### System details

- Omarchy `4.0.2-1`
- Hyprland 0.56.2, kernel 7.1.9-arch1-2
- AMD Ryzen 7 PRO 5850U / Radeon Vega (Cezanne)
- `dropbox 264.4.3421-1`, `dropbox-cli 2024.04.17-2`

(`omarchy debug` does not exist in 4.0.2-1 — `Unknown Omarchy command` — so the above was gathered by hand.)

### What's wrong?

The Dropbox panel starts `dropboxd` differently from the installer, and the difference orphans the daemon from the systemd unit that started it at login.

The installer is careful to give the daemon its own session scope:

```bash
# omarchy-install-service-dropbox:12
uwsm-app -- dropbox-cli start &>/dev/null &
```

The panel is not:

```qml
// shell/plugins/panels/dropbox/Service.qml
101:    loginProcess.command = ["dropbox-cli", "start"]   // login()
106:    runControl(["dropbox-cli", "stop"], 0)            // pause()
110:    runControl(["dropbox-cli", "start"], 1)           // resume()
```

`dropbox-cli start` does not create a scope of its own — it is a bare `setsid` fork that inherits the caller's cgroup:

```python
# /usr/bin/dropbox-cli:769
subprocess.Popen([DROPBOXD_PATH], preexec_fn=os.setsid, cwd=os.path.expanduser("~"), ...)
```

Meanwhile the unit that actually starts Dropbox at login is generated by `systemd-xdg-autostart-generator` from `~/.config/autostart/dropbox.desktop` (written by the Dropbox app itself — it is byte-identical to `/usr/share/applications/dropbox.desktop` and `pacman -Qo` disclaims it):

```
# /run/user/1000/systemd/generator.late/[email protected]
Type=exec
ExitType=cgroup
Restart=no
PartOf=graphical-session.target
ExecStart=:/usr/bin/dropbox
```

`Restart=no` plus `ExitType=cgroup` is the load-bearing part. Pressing the panel's pause/resume toggle therefore:

1. runs `dropbox-cli stop`, killing the process the unit owns → unit goes `inactive`, and with `Restart=no` it does not come back for the rest of the session;
2. runs `dropbox-cli start`, respawning `dropboxd` inside **quickshell's** cgroup instead of an app scope.

Nothing appears to break, because the panel polls `dropbox-cli status`, which only talks to `~/.dropbox/command_socket` and has no opinion about cgroups. The widget keeps showing "Up to date" while the daemon has silently migrated out of its unit into whatever cgroup happened to spawn it.

### Steps to reproduce

1. Install Dropbox via the Omarchy menu and let it autostart at login.
2. `systemctl --user is-active [email protected]` → `active`.
3. Press the pause toggle in the Dropbox panel, then press it again to resume.
4. `systemctl --user is-active [email protected]` → `inactive`, and it stays that way.
5. `cat /proc/$(cat ~/.dropbox/dropbox.pid)/cgroup` → the daemon is now under quickshell, not `app.slice/[email protected]`.

### What was observed on this machine

I reached the same end state by a different route (see "related" below), and can confirm the tail of it directly:

```
$ cat /proc/3153459/cgroup
0::/user.slice/user-1000.slice/[email protected]/app.slice/app-ghostty-surface-transient-3152111.scope

$ systemctl --user status [email protected]
○ [email protected] - Dropbox
     Active: inactive (dead) since Sat 2026-09-05 16:23:39 EDT
   Duration: 1w 3d 18h 40min 55.320s
   Main PID: 1393 (code=killed, signal=KILL)
```

That is `dropboxd` living inside a *terminal window's* transient scope — it dies when that terminal closes. It confirms the mechanism the panel path relies on (no `uwsm-app` ⇒ inherit the caller's cgroup); the step-4/5 sequence above is read from the source rather than something I triggered through the panel UI itself.

This also makes Dropbox collateral damage for #9799 (`systemd-oomd` swap kill takes everything sharing one `app-*.scope`).

### Expected

The panel should start the daemon the same way the installer does, so the process lands in its own scope regardless of who pressed the button:

```qml
loginProcess.command = ["uwsm-app", "--", "dropbox-cli", "start"]
runControl(["uwsm-app", "--", "dropbox-cli", "start"], 1)
```

Worth deciding separately whether Omarchy should own the autostart path at all, rather than leaving the Dropbox-authored `.desktop` and the disabled packaged `dropbox.service` / `[email protected]` units to coexist with it.

### Related

- #7870 / #7886 — same class of bug for 1Password: installer launches it without `setsid`, so it dies on SIGHUP.
- #7218 — Sunshine installer configures two autostart paths that collide after login.
- #7461 — `omarchy-fcitx5.service` restart-loops when a user autostart `.desktop` starts it under a different filename.
- #9799 — everything launched from a terminal sharing one `app-*.scope`.
- #9385 — separate but aggravating: `/usr/bin/dropbox` is a trampoline that re-execs into the self-updated client under `~/.dropbox-dist` (here, packaged `264.4.3421` vs running `268.4.4124`, visible as a `/newerversion` argv). That handoff SIGKILLs the running daemon — which is how PID 1393 above died. Any stray `dropbox <anything>` invocation will knock the unit over, and a comment on #9385 reports the same package/client version pair and `status=9/KILL`. That behaviour is currently only described in a comment on a differently-framed issue; it may deserve its own.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01LRoWF6hrY8HLXofBvxutoc