### What happens

`omarchy-install-service-1password` opens 1Password when it finishes, but the app is terminated about a second later — as soon as the installer terminal closes. On a first install this lands in the middle of first-run initialization.

### Cause

`omarchy-install-service-1password:31` backgrounds the launch without detaching it from the terminal:

```bash
uwsm-app -- 1password >/dev/null 2>&1 &
```

`uwsm-app` does not start a new session, so the app keeps the installer terminal's controlling pty. `omarchy-show-done` then waits for a keypress; when the terminal exits, the pty hangs up and 1Password receives SIGHUP. Chromium treats SIGHUP as a graceful-shutdown request, so the app quits.

Reproduced with an instrumented process launched exactly this way:

```
uwsm-app -- victim.sh &            → tty=pts/3, receives SIGHUP when the terminal exits, dies
setsid uwsm-app -- victim.sh &     → tty=?,     survives
```

Being in its own systemd scope (`app-1password-<pid>.scope`) does not help — the pty association is independent of the cgroup.

Every other installer that opens an app already does this correctly, including the shared helper `omarchy-install-and-launch`:

```bash
setsid uwsm-app -- gtk-launch steam >/dev/null 2>&1 &   # steam, zed, signal, spotify, vscode, emacs, heroic, chatgpt
```

### Observed sequence

```
12:33:25  pacman installs 1password 8.12.32-33
12:33:25  script runs: uwsm-app -- 1password >/dev/null 2>&1 &
          first run: DB schema migrated 0 -> 61, native-messaging manifests written
12:33:26  installer terminal scope ends
12:33:26.044  1Password log: Front end event: window closed
12:33:26.045  1Password log: app will quit / shutdown requested! / starting app shutdown
12:33:26  kernel: traps: 1password[52271] trap int3 ip:558b7c70e195 in 1password[70ea195,558b77ca5000+9aa1000]
12:33:26  systemd-coredump: Process 52271 (1password) terminated abnormally with signal 5/TRAP
```

Relaunching from the app launcher works fine — that instance has no controlling terminal.

### On the SIGTRAP specifically

Per #7822, 1Password emits a Crashpad SIGTRAP as part of its normal shutdown, so the SIGTRAP here is probably incidental rather than a fault, and the notification that surfaced it is that issue's false-positive. **The bug being reported here is that the app is shut down at all**, not that it trapped.

Two recorded details differ from #7822 and I could not resolve them, so I'm flagging rather than claiming: this coredump has `si_code: SI_KERNEL` where #7822 reports `TRAP_BRKPT`, and this instance's log ends mid-teardown at `running shutdown hook: ffi/op-core-node/src/lib.rs:477` without the `Failed to prepare for requesting dump` line #7822 quotes. That may just be log truncation. No core is available either way — 1Password sets `RLIMIT_CORE=0`.

### Expected

A freshly installed 1Password stays open after the installer terminal closes.

### Fix

```bash
setsid uwsm-app -- 1password >/dev/null 2>&1 &
```

`omarchy-install-service-dropbox:12` has the same omission (`uwsm-app -- dropbox-cli start &>/dev/null &`); lower impact since `dropbox-cli start` daemonizes, but it's the same latent bug.

This is the same class as #6762 (a terminal being torn down under a process Omarchy spawned), fixed there by reordering; here the fix is detaching.

### System

omarchy 4.0.0-1, Linux 7.1.8-arch1-3, Hyprland/uwsm, 1password 8.12.32-33, 1password-cli 2.35.0-1.

---
Filed by Claude Opus 5 via Claude Code.