## Summary

Web apps launched through `omarchy-launch-webapp <url>` run as `chrome --app=<url>` with **no pinned profile**. The app window rides whichever Google profile is active in the shared browser at that moment, so a webapp's login/session does not reliably survive restarts. Symptom the user hits: WhatsApp Web shows the phone-QR login again on every relaunch.

## Repro

1. Have multiple profiles in the browser (e.g. `google-chrome` with `Default` + `Profile 1`..`N`, each signed into a different Google account).
2. Log into WhatsApp Web in one of the non-default profiles.
3. Launch the WhatsApp webapp via `omarchy-launch-webapp https://web.whatsapp.com/` (the bundled `WhatsApp.desktop` uses this).
4. Relaunch it after a restart — logo/session context depends on which profile happened to be active, so it often opens in a profile that has no WhatsApp session → QR scan required again.

## Root cause

`omarchy-launch-webapp` (source: `/usr/share/omarchy/bin/omarchy-launch-webapp`) dispatches:

```
exec setsid uwsm-app -- <browser> --app="$1" "${@:2}"
```

with no `--profile-directory` / `--user-data-dir`. Chrome puts the app window in whichever profile is active, so the webapp's cookie/storage home is nondeterministic. Verified on the reporter's box: the WhatsApp session (`wa_web_access_token` cookie) existed only in `Profile 1` and `Profile 2`; the `Default` profile had no token, and no `clear_on_exit`/cookie-clearing was configured anywhere. So this is a *profile hand-off* bug, not data being wiped.

## Proposed fix (feature request)

Give each webapp a **dedicated, persistent profile** so sessions never drift:

- Add optional flags to `omarchy-launch-webapp`, e.g. `--profile <name>` and/or `--user-data-dir <dir>`.
- Better default: provision a stable per-webapp data dir (e.g. `~/.local/share/webapps/<slug-of-url>/`) and pass it as `--user-data-dir`, so every webapp has isolated storage by construction.
- The webapp-create flow should record the chosen profile and reuse it on every launch.

Anything that shares a `--user-data-dir` improves all logged-in webapps (WhatsApp, ChatGPT, Grok, X, …), not just this case.

> Note (coupling, not in scope here): a dedicated profile starts with no extensions, and
> `--load-extension` currently does not inject the bundled extensions (e.g. `whatsapp-slim`)
> on Google Chrome 153 — tracked separately in #11582. Dedicated-profile work should be
> designed so webapps can reach bundled extensions once that lands.

## Workaround used locally (for reference)

A wrapper that pins a dedicated dir:

```
exec /usr/bin/google-chrome-stable \
  --user-data-dir="$HOME/.local/share/whatsapp-chrome" \
  --app=https://web.whatsapp.com/
```

Login then persists across app and browser restarts. Cost: one-time re-login into the fresh dir (expected).

## Related issues (same launch-webapp fragility family)

- #7034 — launch webapp fails when default browser is Firefox (no Chromium installed)
- #8298 — `omarchy-launch-webapp`: Opera ignores `--app=` so keybinds open the start page
- #10988 — `omarchy-launch-webapp` fails silently when the browser `.desktop` `Exec=` is a wrapper
- #4349 — chromium "Save Password" dialog inaccessible in web apps
- #11582 — (edge) bundled extensions fail to load on Google Chrome 153, `--load-extension` ignored

## Environment

- omamen, Omarchy (Arch), Hyprland
- google-chrome 153 (AUR) set as default browser
- `WhatApp.desktop` → `omarchy-launch-webapp https://web.whatsapp.com/`