Background-session daemon: un-settled worker pins daemon → reconnect re-forks a duplicate idle session (+ --continue drops permission mode; forks inherit auto/computer-use)

Claude Code — background-daemon lifecycle & reconnect defects (bundle)

Draft for filing at anthropics/claude-code. Four related defects observed on one machine on
2026-07-14, all in the background-session daemon's spawn / settle / reconnect / fork lifecycle.
Grouped because they share a root neighborhood and compounded into one alarming symptom. Split into
separate issues if maintainers prefer.

Environment

• Claude Code 2.1.202 (Homebrew Cask), macOS (Apple Silicon).
• Evidence source: ~/.claude/daemon.log (the harness's own daemon log). UTC timestamps as logged;

EDT in parentheses.

• Context: several concurrent Claude Code sessions across separate project directories, plus a

fleet "bounce" (each seat resumed via claude --continue).

---

Defect 1 — A background job can never settle, pinning its daemon alive indefinitely

Summary. A background worker that never receives a bg settled record keeps its daemon from
ever hitting the idle …with no clients — exiting path, so the daemon stays alive indefinitely.

Evidence.

[2026-07-14T13:17:44Z] [supervisor] ─── daemon start ─── version=2.1.202 pid=90938 origin=transient   (09:17 EDT)
[2026-07-14T13:17:44Z] [bg] bg spawned a8c5cda7 (slash)                                                (09:17 EDT)
… (no `bg settled a8c5cda7` line appears anywhere in the log) …
[2026-07-14T23:34:43Z] [supervisor] shutting down (cause=signal, …, live_workers=1)                    (19:34 EDT)

Session a8c5cda7 was spawned at 13:17:44Z and has no matching bg settled line for ~10 hours,
until a cause=signal shutdown. For contrast, a clean daemon idle-exits promptly:

[2026-06-17…] [supervisor] idle 5s with no clients — exiting

The idle-exit is gated on there being no live clients; an un-settled background worker counts as a
live client forever, so the 5s idle path is never reached.

Expected. A background worker that has finished (or gone idle) should reach a terminal bg
settled state so the daemon can idle-exit. A worker that legitimately stays live is fine — the
defect is that this one never settled despite being idle.

Impact. The pinned-alive daemon is the precondition for Defect 2 (a reconnect re-forks off it).

---

Defect 2 — A reconnect re-forks off a still-live daemon into a duplicate idle session

Summary. Resuming/reconnecting a seat whose daemon is still alive (per Defect 1) spawns a
duplicate background session forked off that daemon — resuming the same anchor conversation —
rather than reconciling against or reusing the existing session.

Evidence.

[2026-07-14T13:17:44Z] [bg] bg spawned a8c5cda7 (slash)      ← original, still live (Defect 1)
[2026-07-14T23:03:26Z] [bg] bg spawned 478bce6d (slash)      (19:03 EDT) ← the duplicate fork
[2026-07-14T23:16:03Z] [bg] bg settled 478bce6d (crashed)    (19:16 EDT) ← manually killed

A reconnect at 19:03 EDT hit the still-live daemon (kept alive by a8c5cda7) and forked a new
session 478bce6d that resumed the same morning anchor conversation — so it opened idle with
stale context from a conversation hours old.

Expected. A reconnect should detect the existing live background session for that
project/daemon and reconcile (reuse or skip) rather than fork a fresh duplicate.

Impact. Recurs on every reconnect while an un-settled session pins the daemon — each bounce
spawns another orphan.

---

Defect 3 — claude --continue does not restore the session's permission mode

Summary. Resuming with a bare claude --continue (no --permission-mode flag) brings the
session back in plan mode even when the prior session's last-recorded permission mode was
auto.

Evidence / repro.

1. Leave a session in auto (its transcript's last permissionMode record is auto).
2. Resume with claude --continue (no --permission-mode flag).
3. Observed: the session comes up in plan mode, not auto.

Note: threading the flag explicitly — claude --continue --permission-mode auto — does restore
correctly, so the resume machinery can honor the mode; the defect is specifically that the no-flag
--continue default does not restore the left mode from the resumed session's own state.

Expected. --continue should restore the resumed session's last permission mode (the mode it
was left in), the same way it restores the conversation.

---

Defect 4 — Forked/resumed sessions inherit --permission-mode auto + the full computer-use toolset by default

Summary. The duplicate session from Defect 2 (478bce6d) opened carrying
--permission-mode auto and the full mcp__computer-use__* toolset — with a stale diff on
screen and no user having launched it. It read as a hand-armed autonomous agent; it was in fact just
the ambient fork configuration (a co-resident session carried the identical set).

Expected / question. Should an idle background fork inherit auto + computer-use by default?
An unattended, user-unlaunched session defaulting to auto permission with computer-use available
is a surprising and alarming security posture. At minimum, a fork that opens idle (never runs a
turn) arguably shouldn't inherit elevated permission + computer-use.

---

Why bundled

Defects 1→2 are causal (un-settled worker pins the daemon → reconnect re-forks off it), and 3→4 are
what made the resulting orphan alarming (wrong mode + elevated toolset on an unlaunched idle
session). All four live in the same background-session lifecycle. The full ~/.claude/daemon.log
can be attached on request.