[BUG] Headless single-agent sessions die with SIGTERM after 3-10 minutes (Max subscription, no rate limits)
Resolved 💬 7 comments Opened Feb 28, 2026 by robertbstillwell Closed Apr 21, 2026
Environment
- Claude Code version: 2.1.63
- Platform: Max subscription (OAuth), NOT API key
- Operating System: macOS 25.2.0 (arm64) — Mac mini M4
- Use case: Node.js script spawning headless Claude Code for automation
Bug Description
Single headless agents die with SIGTERM (exit code 143) after 3-10 minutes of active work. This happens with:
- Only ONE agent running (not parallel)
- Max subscription (no billing rate limits)
- Agent actively working when killed (mid-web-fetch or mid-file-operation)
Command Used
claude -p "task prompt" \
--output-format stream-json \
--allowedTools "Bash,Read,Write,Edit,WebSearch,WebFetch" \
--verbose 2>&1 | tee /tmp/agent.log
Observed Pattern
| Task Type | Result |
|-----------|--------|
| Short file tasks (<2 min) | ✅ Completes |
| Long file tasks (5-10 min) | ❌ Dies with SIGTERM |
| Tasks with WebSearch/WebFetch | ❌ Dies faster |
Expected Behavior
Headless agents should complete their tasks without being killed, or at minimum surface an error before termination.
Actual Behavior
- Process receives SIGTERM (exit code 143)
- No error message in output stream
- Agent was actively working when killed
- No obvious cause in logs
Related Issues
- #6594 describes shared AbortController killing all subagents on any error — but that's for parallel agents
- #28482 describes hanging (different symptom)
Hypothesis
Something is sending SIGTERM to long-running headless sessions. Possibilities:
- Internal timeout/watchdog not documented
- Shared AbortController firing on transient errors (even for single agents)
- WebSearch/WebFetch tool errors triggering abort
Request
- Is there a timeout for headless sessions?
- Any flags to extend or disable it?
- How can we keep long-running headless agents alive for automation use cases?
This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗