Autocompact-thrashing warning blames "a file or tool output" when the refill came from re-injected project instructions

Type: bug

Environment

• Claude Code version: 2.1.220 (first diagnosed on an earlier 2.1.x build)
• OS: macOS 26.5.2 (Darwin 25.5.0)
• Platform: Claude subscription
• Model: claude-opus-4-8 / claude-opus-5

What happened

Sessions in projects that carry a large auto-loaded instruction set (.claude/rules/*.md plus CLAUDE.md) enter a compaction loop: the context refills to the limit within a few turns of every compact, and the session eventually stops making progress. The harness emits:

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

That diagnosis was wrong in every case we investigated. We scanned for oversized single payloads and found none — no file read and no tool output was large. What refilled the context was the harness re-injecting the project's instruction files as attachments after each compaction (and on user prompts). In the worst measured case a 248 KB instruction directory produced roughly 122 K tokens of re-injection in a single turn, on top of a ~198 K-token post-compact residue — which lands exactly on the compaction trigger, producing an immediate next compaction. That session recorded 16 compactions in 1 h 48 min with almost no forward progress, and 130 re-injections totalling ~3.9 MB.

The warning appears in 30 transcript files here. On one day, two sessions ended permanently at this warning — the last entry in each transcript is the warning itself, followed by zero activity.

Expected

1. The warning should attribute the refill. When the harness detects thrashing it already knows what refilled the window; a per-category breakdown ("instruction re-injection: N tokens; tool results: M tokens; file reads: K tokens") would point at the real cause. As written, the message sends users to optimize the one thing that was not the problem.
2. Unchanged instruction files should not be re-sent verbatim after every compaction. Re-injecting a byte-identical instruction set that is already summarized in the compact output is the loop's engine. A digest/reference, or re-injection only on change, would break it.
3. Thrashing should degrade gracefully instead of ending the session silently. Right now the session can simply stop.

Repro

1. Create a project with a .claude/ instruction directory in the low hundreds of KB (this is easy to reach with an append-only conventions or anti-pattern document).
2. Run a long editing session in that project until auto-compaction fires.
3. Inspect the session transcript: locate compactMetadata entries, then read usage.cache_creation_input_tokens on the first turn after each compaction — this is the size of the re-injection.
4. Observe the compaction interval collapsing and the thrashing warning appearing, with no oversized read or tool result anywhere in the session.

Impact

Highest single-run token loss we have measured, and it is self-inflicted overhead rather than work. The misleading warning text meaningfully extended the time to diagnose — the true cause was only found by measuring the post-compaction context jump directly.