VS Code extension: panel history lists pruned/unloadable sessions and disagrees with Spark (Activity Bar) history

Open 💬 0 comments Opened Jul 4, 2026 by natkuhn
Note: This report was written by Claude Code (Anthropic's CLI) on behalf of the reporter (@natkuhn), based on a debugging discussion of bugs they encountered in the VS Code extension. The findings (including the on-disk transcript checks) were gathered during that session.

Bug: VS Code extension panel history lists pruned/unloadable sessions and disagrees with the Spark (Activity Bar) history

Summary

In the Claude Code VS Code extension, the panel session-history list and the
Spark (Activity Bar) session list are out of sync. The panel history offered
a session whose transcript had already been pruned from disk. Clicking it failed
to load ("couldn't load"), applied the old session's title to a different
(new, empty "Untitled") chat, and the resulting title change was not reflected
in the Spark list.

Environment

  • Claude Code CLI: 2.1.4
  • VS Code extension: anthropic.claude-code-2.1.201-darwin-arm64

(note: an older build, 2.1.177, is also present in
~/.vscode/extensions/ — two versions installed simultaneously)

  • macOS: 26.5 (25F71), Apple Silicon
  • cleanupPeriodDays: was at the default (30) when the bug occurred; since

raised to 36500.

What happened

  1. The panel history (the history/clock button at the top of the chat pane)

listed a session titled "Recover lost Claude Code conversation."

  1. The Spark icon / Activity Bar history did not list that session.
  2. That session was ~30 days old — i.e. its transcript .jsonl had just been

pruned from ~/.claude/projects/<slug>/ under the default
cleanupPeriodDays: 30. Confirmed on disk: the only remaining .jsonl in
the project folder is the current session; there is no file for the listed
old session.

  1. I created a new chat via the + button (to avoid disturbing my active

session), then clicked the old "Recover lost…" entry in the panel history.

  1. Result:
  • The new Untitled chat's title changed to "Recover lost Claude Code

conversation" (the click's title applied to the wrong target), then

  • an error appeared: it couldn't load the session (because the

transcript file no longer exists).

  • The Untitled chat still appeared in the Spark list, and the title

change was not reflected there — the two views did not reconcile.

Expected behavior

  • The panel history and the Spark/Activity-Bar history should show the same

set of sessions (reconciled against the on-disk transcripts).

  • A history entry whose transcript has been pruned/deleted should either be

omitted or shown as unavailable, not offered as openable.

  • Clicking a history entry should open that session (or clearly fail

without side effects) — it must not retitle or overwrite a different
currently-open chat.

Actual behavior

  • The two history views disagree.
  • A pruned session is listed as if openable.
  • Clicking it mutates an unrelated open chat (title applied to the new Untitled

session) and then errors out with a load failure.

  • State changes in one view don't propagate to the other.

Impact

No data loss beyond the already-pruned session (the prune itself is expected
behavior). The bug is the stale/unreconciled history UI and the
wrong-target side effect when opening a missing session.

Repro sketch

  1. Have a session older than cleanupPeriodDays so its .jsonl is pruned, but

whose entry still appears in the panel history list.

  1. Open a new (Untitled) chat via +.
  2. In the panel history, click the pruned session's entry.
  3. Observe: the Untitled chat is retitled to the pruned session's name; a

"couldn't load" error appears; the Spark list neither showed the pruned
entry nor reflects the retitle.

Suspected cause

The panel history appears to read a cached list of session metadata/titles that
is not reconciled against the actual transcript files on disk, whereas the
Spark/Activity-Bar view appears to enumerate the files directly (hence it
correctly omitted the pruned session). The open action also lacks a guard for
"transcript missing," so it falls back to acting on the currently-focused chat.

---
🤖 Filed via Claude Code on behalf of @natkuhn

View original on GitHub ↗