C:/Program Files/Git/compact leaves session in inconsistent state when it fails mid-execution (e.g. rate limit)

Resolved 💬 3 comments Opened May 19, 2026 by tshetke Closed Jun 18, 2026

Summary

When /compact fails partway through (in my case, hitting a usage limit during compaction), the session resumes in a chaotic half-compacted state instead of cleanly rolling back or completing. The next turn sees a flood of replayed <system-reminder> blocks for tool calls from before compaction, the post-compaction summary, and any new user messages, all at once — and the agent has no coherent way to interpret them.

Repro

  1. Have a long session with several recent tool calls (Reads, Edits, etc.).
  2. Run /compact.
  3. Have compaction fail — easiest way is to be near a usage limit so the compaction call itself errors out (Error during compaction: You've hit your limit · resets ...).
  4. Wait for limit to reset, send another message, or run /compact again.

Observed

The next assistant turn receives:

  • The conversation summary from the (eventually-successful) second compaction.
  • A series of <system-reminder> blocks replaying tool calls and their results from before the first failed compaction (Read results, plan-mode contents, etc.) — as if those tool calls just happened in the current turn.
  • A <local-command-stderr> for the failed /compact.
  • A <local-command-stdout> for the successful one.
  • The deferred-tools notice listing tools whose schemas now need re-fetching.

The agent essentially gets four overlapping "here's your current state" signals and has to guess which one is authoritative. In practice it behaves erratically — re-reading files it doesn't need to, treating stale tool results as fresh, or skipping the actual user task.

Expected

/compact should be atomic:

  • Success path: next turn starts from the compacted summary only, with no replayed pre-compact tool reminders.
  • Failure path: session stays exactly where it was before /compact ran — no partial summary, no replayed reminders, no half-applied state. User can retry once the underlying issue (rate limit, network, etc.) clears.

Environment

  • Claude Code CLI on Windows 11
  • Model: Opus 4.7
  • Rate limit hit was an Anthropic plan limit, not network

Why this matters

For long-running engineering sessions, /compact is the main tool to keep going past context limits. If it can leave the session in a broken state, users either lose their place or have to /clear and rebuild context from persisted files — which defeats the point.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗