Webapp crash takes down all browser windows — add process isolation option

[lukeabbott]

Problem

Webapps installed via omarchy-webapp-install launch with brave --app=URL, which connects to the existing main browser process. If a webapp crashes or the main process becomes unstable, all browser windows die simultaneously — including unrelated tabs and other webapps.

Crash report

• Brave: 145.1.87.190
• OS: Arch Linux, kernel 6.18.x, Hyprland/Wayland
• GPU: Intel Arc A750 (discrete), AMD Raphael/Radeon 680M (integrated)
• RAM: 32GB, 4GB zram swap

What happened:

1. Main Brave instance had been running ~4 days
2. Launched brave --app=https://grok.com at 08:33
3. Launched brave --app=https://outlook.office.com/mail/ at 08:36
4. At 08:36:29, the main Brave scope exited — all windows died

Resource usage at death:

• Main Brave scope: 13h 56min CPU, 6GB peak memory, 116MB swap
• No OOM kill in kernel logs, no segfault in dmesg, no crash dump generated

Proposed solution

Add an --isolate option to omarchy-launch-webapp that launches webapps with --user-data-dir=, creating a fully separate browser process tree. If the isolated webapp crashes, the main browser is unaffected.

This is browser-agnostic — --user-data-dir is supported by all Chromium-based browsers that omarchy-launch-webapp supports (Chrome, Brave, Edge, Opera, Vivaldi, Helium, and the Chromium fallback). The isolated data directory is stored under ~/.local/share/omarchy/webapps/<name> rather than any browser-specific config path.

Trade-off: Isolated webapps don't share cookies/sessions with the main browser, so users need to log in separately.

Usage

Interactive: omarchy-webapp-install prompts with a gum confirm asking whether to isolate.

Programmatic: omarchy-webapp-install --isolate "Grok" https://grok.com/ Grok.png

PR: #4749

[alebak]

Second independent occurrence, with a different browser and a different GPU vendor — same signature as the report above.

Environment

• Google Chrome 151.0.7922.173 (not Brave)
• Omarchy 4.0.1, Hyprland 0.56.2, Arch, kernel 7.1.9-arch1-2
• GPU: AMD Picasso/Raven2, Radeon Vega 8, radeonsi, Mesa 26.2.1 (integrated only)
• 29 GB RAM, 58 GB swap

What happened

Chrome had been up for 1 day. In a Google Meet call, moved a browser window from the external monitor (2560x1080@75, HDMI) to the laptop panel (1920x1080@60, eDP). The browser process died instantly and took every window with it — normal tabs plus all seven webapps.

app-com.google.Chrome-<pid>.scope:  Consumed 2h 54min CPU over 1d 0h 07m, 2.6G memory peak
app-Hyprland-google-chrome-stable-<hash>.scope: Consumed 10h 36min CPU over 1d 0h 07m, 8.6G memory peak

Both scopes are the same Chrome — the browser process re-parents itself into its own app-<appid>-<pid>.scope, which is why the accounting is split.

Ruled out

• Not OOM. 13 GB of 29 GB in use, swap completely untouched, zero oom-kill / systemd-oomd entries.
• Not a compositor restart. Same Hyprland instance from the previous day survived the crash and is still running.
• Not the GPU. Zero amdgpu / drm entries in the kernel log around the timestamp.
• Nothing else died. No other scope terminated in that window.
• Not a pattern. Every other Chrome scope termination in the journal this month was a reboot. This is the only mid-session death.

No forensic trace at all

This is the part that matches the original report most closely:

• coredumpctl is empty, and core dumps are correctly configured (core_pattern pipes to systemd-coredump, ulimit -c unlimited)
• no new minidump in ~/.config/google-chrome/Crash Reports — the newest one there is three months old
• zero stderr in the journal, even though that scope's stderr is journaled: there are INFO lines from the same PID logged the day before. The process produced no fatal message, no abort, nothing.
• exit_type in the profile preferences flipped to "Crashed"

Silent death, no core, no minidump — consistent with a crash absorbed by Chrome's own handler. Same as the 6 GB / 4-day Brave case above, with an entirely different browser build and a different GPU stack. That makes a browser-specific or vendor-specific cause unlikely.

Why --isolate would have contained it

All seven webapps launch through omarchy-launch-webapp ... --profile-directory=Default, so they share the main browser's user-data-dir and therefore its single browser process. One fault, one process, everything gone — including apps that had nothing to do with the window being moved.

With --user-data-dir per webapp, the blast radius would have been one window instead of the whole desktop's worth of them.

Adjacent

Issue #2314 ("Moving browser between monitors kill all apps") has 31 comments reporting this same cascade across Chrome, Brave, Edge, Chromium and Zen, triggered by moving windows between monitors — which is exactly the trigger here. Whatever the root fault is, isolation is what limits the damage.

Also worth flagging for whoever picks up PR #4749: profile flags are browser-specific (--user-data-dir / --profile-directory for the Chromium family, -P for Firefox), and browser selection in this script is hardcoded with no override. Both concerns land on the same two lines, so a per-browser launch adapter would serve them together — discussed in #8444.