`claude respawn` silently fails on background sessions that hit "request too large" — only nuclear `claude rm + claude --bg` recovers (loses conversation)
Running 9 sub-agent background sessions via claude --bg under the daemon supervisor (agent-view feature) on Windows 11. Sessions accumulate conversation context over ~36-48 hours of cron-driven activity, then enter a "Needs input" state with detail Prompt is too long and request too large — /compact or trim.
Expected: claude stop <id> followed by claude respawn <id> brings the session back, per docs ("Restart a stopped session with its conversation intact").
Actual: claude respawn returns exit 0 ("respawned <id>") but the session's state.json stays at "state": "stopped" indefinitely. The session never transitions back to working. Multiple respawn attempts each return success but never reach a running state. The supervisor doesn't seem to detect the failure to start.
Pattern reproducible across 8 separate sub-agent sessions over 48 hours — different agent directories, different cron registries, identical failure mode each time.
The only workaround we found:
claude rm <id>— deletes the session entirelycd <agent_dir>andclaude --bg "<startup prompt>"— spawn brand new session with new short_id- Update any tracking files that reference the old short_id
Cost of the workaround: loses the session's conversation history. Acceptable for our use case (sub-agent state lives in shared JSON files on disk, conversation isn't load-bearing). Would be a major problem for sessions where conversation history matters.
Suggested fix(es):
claude respawnshould detect that the existing conversation exceeds context limits and either: (a) auto-/compactbefore restart, (b) error clearly with "context overflow — run/compactorclaude rm + claude --bg", or (c) restart with a fresh conversation that retains the session's metadata + cron registry but not its full message history.- Even an explicit error message would be a huge UX improvement over the current silent "respawned but never starts" behavior. Right now the only signal something's wrong is reading state.json directly.
Environment:
- Claude Code v2.1.142 (Windows native, npm-installed)
- Windows 11 Pro 10.0.26200
- Background sessions spawned via
claude --bg "<startup prompt>" - Daemon-supervised (agent-view feature)
- 9-agent fleet running cron-keep-alive every 3 min per agent
Happy to share state.json captures from the affected sessions or any other diagnostic.
6 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Thanks for the bot suggestion. Looked at all three: they're adjacent but not exact duplicates.
request_too_largeerror itself. This issue is about the downstreamclaude respawnbehavior — it returns exit 0 but the session never actually transitions back to running.--mcp-config/--settingsnot preserving across respawn. Same agent-view surface, different specific bug./compacton respawn — if it's broken in the SDK too, that's relevant context for whoever's working on this area.Happy to close this as a duplicate if maintainers feel #58943 better captures it. Otherwise the silent-failure-of-respawn behavior is the specific repro this issue is reporting.
The pattern you're describing —
respawnreturning success while the state machine never advances paststopped— is the canonical shape of "the supervisor and the supervised disagree about what 'restarted' means." A few notes from running long-lived background fleets in an adjacent coordinator-shaped context, in case any are useful:The silent-success / state-stuck split is structural. Once a session hits
request too large, the recovery action (compact, trim, fresh-context-with-metadata, hard-rm) is a policy decision, not a transport action. Right nowrespawnis wired as a transport ("re-attach the process") but the underlying state requires policy ("what do we do with the context that just exceeded budget?"). Until those are separated, everyrespawnon an oversize-context session will succeed-then-no-op, because the only thing it can legally do is the thing that won't actually unstick the session. Exit code 0 with an unchanged state file is the predictable consequence of that mismatch.A coordinator layer wants three distinct verbs here, not one:
respawn --keep-context— current behavior; only succeeds if context fits. Fail loudly when it doesn't.respawn --compact— auto-/compactthen restart. Lossy-but-recoverable.respawn --reseed— drop context, replay startup prompt, keep cron registry + metadata. Lossy.Right now all three are collapsed into one verb and the failure mode is whichever path silently no-ops first. The "nuclear
claude rm + claude --bg" workaround is really--reseedwith the registry lost — surfacing that as a first-class option preserves the cron metadata you're already managing in the daemon.Independent of the fix, the state-file-as-source-of-truth pattern is doing you a favor. The fact that the bug is observable by reading
state.jsondirectly (and only there) means the daemon already has the right contract —respawnjust isn't honoring it. APostRespawnHookthat assertsstate.state == "working"within N seconds of an exit-0 respawn would catch this from the outside without any internal changes, and is probably worth adding to the 9-agent cron supervisor regardless of whether the upstream fix lands. That at least gives you "the supervisor noticed the supervised disagrees" instead of silent drift across 8+ sessions over 48h.The
/compact-before-respawn suggestion in the issue body is the right minimum, but the deeper bug is that one verb is trying to be three. Worth treating the docs ambiguity ("respawn restarts the stopped session with conversation intact") as the leading indicator — there's no honest single-verb answer when the conversation is what stopped the session.The silent-success-but-stuck pattern you've hit is one of the harder failure modes to debug because the control plane (respawn, state.json) reports a clean result while the actual session never transitions. Worth naming the structural issue: the respawn path is missing an acknowledgment loop that verifies state.json has actually moved from "stopped" to "working" before declaring success.
For anyone running unattended multi-session workflows at this scale (you mention 9 background sessions, 36-48h cycles), the practical gap here is that the orchestrator has no reliable signal distinguishing "this session is recovering" from "this session silently stalled." The workaround you've documented (rm + fresh spawn) is the right recovery path, but you lose the conversation trace — which matters when the session's accumulated context is itself the work artifact.
This compounds with the
--resumeflag behavior (#40319, #43696): once a background session hits "request too large" and enters this stuck state, even a manual--resumewon't help because the session record never enters a state the resume logic considers valid.The root issue is that session lifecycle transitions (stopped → working, working → needs-input, needs-input → working) appear to be fire-and-forget signals with no retry or timeout surface. For long-running supervised workflows, the supervisor needs to be able to detect "issued respawn N seconds ago, session still stopped → treat as failed and trigger recovery." Right now that detection logic has to live entirely outside the harness.
Would be worth adding: (1) explicit failure exit code from
claude respawnwhen state.json doesn't transition within a configurable window, and (2) aclaude session status <id>command that polls state.json and returns a machine-readable result so supervisors can build the detection loop without reading internal files directly.Assigning @bogini is the right path — this is squarely the agent-view/background-session surface.
Addressed by a merged fix. Please reopen with a fresh repro if you still see this on a current version.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.