VSCode extension: session picker only ever shows current session, never history (data intact on disk)

Confirming this on Windows too (VS Code extension, entrypoint: "claude-vscode").

What I found while digging into this:

• 3+ sessions from the same day, in the same project folder, were on disk in ~/.claude/projects/<project>/ with real conversation content (largest 1.9 MB) — but only the currently active session appeared in the Session History picker.
• Verified one of the "missing" sessions was legitimately created by the extension itself: its JSONL transcript has "entrypoint":"claude-vscode" and a cwd that exactly matches the open workspace folder. So this isn't a stale/foreign session or a path-matching edge case — it's a session created moments earlier in the same window.
• Checked %APPDATA%\Code\User\globalStorage\ — there is no anthropic.claude-code folder at all, meaning the extension doesn't appear to maintain its own persistent index of sessions. That suggests the picker should be reading live from ~/.claude/projects/, but isn't reliably doing so.
• Workaround confirmed: the "missing" sessions ARE resumable from the CLI with claude --resume <session-id> (or claude --resume for the interactive picker), which reads the same underlying storage. So this is purely a listing/display bug in the extension's Session History UI — no data loss.
• Claude Code CLI version: 2.1.179; VS Code extension engine version recorded in the affected session's transcript: 2.1.222. Worth noting these differ.
• OS: Windows 11.

The 18 JSONL files are intact and the CLI can resume them, so this is a VS Code session-list visibility problem rather than missing conversation history. The fact that one missing file was created by claude-vscode in the same workspace also rules out a foreign project path as the explanation.

I built BasedGPT/claude-code-session-recovery for related VS Code session-list failures. Run python tools/diagnose.py first and follow the exact command it prints. If it routes you to recover_vscode_sessions.py, run the dry run to see which complete transcripts it would add, then keep VS Code fully closed before applying it. For one immediate check, run claude --resume <session-id> against a file the extension is hiding; that confirms the transcript itself is still usable.

The extension needs to enumerate sessions created by its own claude-vscode entrypoint as well as the currently active one, instead of treating a display omission as if the conversation did not exist.

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

Can confirm this is still happening (VS Code extension, Windows 11), and independently reproduces @jjnxpct's findings above.

One practical gotcha for anyone trying the claude --resume workaround: there's no globally installed claude CLI on my machine (not on PATH, not npm-installed) — the extension ships its own binary. Found it at:

<extensions-dir>\anthropic.claude-code-<version>-win32-x64\resources\native-binary\claude.exe

Running claude.exe --resume <session-id> -p "<prompt>" against a session that was missing from the picker worked correctly and returned a contextually accurate answer, confirming it reads the real transcript — same conclusion as above: display-only bug, no data loss.