Plan-mode side panel shows stale plan from a previous plan cycle after mid-conversation session rollover; approval state doesn't stick

Status Closed — duplicate
Reported on v2.1.220
Maintainer reply None cached
Activity 1 comment · opened Jul 30, 2026 · closed Aug 25, 2026

Summary

In a long conversation with two plan-mode cycles (and a mid-conversation session-file rollover from context management), the plan side panel kept rendering a stale plan from the first cycle while the plan file on disk was being updated correctly during the second cycle. The user rejected ExitPlanMode 4+ times because the panel showed content that no longer existed in the plan file. Additionally, after finally approving, plan mode re-engaged spontaneously and asked for approval again — the approval state did not stick.

Environment

  • Claude Code 2.1.220 (desktop app session on Linux)
  • OS: Debian 13, kernel 6.12.96+deb13-amd64
  • Model: claude-fable-5

Conditions observed (from the session transcripts)

  1. Plan cycle #1 starts; plan file A is created. Mid-cycle, the conversation rolls over to a new session JSONL file (context summarization/continuation). Plan A is then written and approved in the new session file.
  2. Later in the same conversation, plan cycle #2 starts with a different plan file B.
  3. During cycle #2, the assistant wrote 5 distinct versions of plan B (different titles and sizes: 8074 → 3036 → 2716 → 5535 → 3469 bytes). Each Write completed 4-5 seconds before its ExitPlanMode call, verified from the transcript timeline and file mtimes.
  4. The user reported the side panel showed the same wrong plan every time — its content matched plan A (from cycle #1), not any version of plan B. The rejection feedback objected to items that only existed in plan A.
  5. After the 5th version was approved, plan mode re-engaged on its own on the next tool call; the subsequent ExitPlanMode was presented for approval again (and, per the user, again with stale panel content). Pasting the plan text directly into the chat was the only way for the user to see the real plan.

Expected

  • The plan panel re-reads the current plan file (the one referenced by the active plan-mode cycle) on every ExitPlanMode.
  • An approval ends the plan cycle; plan mode should not re-engage spontaneously afterwards.

Actual

  • Panel rendered a cached/stale plan (apparently pinned to the first plan cycle / pre-rollover state) across at least 4 consecutive ExitPlanMode calls.
  • Approval state was lost once, forcing a second approval of an identical, unchanged plan file.

Impact

User rejected correct plans repeatedly based on stale panel content — several wasted plan iterations and significant confusion ("the plan you show me is different from the one in your work log").

Workaround

Pasting the plan file content into the chat before calling ExitPlanMode so the transcript shows the authoritative text.

I can provide the two session JSONL timelines (timestamps of Writes / ExitPlanMode calls / results) privately if useful.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗