[BUG] Autocompact thrashing: context fills within 2-4 turns of previous compact, reproducible with a single word on a fresh branch, persists across unrelated sessions/projects
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Autocompact repeatedly thrashes across many independent chats/branches on the same
project. At least 7 independent reproductions in one day across 7 differently-named
sessions. Cleanest repro: a brand-new chat on a fresh branch where I typed only the
single word "axiom" — nothing else — still hit three compactions and then a full
context wall:
"Ran a command, found files, read 2 files" -> compacted (61.9k saved)
-> "Ran a command, found files" -> compacted (71.9k saved)
-> "Ran a command, read a file" -> compacted (57.2k saved)
-> "Read a file, ran a command" -> "Your context window is full."
This rules out "large input/task" as the explanation. An unrelated MCP server was
suspected as a contributing factor and removed — thrashing continued identically
afterward, ruling that out too.
Suspected contributing factor: heavy fixed per-turn overhead in this environment —
project + global CLAUDE.md loaded together, several auto-injected memory files +
memory index re-injected every turn, multiple MCP servers/tools, several enabled
plugins, and a large set of deferred tool/agent definitions.
What Should Happen?
Claude Code should not reach "context window is full" from a single-word prompt on a
fresh branch. If fixed per-turn overhead (CLAUDE.md, memory injection, tool/plugin
definitions) is contributing to hitting the autocompact-thrashing threshold this
easily, that overhead should be reduced or the thrashing detector's threshold should
account for it.
Error Messages/Logs
Autocompact is thrashing: the context refilled to the limit within 3 turns of the
previous compact, 3 times in a row. A file being read or a tool output is likely too
large for the context window. Try reading in smaller chunks, or use /clear to start
fresh.
Steps to Reproduce
- Open a fresh Claude Code chat in a project with a large/complex CLAUDE.md file,
multiple auto-loaded memory files, several connected MCP servers, and a few
enabled plugins (this heavy fixed overhead may be a precondition — see "Suspected
contributing factor" above).
- Do not give any prior context. Type a single short word as the first message
(e.g. "axiom").
- Observe Claude autonomously running a small number of tool calls (e.g. "Ran a
command, found files, read 2 files").
- Watch the conversation compact 2-4 times in quick succession, each saving
roughly 50-70k tokens, without the user sending any further messages.
- After the last compaction, the session shows "Your context window is full" and
becomes unusable.
Reproduced independently 7 times in one day, across 7 differently-named
sessions/branches in the same project, with varying levels of user input (from a
single word up to normal multi-turn work).
Claude Model
Not sure / Multiple models
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.195 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Also noticed a side effect: because each new session branches from the same local
git state, unpushed local commits from earlier sessions get silently carried forward
into every subsequent new branch's diff — made it hard to tell "real prior work" from
"session noise" until git log origin/main..HEAD was checked manually.
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Root cause found (commenting to prevent auto-close — and because it may explain the linked duplicates too):
"autoCompactWindow": 100000in the global~/.claude/settings.json— the schema minimum. It caps the effective context window at 100k while the fixed session baseline (~64k of agent/skill/MCP descriptions in my setup) never compacts away, so every chat refills within 2–4 turns of the previous compact and thrashes. The desktop app bundles its own CLI but reads the same global settings.json, which is why it reproduced across all surfaces, sessions, and projects.Removing the line fixed it immediately — verified with
/context: baseline 63.8k / 1M, no thrashing since.Suggestion: when the autocompact-thrashing warning fires, surface the active
autoCompactWindowvalue in the message. A low value sitting in settings.json is otherwise invisible while producing exactly these symptoms.Adding a data point from 2.1.251 on Windows 11 where this failure mode is at its most destructive: background subagents (Task tool / Workflow agents) are terminated outright by the thrash detector, not just slowed down.
Failure text (verbatim, from task notifications):
Scale observed in one working session (parallel code-builder agents in isolated git worktrees, medium effort, pnpm monorepo):
Two aspects that make this worse than the interactive-session case:
invalid_request), all in-flight reasoning is lost, and hours of orchestration produce zero output. In an interactive session the human can/clear; a subagent just dies.offset/limit, ≤128-line slices); they still thrashed. What we traced: in a monorepo with per-packageCLAUDE.mdfiles, a subagent's first Read under a package directory injects that package's (large)CLAUDE.mdinstructions into the agent context, and at equal transcript size (~150-177KB) sonnet-tier subagents died with this error while default-model subagents doing the same work survived. So the kill threshold interacts with model tier + injected project instructions, exactly the misattribution pattern described in #85489 — no read strategy the agent adopts can save it.Feature ask: in subagent context, treat thrash as recoverable — drop the largest tool result and continue (or hard-truncate it) instead of terminating the agent; and report which item consumed the window so the misattribution question in #85489 becomes diagnosable.