[BUG] Auto-compaction fires without pre-compaction warning — silent context boundary causes summary-as-pending-action re-execution (regression from earlier versions)

Preflight Checklist

• [x] I have searched existing issues — original filing #50015 was closed today by github-actions[bot] for inactivity, not because the bug was fixed. Adjacent reports #31828, #47541, #47145 still open or similarly stale-closed. This refile uses current binary evidence on CC 2.1.148+ with a tighter scope on the load-bearing harm.
• [x] This is a single bug report
• [x] Reproduced on Claude Code 2.1.148

What's Wrong?

Earlier versions of Claude Code displayed a pre-compaction warning when context usage crossed ~90%. That warning gave users a deliberate window to /compact at a natural breakpoint, persist critical state, or save session notes before the lossy compression of auto-compaction discarded the working context.

Current behavior (verified through 2.1.148): auto-compaction fires silently with no advance warning. The session continues from a compressed summary, and the compressed summary is consistently misread by the next assistant turn — historical state is treated as pending action, completed work is conflated with work still to do, and any in-progress instruction from before the compaction boundary can be re-executed against new parameters.

Concrete failure shape (from the original report, still applicable)

A long-running session auto-compacted. The continuation summary referenced a previously-invoked /coffee overnight skill from earlier in the conversation. The model interpreted this as a pending instruction rather than as historical context, and re-executed the skill — scheduling an overnight warmer at 11:34 AM local time (the user's actual context was mid-morning workday, with no overnight intent). The user had to manually intervene.

This is not a model-quality issue. It is an information-loss-at-the-summary-boundary issue. The pre-compaction warning existed specifically to let users manage that boundary. Its removal converts a previously-survivable transition into a class of session-state corruption that is invisible until the next turn fires the wrong action.

Why this matters more in 2026 than it did in April

Three things have changed since the original filing eight weeks ago:

1. Newer models cost more per token. Re-execution of a misinterpreted historical instruction now burns Fable or Opus 4.8 quota, not Opus 4.7 quota. Same bug, larger per-incident bill.
2. Auto-resume is firing more aggressively. Per CC#66728 (occurrence 6, 2026-06-12), the product's own auto-resume mechanism can drive a session into action on first reconnect with zero user input. A session that auto-resumes into a compaction-boundary misread can produce wrong actions before the user is at the keyboard.
3. Skills and /coffee-style scheduling have proliferated. Skills that schedule work (warmers, watchers, batches) are exactly the class most damaged by historical-state re-execution. The 11:34 AM overnight-warmer example was almost benign; the same shape on a deploy skill, a billing skill, or a destructive-rm skill is not.

Proposed behavior

1. Restore the pre-compaction warning when context usage crosses ~90%, giving users a window to compact at a natural breakpoint with full context still present.
2. Pre-compaction persistence hook. Before auto-compaction executes, notify any registered context/state-management hook so it can flush durable state — memory files, pending task lists, session notes — before the lossy compression generates its summary. Anything the next turn needs to correctly resume should be written to durable storage before the summary exists, not inferred from it.
3. Distinguish historical context from pending action in the summary itself. The compaction summary should mark prior tool invocations explicitly as historical, not as items in the working set the next turn can act on. This is the closest thing to a pure fix the summary mechanism can provide.

Together these convert auto-compaction from "session loses information silently and the next turn acts on the loss" into a graceful, observable transition.

Adjacent context

• cache-fix ships a read-only session-health extension that warns operators about the thinking-desync wedge (upstream #63147) approaching, but that's a different compaction-adjacent problem (re-sent omitted-thinking blocks wedging on retry, not summary-as-pending-action). It doesn't address the harm in this report.
• @jaroslawjanas's 2026-05-14 "not stale, still an issue, just unaddressed" comment on #50015 is the cleanest community signal that the bug persists.
• Community confirmations on the original thread: @Biniruprojects (MitD Terminal), @junaidtitan (Cozempic), @jaroslawjanas. All four hit the same underlying bug from different stacks.

Environment

• Claude Code v2.1.148 (current pinned on visits-01); behavior also observed on 2.1.112 (original filing) and intermediate versions
• Models: Opus 4.6 (1M context), Opus 4.7, Fable 5
• Max 5x and Max 20x plans
• Linux (Ubuntu)