[BUG] [Linux] Transient daemon respawns/displaces itself every ~52s while `claude agents` is open (storm of ~1 `claude daemon run`/sec); drops claude.ai bridge + MCP each cycle

Summary

On Linux (running inside a code-server Docker container), the transient background-job daemon is replaced every ~52 seconds, indefinitely, whenever a claude agents view is open. Each cycle tears down and re-establishes the claude.ai bridge and every MCP connection, and on older versions killed background workers outright. The daemon log shows 13,715 daemon start lines accumulated, with a metronomic ~52.13s cadence. There is no error logged — the daemon just gets displaced by a freshly-spawned one.

This is not the Windows auto-updater reinstall loop (#64104) — versions are identical across restarts here; nothing is reinstalling.

Environment

• Claude Code: 2.1.175 (reproduces; first seen on 2.1.150)
• Node: v22.22.3
• OS: Ubuntu 24.04.4 LTS, kernel 6.12.54 (Unraid host), inside a code-server Docker container
• Install: native (~/.local/share/claude/versions/...)
• Auth: claude.ai (Pro/Max), Remote Control + Agents view in use, several MCP servers configured

What happens

claude daemon status shows the serving daemon pid flipping every ~56s (confirmed by sampling — 2 flips in 2 minutes). The daemon log shows a new supervisor every ~52.13s:

[2026-06-13T04:19:48.884Z] [supervisor] ─── daemon start ─── version=2.1.175 pid=638325 origin=transient
[2026-06-13T04:20:41.005Z] [supervisor] ─── daemon start ─── version=2.1.175 pid=638554 origin=transient   Δ52.12s
[2026-06-13T04:21:33.139Z] [supervisor] ─── daemon start ─── version=2.1.175 pid=638818 origin=transient   Δ52.13s
[2026-06-13T04:22:25.264Z] [supervisor] ─── daemon start ─── version=2.1.175 pid=...    origin=transient   Δ52.13s
[2026-06-13T04:23:17.396Z] [supervisor] ─── daemon start ─── version=2.1.175 pid=...    origin=transient   Δ52.13s

Underneath, there is a storm of ~1 short-lived claude daemon run process spawned per second; almost all lose the lock race and exit in <1s, and one wins every ~52s and displaces the running daemon. Each spawn's parent is the claude agents view (and occasionally a --bg-spare worker):

daemon-run pid=629552 ppid=626854 parent=[claude agents]
daemon-run pid=630245 ppid=626961 parent=[... --bg-spare ...]
daemon-run pid=630254 (already exited)
daemon-run pid=630292 (already exited)
... ~1 new daemon-run pid per second ...

Each new supervisor logs only the routine adopt/spare lines — no error explaining the displacement:

[supervisor] ─── daemon start ─── version=2.1.175 pid=... origin=transient
[supervisor] workers=0
[bg] bg adopt: adopted=4 respawned=0 dead=0
[bg] bg orphan-spare reap: 1
[bg] bg spare spawned host pid=...

Historically the log also showed idle 5s with no clients — exiting and another daemon won the lock race (pid=...) — exiting, consistent with a spawn/lock-race storm.

Impact

1. Background agents stop unexpectedly / "Interrupted" with no user action. On 2.1.159 / 2.1.172, the handoff killed workers — bg adopt logged dead=3, dead=4, up to dead=11. Agent status dots ended up wrong (job finished but marked failed; "needs input" shown with nothing pending) because workers were killed before emitting their final result.
2. claude.ai Remote Control + every MCP server disconnect/reconnect every ~52s — constant connection churn, visible as repeated MCP connect/disconnect notifications and remote-control drops.
3. Log + process-table noise (13,715 restarts; ~1 spawned process/sec).

Mitigation already observed

2.1.175 fixed the worst part: daemon handoffs now adopt workers (dead=0 — 12,343 of 12,474 adopts) instead of killing them, so background jobs survive the recycles much better. (dead>0 counts are almost all from the older 2.1.159/172 days.) But the ~52s churn itself is unchanged on 2.1.175.

Reproduction / things tried (none stop the churn)

1. claude update 2.1.172 → 2.1.175.
2. Full clean restart: exit all sessions, claude daemon stop --any, reopen claude agents.
3. Closing a duplicate claude agents view (had two open) — a single agents view alone still churns at the identical 52.13s cadence, so it's not a multi-instance amplifier.
4. control.sock is present and freshly recreated each cycle; /tmp is on stable container storage (not tmpfs / not being wiped), so it's not a stale-socket or cleared-/tmp issue.

Because service install is disabled in this version (claude daemon --help: "Service install is disabled in this version — the daemon runs on demand and exits when the last client disconnects"), there's no persistent-daemon workaround available to the user.

Expected

A single claude agents view should keep one stable daemon alive for its lifetime, not respawn/displace it every ~52s.

Asks

• Is the agents view's "ensure a daemon" path racing its own lock and respawning ~1/sec?
• Could a persistent/long-lived daemon option be re-enabled for Linux to avoid the transient-respawn storm?