Claude Code Stuck on "Compacting"? How to Fix It
By Neo Zino - builder of ClockedCode9 min readClaude Code stuck on "Compacting" past a minute or two is one of three documented failure modes, not normal auto-compact - here is the fix for each.
Made with DispatchSEO
On this page
Claude Code stuck on "Compacting conversation…" past a minute or two on a normal-sized session isn't ordinary auto-compact working slowly - it's one of three documented failure modes, and the fix depends on which one you're looking at. Anthropic's own troubleshooting docs name one of them outright ("Autocompact is thrashing"); the other two show up as real bug reports on the Claude Code GitHub repo, each with a different real cause and a different real fix.
TL;DR: Normal compaction is one request that finishes in seconds to a couple of minutes. Past that, check for the exact "Autocompact is thrashing" error first (there's an official fix: chunk the file, focused
/compact, a subagent, or/clear). No error but the same files keep getting re-read with no progress is a separate, still-open bug (GitHub #6004) - interrupt and narrow the task. A completely frozen terminal where Ctrl+C does nothing is a third bug (GitHub #19567), sometimes caused by a Homebrew package shadowing macOS'spgrep/pkill- close the terminal,claude --resume, and kill any orphaned process.
What normal auto-compact looks like
Auto-compact fires on its own once your context nears the limit for whatever model you're running, so the session can keep going instead of hitting a wall. Under the hood it's just one more request to the API, built from your conversation so far with a summarization instruction added at the end, so most of what it's sending has already been cached. That's the whole reason it's normally fast: a couple of minutes at most, even on a session that's been running for hours, and then a normal response on your very next message. ClockedCode's fuller breakdown of auto-compact covers the settings that move that trigger earlier or later and what the generated summary actually keeps - worth reading once this specific problem is sorted.
- The spinner runs for anywhere from a few seconds to a couple of minutes on a large conversation
- It stops on its own and your next message gets a normal response
- CLAUDE.md, memory, and your recent files reload without you asking
- An explicit "Autocompact is thrashing" error appears instead of finishing
- The same tool calls (often the same files) repeat with no new output for several minutes
- Ctrl+C does nothing and the terminal stays blank
The three documented ways compaction actually breaks
None of this is guesswork pieced together from a forum thread - one failure mode is named in Anthropic's own docs, and the other two are open, reproducible bug reports on the anthropics/claude-code repo with real environment details attached.
Three documented failure modes, not one vague "it hangs sometimes"
Thrashing
code.claude.com, official
"Autocompact is thrashing: the context refilled to the limit..." - a file or tool output refills context right after each summary.
Read the oversized file in chunks, run /compact with a focus that drops it, delegate it to a subagent, or /clear.
Infinite compaction loop
GitHub issue #6004
Claude re-reads the same files, attempts to compact, then restarts the same read - no error, no progress, and usage limits drain faster than usual.
No official fix yet; interrupt and restart with a narrower task, or split the work so fewer files need to stay in context at once.
Hang with an orphaned process
GitHub issue #19567
The terminal goes completely unresponsive and Ctrl+C does nothing; a claude process with PPID 1 keeps running and consuming CPU/RAM after you close the window.
Close the terminal, then `ps aux | grep claude` and `kill -9` the orphan. One reported cause: a Homebrew proctools install shadowing macOS's own pgrep/pkill - run `PATH="/usr/bin:$PATH" claude` to rule it out.
Source: code.claude.com/docs/en/troubleshooting plus GitHub issues #6004 and #19567, checked 2026-09-06.
| Failure mode | Where it's documented | What tells them apart |
|---|---|---|
| Thrashing | code.claude.com troubleshooting page | Explicit error text naming the problem |
| Infinite compaction loop | GitHub issue #6004 | Same files re-read repeatedly, no error, usage drains fast |
| Hang / orphaned process | GitHub issue #19567 | Terminal fully unresponsive, Ctrl+C does nothing |
The thrashing error is the one Anthropic has actually built a response for: it fires when a single file or tool output refills context back to the limit several times right after compaction finishes, and Claude Code deliberately stops retrying instead of burning API calls on a loop that isn't going anywhere. The other two are real, filed bugs rather than documented behavior - which is exactly why generic "just wait it out" advice floating around for this query doesn't hold up for all three cases equally.
What to do right now, in order
In order, cheapest fix first
Press Ctrl+C once
Cancels the current operation if anything is still listening
Run /compact with a focus
"/compact keep only the plan and the diff" drops the output that's refilling context
Run /clear if the history isn't worth keeping
Costs nothing and skips compaction entirely for the next message
Close the terminal and run claude --resume
Picks the same session back up - closing the window doesn't lose it
Run /doctor, then /feedback if it's still wrong
Checks your setup first, then reports the exact session to Anthropic
One command on that list deserves more detail: instead of the bare /compact, tell it what to protect - /compact keep only the plan and the diff or /compact focus on the failing test output - since custom instructions replace Claude's default summarization prompt rather than adding to it. If you'd rather not lose the earlier conversation at all, ClockedCode's checkpoints guide covers /rewind, which can jump to a point before things went sideways and summarize from there instead of gambling on the automatic pass finishing cleanly.
When a checkpoint beats waiting it out
If a session has already thrashed once, restarting it with the same oversized context just sets up the same collision again. /rewind (or double-tapping Escape) opens the same checkpoint menu Claude Code uses for course-correcting a bad edit, and one of its options is "Summarize from here" - which is a manual compact aimed at a point you pick, rather than wherever the automatic trigger happened to land when the large file was still in context. That's a materially different starting point than letting auto-compact try the exact same request again and hoping the thrashing guard doesn't trip a second time.
Checking how close you are to the trigger before it becomes a problem is worth doing on any long session - the context usage checker reads the same numbers /context shows without you needing to interrupt what you're doing to run the command.
Reporting it as a bug
The thrashing error is expected, documented behavior with a real fix - it doesn't need a bug report. The other two do, and Claude Code has a built-in path for it: run /feedback from inside the stuck session (or the one right after you recover from it) to send the exact conversation to Anthropic. If memory usage is part of what you're seeing - the orphaned-process report in issue #19567 measured 11.8 GB of RAM held by a single hung claude process - /heapdump writes a JS heap snapshot and a diagnostics file to your desktop that's safe to attach to a GitHub issue (the diagnostics file specifically; the heap snapshot contains your full conversation and shouldn't go in a public report). Search the GitHub issue tracker for your exact symptom first - both bugs referenced here already have open threads, and a 👍 or a comment with your environment details is more useful to Anthropic than a fresh duplicate.
When it isn't compaction at all
A session that looks frozen isn't always compacting - it can be sitting on a slow tool call, a hung MCP server, or a long-running Bash command with no output yet, all of which show the same "nothing is happening" symptom without the word "Compacting" ever appearing. Run /doctor first if you're not sure what's actually stuck; it checks your installation, settings, extensions, and context usage in one pass and proposes fixes before you assume compaction is the culprit at all.
Honest limits here
Two of the three failure modes on this page - the infinite loop and the hang - don't have an official Anthropic fix as of this page's last check. The workarounds above (narrower tasks, checking for a shadowed pgrep/pkill, killing an orphaned process) come from what worked in the reported threads, not from documented, guaranteed behavior the way the thrashing error's fix is. If none of them clear your specific case, /feedback and the GitHub tracker are the actual path to a fix, not another restart.
FAQ
What does "stuck on compacting" actually mean in Claude Code?
It means the "Compacting conversation…" spinner is still running well past the point where normal auto-compact finishes - normal compaction is one summarization request that takes seconds to a couple of minutes on a large conversation. Past that, you're looking at one of three documented failure modes: a thrashing error, an infinite compaction loop, or a full hang, and each has a different fix.
How long should normal auto-compact take?
From a few seconds up to roughly a couple of minutes for a very large conversation, since it's a single request built from your existing history plus a summarization instruction and reads from your prompt cache instead of reprocessing everything. It should always finish and hand a normal response back on your next message. If it doesn't, treat it as stuck rather than waiting indefinitely.
What does the "Autocompact is thrashing" error mean and how do I fix it?
It's an official, named error: compaction succeeded, but a file or tool output immediately refilled the context window back to the limit, several times in a row, so Claude Code stopped retrying rather than burn API calls on a loop making no progress. Fix it by asking Claude to read the oversized file in smaller chunks, running /compact with a focus that drops the large output, delegating that piece of work to a subagent, or running /clear if the earlier conversation isn't worth keeping.
Why does compacting seem to loop forever with no error message at all?
That matches a documented GitHub bug report (issue #6004): Claude re-reads the same handful of files, attempts to compact, and restarts the same read pattern with no error and no progress, while usage limits drain faster than normal. There's no official fix yet - interrupt the session and restart with a narrower task, or split the work so fewer files need to stay in context at once.
Claude Code is completely frozen and Ctrl+C doesn't do anything - what do I do?
Close the terminal window; per Claude Code's own troubleshooting docs, that doesn't lose your conversation, and claude --resume in the same directory picks the session back up. If the process won't die, check for an orphaned claude process with ps aux | grep claude and kill -9 it - a real GitHub report (issue #19567) traced this exact hang to a Homebrew proctools install shadowing macOS's native pgrep/pkill, fixed by running PATH="/usr/bin:$PATH" claude.
Does a stuck compaction count against my usage limit?
Compaction itself is a real request - it reads the conversation it's summarizing - so it does draw on your usage the same as any other turn, and a session that's thrashing or looping burns through that budget faster than normal use would. That's a different question from whether it counts against a spend cap or rate limit in the way a 429 does; if usage is disappearing unusually fast, treat a stuck compaction as the likely cause and interrupt it rather than let it keep running.
One spinner, three different bugs
The word "stuck" covers three genuinely different problems here, and the fix for one won't touch the other two - which is the main thing generic advice about this error gets wrong by treating it as one issue with one answer. Confirm which of the three you're actually looking at before you start restarting sessions or killing processes, and if you land on one of the two that Anthropic hasn't fixed yet, /feedback does more good than another retry. ClockedCode's context-window breakdown covers the proactive side of the same problem: keeping a session small enough that it rarely reaches the trigger in the first place.