### System details

Omarchy 4.0.3-1, Hyprland 0.56.2, x86_64. dropbox 264.4.3421-1 (self-updated client 268.4.4124 under `~/.dropbox-dist`), dropbox-cli 2024.04.17-2.1.

### What's wrong?

The panel's Login and Resume buttons run `dropbox-cli start`. That command decides whether Dropbox is already running by reading `~/.dropbox/dropbox.pid` and checking that the pid is a `dropbox` process. If the file is missing or names a dead pid, `start` forks a fresh `dropboxd` from `~/.dropbox-dist` regardless of whether a daemon is actually running. The result is two daemons on one `~/.dropbox`, and the panel ends up reporting the wrong one.

Measured on a healthy, up-to-date install by moving the pidfile aside and running `dropbox-cli start` once from a terminal:

- A second daemon started within 2 seconds, in the caller's cgroup. It rewrote the pidfile with its own pid and took over both command sockets. The original daemon, still under `[email protected]`, kept running.
- Both ran side by side for the 2 minutes I watched. Neither exited or killed the other.
- From that point `dropbox-cli status` answered "Starting..." and stayed there, because the CLI now talks to the newcomer. The original kept syncing, invisible to the CLI and so to the panel.
- Killing the stray did not recover: the pidfile still named the dead pid, `dropbox-cli status` reported "Dropbox isn't running!", and the original daemon was still up and syncing. Only `systemctl --user restart [email protected]` repaired the state.

When the panel is what runs `start`, the second daemon lands in Quickshell's cgroup (#10423), and the panel shows "Starting..." indefinitely on a machine where Dropbox is in fact working.

### Steps to reproduce

1. Dropbox linked and reporting "Up to date" under the autostart unit.
2. `mv ~/.dropbox/dropbox.pid ~/.dropbox/dropbox.pid.bak`
3. `dropbox-cli start` (or press Resume in the panel).
4. `pgrep -x dropbox` shows two pids; `dropbox-cli status` shows "Starting..." and does not progress.
5. `kill` the newer pid; `dropbox-cli status` now shows "Dropbox isn't running!" although the older pid is alive.
6. `systemctl --user restart [email protected]` to recover.

### How the pidfile goes stale in practice

I did not see the pidfile go stale during two full link rounds on this client, so those rounds do not establish ordinary linking as its cause. Two routes I have seen: the daemon being replaced by a bare `dropbox …` invocation (the #9385 mistake, which swaps the running process), and killing a stray daemon that had already taken the pidfile, as in step 5 above. When the pidfile is missing or stale, a Login or Resume action that runs `dropbox-cli start` can fork a duplicate despite the existing daemon. After that duplicate takes over a valid pidfile, further starts need not fork again; the observed damage is already present.

### Where a fix could go

This is a `dropbox-cli` behaviour and arguably belongs upstream, but the panel is the thing pressing the button. Options, from least to most invasive:

- Before running `start`, the panel could check for a live `dropbox` process itself (or for the command socket answering) and skip the launch, showing "Dropbox is running but not answering" instead.
- After running `start`, if status stays on "Starting..." while more than one `dropbox` process exists, surface that rather than the bare status text.
- Have the panel start the daemon through the autostart unit (`systemctl --user start [email protected]`) rather than `dropbox-cli start`, which would also address #10423 by construction.

### What draft PR #11955 mitigates

The review follow-up in #11955, commit 38c0ba78, now guards all clicks during an already-pending link:

- If the panel captured a URL, another click reopens that page.
- If no URL was captured, another click keeps waiting. This covers the client behavior measured in that PR.
- Neither pending-click path runs another `dropbox-cli start` or resets the link deadline.

This is a limited repeat-click mitigation, not a stale-pidfile or daemon-ownership fix. An initial Login, Resume, or a fresh retry after the link wait times out still uses the unchanged launch path and can encounter this issue. The draft is not merged; this issue remains open.

The follow-up was verified using an isolated Quickshell runtime fixture with a fake CLI/status helper and an intercepted browser boundary. The fixture rejects the original no-URL repeat-click behavior. The real duplicate-daemon reproduction recorded above was not repeated for this update.

### Related

- #10423 / #10538: the cgroup the panel-started daemon lands in. Same launch path, different consequence.
- #9385: running `/usr/bin/dropbox` (the daemon) instead of `dropbox-cli`. That replaces the daemon rather than duplicating it, but it is one way the pidfile ends up stale.
- The "Starting..." blocker in #9385's comment was inotify watch exhaustion; the "Starting..." here is the second daemon, and the journal shows nothing.
- #8499 also changes the login path. Its URL-discovery timeout needs to be coordinated with #11955's no-URL completion wait before combining the two; a textual rebase alone does not establish compatible behavior.