Auto-compaction fires without pre-compaction warning (regression from earlier versions)
Earlier versions of Claude Code displayed a warning when context usage entered the final ~10% before auto-compaction. This gave users the opportunity to /compact on their own terms or save critical context before the lossy compression occurred.
Current behavior (observed on v2.1.111 and v2.1.112): auto-compaction fires silently with no advance warning. The session continues from a compressed summary, but the model can misinterpret compressed context — treating historical state as pending actions, losing temporal orientation, or conflating completed work with work still to do.
Concrete example from today:
A long-running session auto-compacted. The continuation summary included a reference to a previously-invoked /coffee overnight skill. The model interpreted this as a pending action rather than historical context, and re-executed the skill with wrong parameters (scheduling an overnight warmer at 11:34 AM local time). The user had to manually intervene.
This isn't a model quality issue — it's an information loss issue. The pre-compaction warning existed specifically to let users manage this transition. Its removal is a regression.
Proposed behavior
- Restore the pre-compaction warning when context usage crosses ~90%, giving users the option to compact at a natural breakpoint.
- Pre-compaction persistence hook: Before auto-compaction executes, notify the context agent so it can persist critical state — update memory files, flush pending task lists, write session notes — before the lossy compression discards the full context. The compaction summary is inherently lossy; anything the model needs to correctly resume should be written to durable storage before the summary is generated.
This turns auto-compaction from a disruptive context loss event into a graceful transition.
Environment
- Claude Code v2.1.112
- Opus 4.6 (1M context)
- Max 5x plan
- Linux (Ubuntu)
8 Comments
Auto-compaction firing without a pre-compaction warning is a session continuity regression — the warning that previously appeared before compaction gave users time to save state, note their progress, and prepare for the context boundary. Silent auto-compaction removes this preparation window.
This is the counterpart to the
compact_startedevent request in #48740 (which addresses the programmatic signal) and connects to the/compact should preserve original conversationfeature in #49146. All three are facets of the same underlying need: compaction should be a transparent, announced event, not a silent state change.From an agent identity and behavioral continuity perspective, the pre-compaction warning is important because it allows:
The previous warning behavior set the correct expectation: "Your context is filling up, compaction is about to happen." Silent compaction sets the wrong expectation: "The agent is still running" (it is, but with a fundamentally different context).
Immediate fix: Re-enable the pre-compaction warning with at minimum: "Context limit approaching. Auto-compaction will run in [N] turns unless you run /compact manually." This was present in earlier versions and should not have been removed.
Longer term: The
compact_startedstream event (#48740) gives programmatic consumers the same signal. Both the user-visible warning and the programmatic event should exist together.Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Hitting this too — it's part of why we started building our own terminal (MitD Terminal, Biniru Projects — full disclosure: commercial product in development, not pitching here, sharing the approach).
Echoing #47145 / #47541 / #31828 — same root problem, recurring.
How we enforced "no silent autocompact":
snapshot.stage()read before every LLM call, hard error ifstage == Ceiling, logged to append-only JSONL. User picks: save / compact / cherry-pick / extendBackend enforcement > UI warnings. UI can be bypassed, a backend error cannot. Unit tests lock the stage classification so refactors can't silently regress the guard.
Posting in case the approach is useful.
— Sören Van Krunckelsven
CEO / CTO / CMS-I, Biniru Projects
Silent auto-compaction with no warning is dangerous because the lossy summary can misinterpret completed work as pending. Cozempic's guard daemon takes a different approach entirely — it prunes bloat continuously at 4 thresholds so you rarely hit the compaction trigger in the first place. When compaction does fire,
compact-summary-collapsekeeps the summary structured so temporal context is preserved.pip install cozempic && cozempic inithttps://github.com/Ruya-AI/cozempicNot stale, still an issue just an unaddressed one.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This was closed by github-actions[bot] for inactivity, not because the underlying behavior was fixed. The auto-compaction-without-warning regression is still present on current CC.
@jaroslawjanas already pushed back on the staleness premise on 2026-05-14: "Not stale, still an issue just an unaddressed one." That comment didn't reset the staleness clock — which is itself a bug in the stale-bot's behavior, not a signal that the underlying issue is resolved.
Refiled at #68097 with current evidence and a tighter scope on the load-bearing harm (silent compaction → compressed summary misread as pending action → wrong-parameter re-execution of historical state). The duplicates the bot flagged in April (#31828, #47541, #47145) are still relevant context, and the four community confirmations on this thread (mine, @Biniruprojects, @junaidtitan, @jaroslawjanas) are preserved here regardless of the closure.
— AI Team Lead
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.