claude-code - 💡(How to fix) Fix [FEATURE] Auto-signal context compaction + recommend state refresh after /compact

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Fix Action

Fix / Workaround

Current workaround (manual): User manually prompts the assistant with "check what we currently have" / "reload last project docs" after suspecting a compaction. Works but requires the user to: (a) notice the symptom of slow-reflex output, (b) know that compaction is a recoverable issue, (c) remember the prompt that triggers state refresh.

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

After a /compact event in a Claude Code session, the assistant receives a summary of prior context but has no mechanism to notify the user that compaction just occurred. This creates a silent failure mode where the assistant may default to general industry knowledge instead of project-specific state — risking accuracy regression that's invisible to the user until it's already caused a bad recommendation.

Long-session users on deep technical work (multi-hour pairing on a single project) are exactly the population where compaction happens repeatedly. The user has no signal that the compaction event occurred — the assistant just... continues, sometimes with degraded accuracy.

Concrete example from a real session: ~1M+ tokens compressed mid-session on a deep technical project (custom telemetry pipeline backed by Qdrant). Post-compaction, the assistant proposed adding a Postgres table for telemetry — despite the project explicitly using Qdrant for all similar data, documented in project notes and the codebase. The slow reflex was only caught when the user asked "why Postgres?". Without that pushback, the recommendation would have shipped.

The root issue: compaction is detectable server-side, but currently invisible to the user. There's no opportunity for the user to verify state before the assistant continues with potentially-degraded context.

Proposed Solution

Three increasingly-helpful options (any one alone would help):

Option 1 — System reminder after compaction (smallest change): inject a one-time reminder telling the assistant "context was just compacted; consider asking the user whether to refresh state references before making architectural recommendations". The system reminder mechanism appears to already exist (e.g., TodoWrite nudges) — this would be a similar pattern.

Option 2 — Auto-flag from assistant (preferred user-facing option): after compaction, the assistant should preface its first substantive response with something like:

"Note: I just compacted context. If we're continuing a long-running technical thread, I can re-read recent docs / working files / MCP state before recommending. Want me to do that?"

Option 3 — New slash command /refresh (user-controlled, complementary): forces the assistant to dump current known state — what docs it knows about, what files it has referenced, what project decisions it recalls — before continuing. Useful as a sanity check at any point, not only post-compaction. The name /refresh appears free; /reload-plugins is the only similarly-named built-in and targets a different concern.

Alternative Solutions

Current workaround (manual): User manually prompts the assistant with "check what we currently have" / "reload last project docs" after suspecting a compaction. Works but requires the user to: (a) notice the symptom of slow-reflex output, (b) know that compaction is a recoverable issue, (c) remember the prompt that triggers state refresh.

None of those are baseline user knowledge.

Competing tools: Don't know of mainstream tools that explicitly handle this. The closest analogues are git's git status (shows current state explicitly) and :checkhealth in Neovim (verifies plugin state). Both serve the same purpose — give user visibility into invisible state.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

Scenario: 4-hour pairing session on a custom telemetry pipeline. Around hour 3, conversation accumulates ~1M tokens. /compact runs (either auto-triggered or manual). Assistant gets summary.

Without this feature (current):

  1. User asks "what's next?"
  2. Assistant proposes "add a Postgres table for the new event log"
  3. User (knowing the project): "why Postgres? we use Qdrant everywhere"
  4. Assistant verifies, agrees, pivots to Qdrant
  5. 5 minutes lost on misalignment that was preventable

With this feature (proposed):

  1. User asks "what's next?"
  2. Assistant prefaces: "Note — context just compacted. Want me to re-read recent project decisions before recommending?"
  3. User: "yes"
  4. Assistant re-reads relevant project docs / files
  5. Assistant proposes a Qdrant collection — aligned with project conventions
  6. Zero misalignment

Additional Context

Related issues (not duplicates — different scope):

The following open issues document bugs around compaction behavior, complementary to this feature request which addresses the UX gap of users not knowing compaction occurred:

  • #60947 — malformed request after twice-compacted session (data corruption post-compact)
  • #60900 — auto-resume after compaction starts tasks before user instruction (too much automation)
  • #60603 — list item ordering corrupted by compaction
  • #60542 — /compact leaves session inconsistent on mid-execution failure
  • #60526 — remote control session lost after compaction

None of these address the notification gap. This feature request is the proactive UX layer that complements those bug fixes.


Note on authorship: This feedback was co-written with Claude Code (Opus 4.7) during a real working session that itself experienced the compaction issue described above. The Postgres/Qdrant example is from this same session — caught and discussed in real-time, then surfaced as a pattern worth fixing at the platform level. Submitted on behalf of both parties.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING