## What happened

`omarchy update` on 4.0.2 stopped dead at:

```
Running migration (1787481315)
Re-stage the current theme so an installed theme's code is dropped
```

The transcript in `/tmp/omarchy-update.log` went silent mid-migration and produced no further output for 27 minutes, until the terminal was closed. `1787481315` → `omarchy-theme-refresh` → `omarchy-theme-set` → `run_parallel`'s `wait` → `omarchy-theme-set-browser`, which blocks at line 21:

```bash
"$command" --refresh-platform-policy --no-startup-window &>/dev/null   # no &, no timeout
```

## Why this is not #4772, #8158 or #8212

All three existing reports turn on the browser **not** genuinely running:

- **#4772** (closed as completed): no Chromium instance running at all. Fixed by adding the `pgrep -x` guard in `refresh_running_browser`.
- **#8158** / **#8212**: `pgrep -x brave` false-positives on brave-origin's processes, so the guard passes and the script launches *a different binary* (`/usr/bin/brave`), which has no window and never exits.

**This case has no false positive and no second binary.** Chromium is genuinely running, `pgrep -x chromium` is correct, and the call hangs anyway:

```
$ pacman -Q | grep -ci chromium
1                                   # exactly one chromium package, 151.0.7922.173-1
$ readlink -f /usr/bin/chromium
/usr/bin/chromium                   # not a wrapper to some other browser
$ for p in $(pgrep -x chromium); do readlink -f /proc/$p/exe; done | sort -u
/usr/lib/chromium/chromium          # the running processes ARE that package
$ pgrep -xc chromium
16

$ timeout 20 chromium --refresh-platform-policy --no-startup-window; echo $?
124                                 # hangs the full 20s
```

So the guard-based fix from #4772 is insufficient in principle, and the binary-path fix proposed in #8158 (`refresh_running_browser /opt/brave-bin/ brave -f`) would not help here either. With a browser genuinely running, the unbounded foreground call is still unbounded.

Journald shows why: the invocation did not forward the policy to the existing instance and exit. It started a **full second browser** — a fresh `app-org.chromium.Chromium-<pid>.scope`, which was still logging `extension_garbage_collector … complete` 50 seconds later — and then sat there. One of its children also dumped core (SIGTRAP) a second after launch, which may or may not be related; the parent survived and kept blocking.

## Two migrations reach this, not one

```
migrations/1787481315.sh:25   omarchy-theme-refresh          # → theme-set → theme-set-browser
migrations/1787515927.sh:16   omarchy-theme-set-browser || true
```

`|| true` on the second one guards a nonzero exit, not a hang, so it blocks identically. Both are pending on any install that has not yet passed `1787481315`, so a machine that hits this hangs, gets killed, and then hangs again in the same place on the next attempt — no marker is ever written.

## Expected

The refresh should hand the policy to the running instance and return promptly, and in any case should not be able to block an update indefinitely. The policy is picked up at next launch regardless, so there is nothing lost by giving up on it.

## Suggested fix

Bound the call, as #8158 and #8212 both suggested — this report is the argument that a timeout is *necessary* rather than merely defensive, since no amount of guard-tightening covers a true positive:

```bash
timeout 10 "$command" --refresh-platform-policy --no-startup-window &>/dev/null || true
```

## Collateral (separate defect, happy to file separately)

`omarchy-update` sets `trap 'omarchy-update-stay-awake stop' EXIT`. A bash EXIT trap does not run when the shell dies on an uncaught fatal signal, so killing the hung update left the root-owned inhibitor resident:

```
omarchy-update  0  root  <pid>  systemd-inhibit  sleep:idle  Omarchy update in progress  block
```

It was still blocking sleep **and** idle three hours later, on a laptop, with no update running. `omarchy-update-stay-awake stop` cleans it up. A trap on `INT TERM HUP` alongside `EXIT` would close it.

## Reproduce

1. On 4.0.2 with migration `1787481315` pending, have Chromium running.
2. `omarchy update`.
3. It hangs at `Running migration (1787481315)` indefinitely.
4. `timeout 20 chromium --refresh-platform-policy --no-startup-window; echo $?` → `124`.
5. Quit Chromium and re-run: the migration completes immediately.

## System

- Omarchy 4.0.2-1
- kernel 7.1.8-arch1-3 (7.1.9.arch1-2 installed, pending reboot)
- chromium 151.0.7922.173-1
- hyprland 0.56.2-1, quickshell 0.3.1-1
- AMD Ryzen 5 PRO 4650U / Radeon Renoir

`contributing.md` points at `omarchy debug --no-sudo --print` for diagnostics, but that command still does not exist on 4.0.2 (`Unknown Omarchy command: omarchy debug`) — same as #8158 reported for 4.0.0 — so the above was gathered by hand.

---

Filed by Claude Opus 5 via Claude Code.