Transient daemon silently resurrects killed sessions (bypassPermissions); background tasks die at spawn in sessions with disrupted state

Environment

• Claude Code 2.1.212, Linux x86_64 (kernel 6.8), subscription (OAuth) auth
• Heavy multi-session automation: many concurrent tmux-hosted sessions per host, plus

headless invocations; transient daemons present (claude daemon run --origin transient)

Defect 1: transient daemon silently resurrects killed sessions (with bypassPermissions)

Observed. A claude daemon run --origin transient --spawned-by {...} process outlives the
process that spawned it. It hosts sessions via --bg-pty-host. When one of its hosted resumed
sessions is killed (plain SIGTERM), the daemon re-resumes it: within ~40-60 seconds a fresh
claude --resume <transcript-path> --permission-mode bypassPermissions appears under a new
pty-host child. Measured 42 seconds in a controlled repro.

Aggravating details, all observed in production use:

1. A session whose transcript had been untouched for 17 days was resurrected this way — an

unattended agent session with weeks-stale context, granted bypassPermissions.

1. In one case the resume woke a dormant session, which began executing bash commands

unattended; in another (a different automation host role), a resurrected session performed
git commits and pushes over several hours, racing its live successor.

1. One transient daemon resurrected sessions whose working directories differed from the

daemon's own --spawned-by cwd — blast radius is not scoped to the spawning context.

1. daemon.json's log records only auth-refresh lines. Resurrections are not logged anywhere

we could find — no audit trail that a killed session came back.

1. Killing the resumed session again just repeats the cycle; the only durable stop is killing

the transient daemon first, then the pty-host, then the session.

Expected. An intentionally terminated session stays terminated (or resurrection is opt-in
and visible); resumes are logged; bypassPermissions is not silently re-granted to an unattended
resurrection.

Repro. With a transient daemon alive, SIGTERM a --bg-pty-host-hosted resumed session and
watch the process table for ~60s: a new pty-host + --resume pair appears.

Defect 2: all Bash-tool background tasks die at spawn in sessions with disrupted state

Observed. In an affected session, 5 of 5 Bash tool background executions — both explicit
run_in_background: true and foreground commands auto-promoted to background at the ~120s
timeout — died within seconds of spawn with zero output. This included identical commands run
back-to-back with no source changes: every foreground run succeeded, every backgrounded run
died at spawn. Host exonerated: 88 GiB memory available at kill time, no OOM events, other
sessions on the host backgrounded normally at the same time.

Correlation. The affected session had earlier suffered disrupted session state (its
identity/registry records were lost mid-session while the session itself stayed alive). Our
working hypothesis: background-task lifecycle is keyed to a session record that no longer
matches the live session, so newly spawned background children are immediately reaped as
orphans of a dead/foreign session entry.

Expected. Background task lifetime should be tied to the live session process, and a
background spawn that cannot be tracked should fail loudly rather than being silently killed
with zero output (from the model's side it looks identical to an instantly-completing empty
command).

Repro shape. In an affected session, run any long-lived command with
run_in_background: true; it dies at spawn. We can trigger the "affected" state only
opportunistically, but it recurs multiple times per day across a ~20-session fleet.

Why one report

Both behaviors key on the same object — the session's identity/lifecycle record — and both are
internal to Claude Code, so downstream automation can only work around them (we now sweep for
resurrected sessions and route long tasks foreground in affected sessions). Sanitized process
listings, daemon command lines, and timing logs are available on request.