`claude respawn` silently fails on background sessions that hit "request too large" — only nuclear `claude rm + claude --bg` recovers (loses conversation)

Resolved 💬 5 comments Opened May 16, 2026 by jordanl61 Closed May 27, 2026

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:

  1. claude rm <id> — deletes the session entirely
  2. cd <agent_dir> and claude --bg "<startup prompt>" — spawn brand new session with new short_id
  3. 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 respawn should detect that the existing conversation exceeds context limits and either: (a) auto-/compact before restart, (b) error clearly with "context overflow — run /compact or claude 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.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗