## What happened

Switching stable -> edge from the menu (`omarchy-channel-set edge`) asked for the sudo password **19 times** in a single switch on 2026-09-27. Nineteen, for one channel switch.

The run is reproducible from a log of the full session. Mapping each prompt to the step that issued it:

| # | Step | Source |
|---|------|--------|
| 1 | `sudo cp` of `/etc/pacman.conf` ("Setting channel to edge") | `omarchy-channel-set:133` via `omarchy-refresh-pacman:33` |
| 2 | `pacman -S --needed --noconfirm --ask 4 omarchy-dev omarchy-settings-dev` | `omarchy-channel-set:137` |
| 3 | `paccache -rk2` ("Prune package cache") | `omarchy-update:66` |
| 4-8 | `snapper` config query, `create`, and cleanup ("Create system snapshot") | `omarchy-update:71` |
| 9-10 | `pacman-key` refresh ("Update Arch signing keys") | `omarchy-update:78` |
| 11 | `pacman -Syu` ("Update system packages") | `omarchy-update:83` |
| 12-13 | migration 1788129995, "Replace Satty and Tensaku with Omasnap" | `omarchy-update:90` |
| 14 | migration 1788163635, "Remove legacy temporary passwordless sudo grants" | `omarchy-update:90` |
| 15 | migration 1788596255, "Add vi as a standard terminal editor" | `omarchy-update:90` |
| 16 | migration 1789294350, "Switch TCP congestion control to BBR with fq pacing" | `omarchy-update:90` |
| 17 | migration 1789764927, "Enable OWE desktop video backgrounds and lock feed" | `omarchy-update:90` |
| 18 | migration 1790042972, "Install Elsewhen" | `omarchy-update:90` |
| 19 | `pacman -Rns` ("Removing orphan system packages") | `omarchy-update:91` |

Steps 3-19 are all the hand-off update, not the switch itself. 41 of the shipped migrations call `sudo`, so this count scales with how many of them your machine has pending.

## #13323 already fixed most of this

This report is a follow-up, not a duplicate. #13319 was closed by #13323 ("Ask for the sudo password once per `omarchy update`"), merged 2026-09-26. My run is `omarchy-dev 4.0.0.r2304.g7b336b1-1`, which predates that merge and still has the old shape: `omarchy_security_enable_no_update_sudo` at `omarchy-update:28` puts the no-update wrapper on `PATH` for the **whole** run, and per-phase `sudo -k` revokes mean no timestamp survives to the next helper. That is the r2304 behaviour and it accounts for steps 3-19.

So the remaining gap is the one #13323's own description names:

> Channel switching still authorizes its own steps command by command. The update it hands off to then asks once for its own phases.

## The remaining gap, on current master

`omarchy-channel-set` still has no authorization of its own. It revokes the timestamp on entry (`omarchy-channel-set:21`) and never establishes one, so each of its privileged steps starts cold:

1. `omarchy-refresh-pacman` revokes on entry (`:24`), then `sudo cp` (`:33-37`) — prompt 1.
2. It revokes again around the `pre-refresh-pacman` hook (`:44`, `:47`) and calls `pacman -Syyuu` (`:50`) — prompt 2. Its `EXIT` cleanup trap (`:23`) revokes once more.
3. `omarchy-update-pacman -S --needed` for the `omarchy` <-> `omarchy-dev` swap (`omarchy-channel-set:137`) — prompt 3. The cleanup trap on `omarchy-channel-set` revokes again.
4. The hand-off `omarchy-update` then establishes its own — prompt 4.

That is **four** password entries for a channel switch where `omarchy update` now costs **one**, and on r2304 it was nineteen. I verified `bin/omarchy-refresh-pacman` and `bin/omarchy-channel-set` on master are byte-identical to the r2304 copies I ran, so this gap is still live.

## Expected

A channel switch is a single user-initiated operation against the same machine, in the same terminal, with the same trust level as `omarchy update`. It should cost the same one authorization, not four.

## Suggested direction

`omarchy-channel-set` already brackets itself with `omarchy_security_install_sudo_cleanup_traps` / `omarchy_security_revoke_sudo_timestamp`. It could establish one authorization after its entry revoke, in the same shape #13323 gave `omarchy-update` — one `sudo /usr/bin/true` and a keepalive — and hand that timestamp to the steps it trusts, `omarchy-refresh-pacman` and `omarchy-update-pacman`.

The two revokes inside `omarchy-refresh-pacman` are the part that needs care: they exist because `pre-refresh-pacman` is a user hook, and the comment at `:41-43` is explicit that authorization the hook obtained must not carry into the transaction. Revoking the parent's shared authorization there would be wrong. The split that #13323 used is the obvious one: trusted steps reuse the shared authorization, the user hook and the transaction after it run cold. That still costs a second prompt after the hook, unless the hook boundary is what gets relaxed.

Worth deciding explicitly rather than inheriting: the `pre-refresh-pacman` hook is the only genuinely untrusted code between the first and last channel-switch prompts. Everything else in the switch is Omarchy's own scripts.

## System details

```
Omarchy        4.0.0.r2304.g7b336b1-1 (omarchy-dev / omarchy-settings-dev, edge)
OMARCHY_PATH   /usr/share/omarchy
channel        stable -> edge
kernel         7.2.5-3-omarchy running, 7.2.5-4 installed by this switch
CPU            Intel Core i7-10750H (CometLake-H)
GPU            Intel UHD (GT2) + NVIDIA GTX 1650 Ti (hybrid)
sudo           1.9.17p2
date           2026-09-27
```

I can attach the full 981-line log from this run if it is useful.