## What happened

`omarchy-remove-browser` uninstalls a browser package without checking whether that browser is currently running. If it is, the running process survives on deleted inodes and is left in a half-dead state: the browser window stays up and usable, but every child process it subsequently spawns hits a fatal `CHECK` during startup and dumps core.

On this machine that produced three core dumps over two hours from a browser that still looked fine on screen.

**This affects all six browsers the script supports, not just Chrome.** Every branch — `chrome`, `brave`, `brave-origin`, `edge`, `firefox`, `zen` — calls `omarchy-pkg-drop` with no running-process check, so the same failure is reachable through any of them. Chrome is simply what I hit; the reproduction and crash detail below are Chrome-specific, but the defect is in the shared removal path. The Chromium-family browsers (Chrome, Brave, Brave Origin, Edge) would fail in the same multi-process way; Firefox and Zen would degrade differently but are equally unguarded.

Timeline from `pacman.log` + journal:

| Time (2026-08-14) | Event |
|---|---|
| 13:33:34 | Chrome launched via `gtk-launch google-chrome.desktop` |
| 13:36:28 | `omarchy-remove-browser chrome` invoked |
| 13:36:32 | `pacman -Rns --noconfirm google-chrome` — `/opt/google/chrome` deleted |
| **13:36:34** | Core dump: child `OnDeviceModelService`, SIGTRAP |
| 15:11:44 | Core dump: child `VideoCaptureService`, SIGTRAP |
| 15:30:26 | Core dump: child `VideoCaptureService`, SIGTRAP |

The browser process itself (PID 20399) was still running with **143 mappings** backed by deleted inodes at the time of diagnosis, ~2 hours after the package was removed.

## Expected

`omarchy-remove-browser` should detect that the target browser is running and either refuse with a message, or prompt to close it first — before handing the package to `omarchy-pkg-drop`.

## Actual

`/usr/share/omarchy/bin/omarchy-remove-browser` goes straight to removal with no running-process check. The `chrome` branch:

```bash
chrome)
  echo "Removing Chrome..."
  set_fallback_default_browser google-chrome.desktop
  omarchy-pkg-drop google-chrome
  rm -f ~/.config/chrome-flags.conf
  sudo rm -f /etc/opt/chrome/policies/managed/color.json
  ;;
```

`omarchy-pkg-drop` in turn runs `sudo pacman -Rns --noconfirm`, so there is no confirmation step anywhere in the path. All six browser branches (`chrome`, `brave`, `brave-origin`, `edge`, `firefox`, `zen`) have the same gap.

## Steps to reproduce

1. Launch Chrome and leave it open.
2. Run `omarchy remove browser chrome`.
3. Leave the still-running Chrome window open and visit a page that requests camera/mic access (or otherwise causes a new utility process to spawn).
4. `coredumpctl list` shows SIGTRAP core dumps from `/opt/google/chrome/chrome`.

## Crash detail

The crash itself is correct Chrome behavior, not a Chrome bug — it is a deliberate `CHECK` failure, since the install directory the child needs is gone. Chrome ships stripped and publishes no debug symbols, so no frame symbolizes. I recovered the machine code at the crash site by reading the deleted binary back through `/proc/<browser-pid>/exe`:

```
... e8 4f b2 3e fd   call   <check-failure handler>
    cc               int3            <- trapped here
=>  0f 0b            ud2             <- RIP after the trap
```

That `int3; ud2` pair is Chrome's `IMMEDIATE_CRASH()`, emitted by a failed `CHECK()`. `int3` raises SIGTRAP with `si_code: SI_KERNEL`, matching what `coredumpctl info` recorded. The kernel agrees independently:

```
traps: chrome[92502] trap int3 ip:55720d1e78ba sp:7fffbed73a50 error:0 in chrome[5eb68ba,55720a4d8000+d72d000]
```

Both `VideoCaptureService` crashes are at the identical offset (`chrome + 0x5eb78ba`); the `OnDeviceModelService` crash is at a different one (`+ 0x50c6b15`) — so it is one root cause reached through more than one code path, not a single repeated failure. Without symbols I cannot name the specific assertion; the plausible candidates are resource files (`icudtl.dat`, `.pak`) or a sibling `.so` resolved by path relative to the deleted module directory.

Ruled out: no memory pressure (32 GiB free, zero swap used, no OOM kills) and no library-ABI skew (nothing Chrome links against was upgraded in the window).

## Suggested fix

A `pgrep` guard in `omarchy-remove-browser` before `omarchy-pkg-drop`, applied to all six branches — refuse, or prompt to quit the browser first. Removing a browser while it is open seems like the common case rather than an exotic one, and the current failure mode is silent: nothing on screen indicates anything is wrong, while core dumps accumulate in the background.

## Related

#6748 (`omarchy-update` replacing `/usr/share/omarchy/shell` under the running Quickshell) is the same class of bug — a package operation applied underneath a running program — but a different component, and its fix was a sequencing change specific to `omarchy-update` rather than a general guard. Noting it as precedent, not as a duplicate.

## System

- `omarchy version`: 4.0.0-1
- Kernel: Linux 7.1.8-arch1-3
- Removed package: `google-chrome 151.0.7922.137-1`

---

Filed by Claude Opus 5 (1M context) via Claude Code.