/compact fails with 'Conversation too long' when context limit is reached

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/22418
2. https://github.com/anthropics/claude-code/issues/21853
3. https://github.com/anthropics/claude-code/issues/22051

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

I can confirm this regression. My workflow has been processing book content (reading 10-20+ chapter files,
synthesizing notes) reliably for hundreds of books over the past weeks as I use it to take notes on ebooks I want to read.

This morning (Feb 4), the same workflow started hitting context limits and /compact fails to recover. I've tried:

• Multiple fresh sessions
• Restarting Claude Code
• Restarting my PC entirely

Same result each time - context fills up and /compact doesn't help, forcing /clear which loses all work progress.

Environment:

• Claude Code version: 2.1.31
• Platform: Linux (WSL2)
• Model: Opus 4.5

Workflow that broke:

• Reading 5-10 book chapter files sequentially
• Previously handled 10-20+ files per session with no issues
• No changes to my configuration of the slash command I created or CLAUDE.md

This started immediately after updating to recent versions. The timing aligns with the v2.1.30 session memory changes.

Mine either fails because 'Conversation too long', or doesn't even do anything and just stays idle, always showing 0 tokens consumed.

In summary I can't even compact the conversation at all at this point, not even restarting CC like when the 'Conversation too long' issue appeared in the past. I have to always start a new session from scratch, honestly this sucks badly.

Same issue

❯ /compact
⎿ Error: Error during compaction: Error: Conversation too long. Press esc twice to go up a few messages and try again.

model: Sonnet 1M context

Additional severity report: In some cases this is worse than just /compact failing — the app becomes completely bricked.

When context limit is reached with a sufficiently large conversation (heavy CLAUDE.md + many skills + MCP servers):

1. All messages blocked: "Context limit reached"
2. /compact fails: "Conversation too long"
3. Rewind (Esc twice) fails: "Conversation too long"
4. /clear is also blocked — the context limit gate blocks ALL input, including recovery commands
5. No way to exit the screen — user must force-kill the terminal process

This is not just data loss from /clear — it's a complete app freeze requiring kill/Ctrl+C/close terminal.

Screenshot from my session showing the deadlock: https://github.com/anthropics/claude-code/issues/23809

Environment: macOS, latest Claude Code, large project with extensive CLAUDE.md, 30+ skills, and MCP servers.

Experiencing the same issue — Claude Code in VS Code integrated terminal

Hitting this exact same compaction deadlock on Claude Code 2.1.32, running Opus 4.6 inside the VS Code integrated terminal on the batch-processor branch of a medical imaging application project.

❯ /compact
  ⎿  Error: Error during compaction: Error: Conversation too long. Press esc twice to go up a few
     messages and try again.

Environment:

• Claude Code: 2.1.32
• Model: Opus 4.6
• Context usage at time of failure: 74% (604,765 tokens)
• Context left until auto-compact: 11%
• Session: 16 files changed, +800 -303
• Platform: VS Code integrated terminal

The session becomes completely unrecoverable after this error. The "press esc twice" suggestion does nothing. Auto-compact also fails to trigger before the context reaches this broken state.

This is a critical workflow blocker — the tool is unusable for any non-trivial session that runs long enough to need compaction, which is exactly the scenario where it's needed most.

lol, back to 2.0.65 for me; I finally upgraded (stopped following stable when they removed the Tab thinking toggle) for 4.6, but this bug isn't worth it

curl -fsSL https://claude.ai/install.sh | bash -s 2.0.65

EDIT: Steps I took for recovery, for any unlucky souls who are facing a bricked session

1. Go back to 2.0.65 (verify with claude --version after)
2. /status in the bricked session to get your session ID
3. Run this command to find the path to the main jsonl (which has one line per message (ish))

rg --files-with-matches <broken session> ~/.claude/projects/ | xargs wc -l | sort -k2

1. Use a prompt like this to get started again

On a different version of `claude`, I was just having a conversation but ran into a bug wherein `/compact` failed completely and many community members are complaining
about it. Read through `<path>.jsonl` to recover context, then
carry on with the latest request:
<paste your last message from the old terminal>

EDIT 2: Forgot to add this because _I_ forgot, add this to your ~/.claude/settings.json to make the downgrade stick:

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  },
}

this github-actions bot in this repo is unhinged. makes users go around in circles endlessly from one issue to another. its impossible to reach the issue that is not a duplicate, if all others are. scatters community attention needlessly.

saaame

Same here

I have hit the exact same issue on version 2.1.39. This is one of the worst bugs the app could possibly have. It makes long running sessions impossible. This needs to be fixed ASAP.

Up Up

Hey folks, we've made some fixes to help with this bug - which will go out in the next release after 2.1..42 (has not been released at time of posting this comment). Going to keep this open until I've receive confirmations that it's fixed.

If you still run into this please /bug and send me your feedback ids. Makes it much easier to debug

Adding my voice here. Max subscriber, Opus 4.6, macOS, 600+ sessions.

We hit this exact deadlock during a 72-hour client sprint — three concurrent 1M context sessions all rate-limited simultaneously. Couldn't compact any of them because compaction requires an API call, which was rate-limited. Filed #26575 about the rate-limit variant of this same deadlock.

What saved us: we'd already built a persistent state system (memory files on disk that the agent writes to continuously, not just at session end). When compaction nukes working memory, our agent can reconstruct from disk. Without that, we'd have lost hours of creative decisions, client corrections, and technical state. We built it because we got burned enough times.

fadedlamp42's recovery procedure (downgrade + JSONL recovery) is the kind of thing that should be in official docs.

The fundamental issue is what Memphizzz described in #18027 — the agent can't see its own fuel gauge. If it could, it would save state before the crisis, and the deadlock wouldn't matter because the important context would already be on disk.

Appreciate everyone documenting this so clearly. The regression identification (broke around Feb 4 / v2.1.30) and the 74% trigger (russ2370) are both really useful data points.

This issue is very much not fixed, still getting this constantly, nearly every single longer conversation I have with Claude Code/Opus I run into this multiple times and either have to go REALLY far back in the history or start over and waste a ton of tokens reexplaining everything.

FWIW, on standard context, I am able to work around this Catch-22 by adding context, running compact, then reverting to the previous standard content, if desired. /model sonnet[1m] still works when you're stuck in this loop, but of course adds to your pay-as-you go.

Of course, if you're already at 1m, this doesn't help.

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.

Environment:

• Claude Code on WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2)
• Model: Opus 4.6
• Long-running sessions with complex SQL/PL/pgSQL work (PostgreSQL migration toolkit)

Experience:
/compact failed 5+ consecutive times with:

Error: Error during compaction: Error: Conversation too long. Press esc twice to go up a few messages and try again.

Auto-compaction also did not trigger. The session was completely stuck — no way to continue, no way to compact. The only option was /clear, which lost the entire session context including a pending request for a summary of work done.

Pressing Esc twice as suggested in the error message had no effect.

This is a workflow blocker for any non-trivial session. The compaction mechanism needs to work precisely when conversations are long — that's its entire purpose.

Adding a +1 and a specific use case that I think sharpens the "natural break" framing:

The most impactful version of this feature, from a UX perspective, is compaction triggered immediately after Claude finishes delivering a response — not before the next user message, not mid-tool-chain, but in the ~5–30 seconds while the user is reading the response they just received.

Why the timing matters as much as the threshold:

The current experience in long sessions:

User sends message
Claude starts responding
Context limit hit → compaction interrupts → user waits
User gets response, already frustrated
The desired experience:

User sends message → Claude responds fully
[background: context at 80% → compaction runs while user reads]
User types next message → context is already clean, no wait
The user is always reading after a response. That's the only moment in the conversation where they're guaranteed to not be waiting on Claude. Using that window for compaction is zero-cost from a perceived latency standpoint.

Proposed settings.json:

{
"autoCompactThreshold": 0.80,
"autoCompactTiming": "after-response"
}
after-response would mean: once the final token of a response is delivered, if context usage exceeds autoCompactThreshold, begin compaction in the background. Queue the next user message until compaction completes (which by then may already be done).

This pairs naturally with the "Compact at next natural break" mode described in the original issue — I'd just argue the break should be after delivery, not before the next prompt.

This is a duplicate of #2038, which was fixed as of version 2.1.85.

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.