## System details

Apple MacBookPro18,2 (M1 Max, aarch64), Omarchy 4.0.4-mac.1
(`omarchy-debug` needs an interactive sudo TTY — supplying details inline; the bug is in the script's logic, not environment-dependent.)

## What's wrong?

When the XDG default browser is a `.desktop` file outside the hardcoded allowlist, `omarchy-launch-webapp` silently substitutes `chromium.desktop` and launches the web app in a **different browser** than the user's configured default — typically a different profile with no logins, cookies, or extensions. The app "opens", so the failure looks like the site is broken rather than the launcher.

### Repro

1. Make the default browser a custom launcher `.desktop`, e.g. `browseros.desktop` with `Exec=/home/user/.local/bin/browseros %U` — a wrapper that execs `/usr/lib/chromium/chromium --user-data-dir=~/.config/browser-os` (a dedicated, signed-in profile).
2. `xdg-settings get default-web-browser` → `browseros.desktop` (also set in `mimeapps.list`).
3. Launch any bundled web app, e.g. `X.desktop` → `omarchy-launch-webapp https://x.com/`.
4. Result: the window opens on the **stock chromium default profile** (`~/.config/chromium`) — X shows a login wall even though the configured browser is signed in.

### Root cause

```bash
browser=$(xdg-settings get default-web-browser)
case $browser in
  google-chrome* | brave* | microsoft-edge* | opera* | vivaldi* | helium*) ;;
  *) browser="chromium.desktop" ;;
esac
exec setsid uwsm-app -- $(sed -n 's/^Exec=\([^ ]*\).*/\1/p' .../$browser ...) --app="$1"
```

`browseros.desktop` fails the case → is replaced wholesale by `chromium.desktop`. The configured browser's `Exec=` line is never even read, so a `.desktop` that wraps chromium with `--user-data-dir`/`--profile-directory` can never be honored.

Verified with `bash -x /usr/share/omarchy/bin/omarchy-launch-webapp https://x.com/`:

```
+ browser=chromium.desktop
+ exec setsid uwsm-app -- /usr/bin/chromium --app=https://x.com/
Opening in existing browser session.   # <- default-profile singleton
```

The spawned window (`chrome-x.com__-Default`, owned by a chromium with no `--user-data-dir`) lands in a separate instance from the configured browser (`--user-data-dir=~/.config/browser-os`), confirmed via `hyprctl clients` + `/proc/<pid>/cmdline`.

### Related but distinct

- #13527 — web apps ride whichever *Chrome profile* is active (no `--profile-directory` passed). Same symptom family, different seam: this issue is the launcher choosing a different *browser executable/profile entirely*.
- #10988 — wrapper `Exec=` lines (`env VAR=... brave`) are mis-parsed and fail *silently with no window*. Here the window opens — in the wrong browser.
- #7034 — Firefox default unsupported.

### Suggested direction

Any of:

1. Parse the default `.desktop`'s own `Exec=` first; if the resolved binary is a Chromium-family browser, pass `--app` to *it* (honors wrappers, custom `--user-data-dir` flags, and fixes #10988's parsing gap too). Only fall back to `chromium.desktop` when the default truly isn't app-capable.
2. An opt-in override (`OMARCHY_WEBAPP_BROWSER` env or a config key) forcing which `.desktop` handles web apps — cheap and covers every custom browser.
3. At minimum, surface a notification when the configured default is demoted — a silent browser/profile swap is the core UX bug: nothing looks wrong except that every login is missing.