Uncontrolled background agent parallelization causes context overflow, session death, and wasted tokens
Status Closed — not planned
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 7 comments · opened Feb 14, 2026 · closed Apr 23, 2026
Bug Report: Uncontrolled background agent parallelization causes context overflow, session death, and wasted tokens
Environment
- Claude Code version: v2.1.39
- Model: Opus 4.6 (Claude Max subscription)
- OS: Windows 11 Pro 10.0.26200
- Date: 2026-02-14
Summary
When Claude Code launches many background agents (Task tool with run_in_background: true) in parallel, the returning results can overflow the context window. This kills the session with no recovery path, and the user pays for all tokens consumed by the agents — even though the results were never usable.
Steps to Reproduce
- Start a Claude Code session and work on several tasks (building up context)
- Ask Claude to document a large codebase comprehensively ("Document everything — theme, plugins, all files")
- Claude launches 14 background agents (Explore subagent_type) in three waves (6 + 5 + 3)
- All agents run in the background, each consuming tokens independently
- Agents start completing and returning results
- Context window fills up
What Happened
- Claude launched 14 parallel background agents to explore different parts of the codebase
- Each agent consumed significant tokens (e.g., "21 tool uses · 80.8k tokens · 1m 25s" for a single agent)
- As agents completed, each return added to the context
- After ~10 agents returned, the context was full
- Every subsequent agent completion showed:
Context limit reached · /compact or /clear to continue - Running
/compactfailed with:Error: Error during compaction: Error: Conversation too long. Press esc twice to go up a few messages and try again. - Session was completely dead — no further interaction possible
- All tokens consumed by the 14 agents were billed to the user
Expected Behavior
- Context budget awareness: Before launching N background agents, Claude Code should estimate whether the returning results will fit in the remaining context window. If not, it should launch fewer agents or process results incrementally.
- Graceful degradation: When context is approaching limits, agent results should be summarized or truncated rather than causing a hard crash.
- Compaction should always work:
/compactfailing with "Conversation too long" is a dead end. If the conversation is too long, that's exactly when compaction is needed most. This is a catch-22.
- Token accountability: Tokens consumed by agents that cannot return results (because context is full) should not count against the user's quota, or at minimum the system should prevent this scenario.
- Agent launch limits: There should be a configurable or automatic cap on concurrent background agents to prevent context overflow.
Impact
- Token waste: 14 agents × ~50-80k tokens each = significant token consumption with no usable output
- Lost session: User cannot continue working, must start a new session
- Lost context: All prior conversation context (including earlier productive work in the same session) is inaccessible
- User pays for system failure: The user's subscription quota is consumed by Claude's own architectural limitation, not by the user's actions
Workaround
None available. Once the context overflows:
/compactfails/clearloses all context- The only option is to start a new session
Suggested Fixes
- Add a context budget check before launching background agents. Calculate:
remaining_context - (estimated_agent_results × num_agents) > safety_margin - Implement streaming/incremental agent processing — process each agent's result before launching the next, or cap concurrent agents at 3-4
- Fix
/compactfor oversized contexts — compaction should work especially when the context is too long, not fail because of it - Add a background agent limit — either hard cap or configurable setting (e.g.,
max_concurrent_agents: 4) - Implement result truncation — if an agent result would overflow context, summarize it automatically instead of crashing
Session Log
The full session transcript is available showing the exact sequence:
- 6 agents launched → 5 more agents launched → 3 more agents launched
- Agents completing with "Context limit reached" errors
/compactfailure- Session death
Total productive time before crash: ~25 minutes of successful code changes, then ~11 minutes of documentation attempt that killed the session.
7 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is exactly the scenario we kept hitting with agent teams. 14 parallel agents returning at once is a guaranteed session kill. We built cozempic to handle this — it runs a background guard that watches the session file for sudden size spikes and auto-recovers: prunes the bloat, preserves agent/team state, kills Claude, and resumes the session. Takes about 10 seconds vs a permanently dead session.
If you get a chance to test it, let us know if it helps — especially with that many background agents.
Related: #29957 proposes a proactive solution to this — topic-aware fork prompts to prevent context bloat, overflow-to-file recovery instead of data loss on compaction, and graduated warnings before the emergency. If this problem matters to you, a thumbs-up there would help consolidate the signal.
A PreToolUse hook can cap the number of concurrent subagents:
Settings:
Default limit is 5. Override with
CC_MAX_SUBAGENTS=3for tighter control.Install:
npx cc-safe-setup --install-example subagent-budget-guardThis won't fix the root cause (Claude Code should have native limits), but it prevents the cascade.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
14 background agents returning results simultaneously is a perfect storm for context overflow. Cozempic's guard daemon monitors context growth continuously, and the zombie-teams doctor check specifically detects runaway background agents before they kill the session.
pipx install cozempic && cozempic guard— https://github.com/Ruya-AI/cozempicThis 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.