[BUG] Plan side panel shows a stale snapshot from the first proposal, never updates

Confirming this on a separate session, with some additional evidence that narrows the cause.

The panel renders content that no longer exists on disk.

I ran a controlled test. On re-entering plan mode the harness assigned a new plan file (clever-wishing-anchor.md). I wrote a plan containing a unique marker TEST-MARKER-20260810T170258Z plus canaries CANARY-ALPHA-7731, CANARY-BRAVO-4402, CANARY-CHARLIE-9185, and verified on disk that the active plan file contained exactly that immediately before calling ExitPlanMode.

The panel instead rendered an unrelated plan from about a month earlier — from a plan file that had been deleted three days before the test. At test time ~/.claude/plans/ contained only two files, and neither contained the text shown.

Closing the panel does not clear it. I closed the panel completely via the X and called ExitPlanMode again with the file unchanged. Identical stale content. So it isn't a panel-instance cache; it appears session-scoped.

Scope, from testing:

• Not the plan file — active file verified correct immediately before each call
• Not files on disk — rendered content came from a deleted file
• Not the panel instance — survives a full close and reopen
• Untested: whether restarting the session clears it

One diagnostic trap worth flagging: deleting old files from ~/.claude/plans/ appeared to fix it once. That was coincidental, since the panel never reads them, and it sent me down the wrong path for a while.

Environment: macOS (Darwin 24.6.0), desktop app, Opus 5 (also reproduced across a switch to Sonnet 5).

Follow-up with a likely mechanism, and a correction to my earlier comment.

Restarting the app does not fix it. I assumed it might be session-scoped — it isn't. Quitting and reopening Claude Code resumes the same session transcript, and the panel stays stale.

The stale state appears to live in the session transcript, at ~/.claude/projects/<project>/<session-id>.jsonl. That file persists across restarts, which explains the behaviour.

The transcript tracks planFilePath correctly. In a 1,895-line transcript with four plan-mode cycles:

| plan file | first appears at line | occurrences |
|---|---|---|
| <redacted>-plan-a.md | 12 | 12 |
| breezy-leaping-moon.md | 796 | 2 |
| quiet-soaring-marshmallow.md | 890 | 15 |
| clever-wishing-anchor.md | 1743 | 6 |

The panel rendered content associated with the first entry at line 12, even though the current plan's unique marker TEST-MARKER-20260810T170258Z appears from line 1738 onward, near the end of the transcript.

So the pointer is right and the content resolution is wrong: the panel appears to latch onto the first plan record in the transcript rather than the one for the current ExitPlanMode call. This matches the issue title precisely, and explains all the observed behaviour:

• Survives closing the panel (not a panel-instance cache)
• Survives an app restart (transcript is on disk, and restarting resumes the same session)
• Renders content from a plan file deleted days earlier (content comes from the transcript, not the file)
• Unaffected by anything in ~/.claude/plans/

Prediction, untested: a genuinely new session — new transcript, new session id — should render correctly, since there'd be no earlier plan record to latch onto. That would make "start a new conversation" a workaround, as distinct from restarting the app, which does not work.

Prediction confirmed: a genuinely new session renders correctly.

Following up on my previous comment, where I predicted that a new session, with a new
transcript and new session id, should render the correct plan. It does.

Setup, verified before running the test:

1. New session, started fresh rather than resumed.
2. The transcript contained no plan records at all: 18 lines, zero planFilePath entries.
3. ~/.claude/plans/ did not exist. The harness created it along with a new plan file,

humming-seeking-balloon.md.

Test: I wrote a plan containing the unique marker NEWSESSION-20260810T174920Z plus
canaries CANARY-DELTA-5518, CANARY-ECHO-2094, CANARY-FOXTROT-8836, confirmed on disk
that the active plan file contained exactly that immediately before calling
ExitPlanMode, then read the panel.

Result: the panel rendered the correct plan, marker and canaries included. No stale
content.

One caveat about how much this isolates. In this test the plans directory was also empty,
so the panel had nothing old available from any source. The result is consistent with the
transcript mechanism I described earlier, but it does not demonstrate it the way the
earlier test did, where the panel rendered content from a file that had been deleted three
days before.

What it does settle is the practical question:

1. Starting a new conversation clears the stale panel. This is a real workaround.
2. Quitting and reopening the app does not, because it resumes the same session transcript.
3. Resuming an affected session brings the stale content back with it.

Environment: macOS (Darwin 24.6.0), desktop app, Opus 5.