Context Limit Reached error should auto-compact and queue user message instead of failing

[cosmicflow-space]

Description

When running long sessions with multiple parallel background agents (Task tool with run_in_background: true), sending a user message (especially with a screenshot attachment) while agents are still running throws a "Context Limit Reached" error instead of gracefully handling it.

This is on a Max plan — not a billing or rate limit issue. The model's context window is exhausted by accumulated agent results.

Expected Behavior

1. User sends a message while agents are running
2. System detects context is near/at limit
3. System auto-compacts (summarizes prior messages)
4. User's message is queued and processed after compaction
5. Session continues seamlessly

Actual Behavior

1. User sends a message while agents are running
2. System throws "Context Limit Reached" error
3. User cannot send any further messages
4. /compact may also fail with the same error
5. Only option is /clear — which loses all conversation history, agent results, and work in progress

Reproduction Steps

1. Start a Claude Code session (Opus 4.6, Max plan)
2. Launch 4-6 parallel background agents using the Task tool (e.g., SEO audit with 6 specialist subagents)
3. While agents are running and returning results, send a new user message with a screenshot attachment
4. Observe "Context Limit Reached" error

Root Cause Analysis

From investigating a crashed session (46MB JSONL transcript):

• 274 user messages averaging 164KB each
• 12 messages over 1MB, 39 over 100KB
• 97.5% of context came from subagent results returned as user messages
• The Task tool returns agent output as user-visible messages, which accumulate rapidly

Impact

• Loss of work: Hours of multi-agent analysis lost when /clear is the only recovery
• No recovery path: /compact fails with the same error, creating a dead-end state
• Session state destroyed: TaskList, agent results, conversation history — all gone
• Workaround burden on users: Must manually track when to /compact, which defeats the purpose of autonomous agent workflows

Suggested Solutions

Priority 1: Graceful degradation

When context limit is approaching:

• Auto-trigger compaction before the hard limit is hit
• Queue the user's pending message
• Process the queued message after compaction succeeds

Priority 2: Pre-emptive compaction

• Add a threshold (e.g., 80% of context window) that triggers automatic compaction
• Or add a hook event like PreContextLimit that fires before the hard limit

Priority 3: Agent result management

• Task tool results from background agents should not expand into full user messages
• Consider: agent results as compressible system messages, or file-based result passing where agents write to disk and parent reads files

Current Workarounds

We've implemented partial mitigations via hooks and CLAUDE.md instructions:

• SubagentStop hook reminds to /compact after agent work
• PreCompact hook preserves critical context
• All custom skills use file-based result passing (agents write to files, return only brief summaries)
• But none of these prevent the hard crash when a user message arrives during heavy agent work

Environment

• Plan: Claude Max (Opus 4.6)
• Platform: macOS (Darwin 25.2.0)
• Claude Code version: Latest as of Feb 2026
• Model: claude-opus-4-6

[cosmicflow-space]

[github-actions]

Found 3 possible duplicate issues:

1. TaskOutput burst polling causes unrecoverable 'Prompt is too long' when multiple background agents complete simultaneously #24341
2. InboxPoller delivers queued messages without context budget check, causing unrecoverable context overflow #23876
3. Background task output polling blocks /compact requests, consuming entire context window #24220

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[piwi3910]

these are not duplicates, and or different issues.

[Notum]

I can confirm this bug and currently working with claude code as an agenting development is just impossible.
Agents context window is shared between agents and main claude code context:

● Agent "Create Certifications migration+model" completed
⎿ Context limit reached · /compact or /clear to continue

● Agent "Add CRS org settings migration" completed
⎿ Context limit reached · /compact or /clear to continue

● Agent "Create CRS models and migration" completed
⎿ Context limit reached · /compact or /clear to continue

● Agent "Add Authorization access matrix" completed
⎿ Context limit reached · /compact or /clear to continue

● Agent "Auth routes, controller, sidebar" completed
⎿ Context limit reached · /compact or /clear to continue

This I got in same moment.

[sarob]

i have been getting these msg in prompts over the past couple of days

• Image base64 size (5.0 MB) exceeds API limit (5.0 MB). Please resize the image before sending.
• prompt is too long
• they are starting to impact my ability to work as I am regularly losing the conversation history. updating a plan markdown file is a workaround, but it is slowing me down.
• when I try to report these bugs, the Fin AI Agent regularly hallucinates and tries to get me to use non-existing methods to report bugs, e.g. use /doctor or /bug or /debug within claude code.
• when I ask for a human to help, I get a boilerplate we will email you and then nothing else. The communication stops. No more chat and no email that anything will happen.
• I like the claude code tooling, but this is a poor experience with little hope of being repaired.
• I am posting here as a last ditch option of getting any type of support

[sarob]

Since losing conversation history was a recurring problem for me, I built a bash dashboard to track all Claude Code operational files (CLAUDE.md, MEMORY.md, conversation logs) across projects. It helps you see what Claude knows per project and clean up old session logs.

Zero dependencies, single script: https://github.com/sarob/claude-ops