[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

Status Open
Reported on v2.1.195
Maintainer reply None cached
Activity 3 comments · opened Jul 1, 2026

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

  1. 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).

  1. Do not give any prior context. Type a single short word as the first message

(e.g. "axiom").

  1. Observe Claude autonomously running a small number of tool calls (e.g. "Ran a

command, found files, read 2 files").

  1. Watch the conversation compact 2-4 times in quick succession, each saving

roughly 50-70k tokens, without the user sending any further messages.

  1. 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.

View original on GitHub ↗

3 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/60600
  2. https://github.com/anthropics/claude-code/issues/60485
  3. https://github.com/anthropics/claude-code/issues/59656

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

duidet-byte · 3 months ago

Root cause found (commenting to prevent auto-close — and because it may explain the linked duplicates too):

"autoCompactWindow": 100000 in 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 autoCompactWindow value in the message. A low value sitting in settings.json is otherwise invisible while producing exactly these symptoms.

LZong-tw · 1 month ago

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):

Agent terminated early due to an API error: 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. (error type invalid_request)

Scale observed in one working session (parallel code-builder agents in isolated git worktrees, medium effort, pnpm monorepo):

  • Orchestration run 1: 5+ of 6 agents terminated with exactly this error
  • Orchestration run 2 (same tracks, re-run): 6/6 terminated
  • 4 additional individually-resumed agents also terminated the same way
  • The parent session itself never thrashed — only spawned agents

Two aspects that make this worse than the interactive-session case:

  1. It is unrecoverable. The agent is killed mid-task (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.
  2. The remediation advice ("try reading in smaller chunks") is misdirected — we partially root-caused the refill and it was not the reads. The agents' prompts already instructed slice-reads (offset/limit, ≤128-line slices); they still thrashed. What we traced: in a monorepo with per-package CLAUDE.md files, a subagent's first Read under a package directory injects that package's (large) CLAUDE.md instructions 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.