Background session crash-loop on attach + ambiguous kill behavior on worker pool

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Two related reliability issues with background agent sessions:

1. A background session can enter a crash-loop that makes it impossible to attach to. Attempting to resume it produces a repeating [worker crashed (exit 1 — exit_with_message) — respawning…] message instead of ever attaching.
2. Killing background worker processes with a normal kill (SIGTERM) appears to do nothing — the daemon's spare-worker pool replenishes killed processes before the next ps aux check, making it look like the kill silently failed. Only kill -9 (SIGKILL) reliably confirms the process is actually gone (No such process).

The combination made it very difficult to get an accurate picture of what background sessions were actually running, and how to reliably stop unwanted ones, without dropping to raw ps/kill -9 at the OS level and manually cross-referencing PID start-times.

What Should Happen?

• Attaching to a session that's in a crash-loop should either succeed, or fail with a clear, actionable error — not repeat [worker crashed ... — respawning…] indefinitely with no path forward except stopping it from the separate claude agents list view instead.
• Stopping/killing a background session should have an unambiguous success signal. If a spare/pool worker is spawned to backfill capacity right after a kill, it should be clearly distinguishable from the session the user was actually trying to stop (e.g. a distinct process name/arg, or explicit confirmation output), so a user doing manual process management isn't left uncertain whether their target actually died or they're looking at an unrelated replacement process.

Error Messages/Logs

Session <id> is currently running as a background agent (bg). Use `claude agents` to
find and attach to it, or add --fork-session to branch off a copy.

[worker crashed (exit 1 — exit_with_message) — respawning…]

$ kill 36417 65277 65296 [... full PID list ...]
$ ps aux | grep -i claude
# same PIDs still present, plus a NEW unclaimed --bg-spare worker process
# (different PID, no --resume argument) had appeared

$ kill -9 36417 65277 65296 [... same PID list ...]
-bash: kill: (36417) - No such process
-bash: kill: (65277) - No such process
[... all PIDs report "No such process" ...]

Steps to Reproduce

1. Accumulate several hours of Claude Code usage with multiple background agent sessions across several different project directories (in this case: ~24 distinct sessions, 48+ processes, across standards, panll, nexia-list, odds-and-sods-package-manager, and several generic -home-hyperpolymath-developer-repos paths).
2. Attempt to attach directly to one specific background session via its resume path (reached via the "Session X is currently running as a background agent" prompt). Observe the crash-loop described above instead of a successful attach.
3. Run ps aux | grep -i claude to enumerate all background Claude processes (parent --bg-pty-host + child --resume <session>.jsonl pairs per session).
4. Run kill <pid1> <pid2> ... (plain SIGTERM) against the full list of non-essential PIDs (excluding the core daemon and any session you want to keep).
5. Re-run ps aux | grep -i claude — the same PIDs are still listed, and a new unclaimed --bg-spare worker (no --resume argument) has appeared with a fresh PID.
6. Run kill -9 against the same original PID list from step 4 — every PID now reports No such process, confirming the original SIGTERM in step 4 had actually worked; the confusion in step 5 was caused entirely by the daemon backfilling its spare-worker pool with a new, differently-numbered process that happened to show up in the same ps aux output.

Claude Model

Multiple models observed across different background sessions in the same ps aux snapshot: sonnet and claude-fable-5[1m] (some at --effort xhigh).

Is this a regression?

Unknown — first time encountering this specific combination of behaviors.

Last Working Version

N/A (unknown if this is a regression)

Claude Code Version

2.1.201 (Claude Code)

Platform

Claude API (via claude CLI on Anthropic's own agent/session management, not a third-party integration)

Operating System

WSL2, Ubuntu, Linux 6.18.26.1-microsoft-standard-WSL2

Terminal/Shell

bash, via a native WSL2 terminal (not through a piped/non-TTY wrapper — note that claude agents itself correctly detects and reports "requires an interactive terminal (stdout is not a TTY)" when run in a non-TTY context, with a helpful --json fallback suggestion; that specific behavior worked fine and is not part of this report)

Additional Information

This was discovered while trying to understand why a very long list of background agent sessions had accumulated over several hours, several of which were running --effort xhigh --model claude-fable-5[1m] (the most expensive available configuration) concurrently. The ambiguous kill behavior in particular made it genuinely unclear for a period of time whether cost-relevant background sessions had actually been stopped, which is a meaningfully worse experience than the underlying pool-management behavior itself.