Session History panel fails to list/resume local sessions

Status Open

Maintainer reply None cached

Activity 4 comments · opened Aug 26, 2026

## Description
The Session History panel in the VS Code extension does not list or let me resume past local sessions, even though the session transcripts exist and are intact on disk. Related keybinding/command issues found during troubleshooting are included below.

Steps to Reproduce

Have one or more prior Claude Code sessions saved locally (~/.claude/projects/<project>/*.jsonl present and readable).
Click the history/clock icon in the Claude Code panel.
Separately, try Command Palette > search "Resume Session" and try the matches shown (Claude Code: Reopen Closed Session [Ctrl+Shift+T], Ask in Chat: Claude Code: Resume Session [Ctrl+Alt+I]).

Expected Behavior

The history icon should show a searchable list of past sessions for the current project. "Reopen Closed Session" should reopen a recently closed Claude Code session. The resume keybinding should resume a Claude Code session, not launch GitHub Copilot Chat.

Actual Behavior

History icon: only the currently-open session is shown, or a blank "Untitled" session opens if none is open. Typing into the search field returns no results even for titles known to exist on disk. If a session is already open, pressing the icon hides its visible chat content (title stays, messages disappear from view — the underlying data isn't deleted).
"Reopen Closed Session" (Ctrl+Shift+T): does nothing when invoked.
"Ask in Chat: Claude Code: Resume Session" (Ctrl+Alt+I): opens a new GitHub Copilot Chat session instead of resuming Claude Code — looks like a keybinding collision where Copilot intercepts Ctrl+Alt+I.

Diagnostic detail from the extension's own log (Claude VSCode.log): clicking history fires a list_sessions_request (entryPoint sessions_dialog) plus a separate list_remote_sessions call. The remote call correctly logs Fetched 0 remote sessions (expected, local-only usage). The local list_sessions_request never logs a result count or error at all — it silently returns nothing despite valid .jsonl session files on disk.

Workaround: running claude --resume from an interactive terminal in the project directory correctly lists and resumes sessions, since it reads the same .jsonl files directly — unaffected by whatever's failing in the panel's request path.

Environment

Extension: Claude Code for VS Code, v2.1.246
OS: Windows 11
A stale duplicate v2.1.245 install was found and removed during troubleshooting; issue persisted after removal, so it isn't a duplicate-version artifact.

Additional context

Diagnosed collaboratively with Claude (Claude Code) while troubleshooting session resume across multiple attempts (history icon, command palette, keybindings) before concluding the panel itself is broken rather than user error.

View original on GitHub ↗

4 Comments

andyandyau · 1 day ago

I have the same issue ..
While the Local Session View is rendered I find this error when a symbol is attempted to be rendered ..
Could be related..

Loading the font 'data:font/ttf;base64,AAEAAAALAIAAAwAwR1NVQiCLJXoAAAE4AAAAVE9TLzI3T0tHAAABjAAAAGBjbWFwQ5s/ewAACSQAABreZ2x5ZvJtKHkAACekAAD3FGhlYWRYl6BTAAAA4AAAADZoaGVhAlsC+QAAALwAAAAkaG10eBxB//oAAAHsAAAHOGxvY2EFi8dWAAAkBAAAA55tYXhwAu8BgQAAARgAAAAgbmFtZZP3uUsAAR64AAAB+HBvc3RjGEbCAAEgsAAAGSQAAQAAASwAAAAAASz////+AS4AAQAAAAAAAAAAAAAAAAAAAc4AAQAAAAEAAFT7+XFfDzz1AAsBLAAAAAB8JbCAAAAAAHwlsID////9AS4BLQAAAAgAAgAAAAAAAAABAAABzgF1ABcAAAAAAAIAAAAKAAoAAAD/AAAAAAAAAAEAAAAKADAAPgACREZMVAAObGF0bgAaAAQAAAAAAAAAAQAAAAQAAAAAAAAAAQAAAAFsaWdhAA...h0C3RyaWFuZ2xlLXVwB3R3aXR0ZXISdHlwZS1oaWVyYXJjaHktc3ViFHR5cGUtaGllcmFyY2h5LXN1cGVyDnR5cGUtaGllcmFyY2h5BnVuZm9sZBN1bmdyb3VwLWJ5LXJlZi10eXBlBnVubG9jawZ1bm11dGUKdW52ZXJpZmllZA52YXJpYWJsZS1ncm91cA92ZXJpZmllZC1maWxsZWQIdmVyaWZpZWQIdmVyc2lvbnMJdm0tYWN0aXZlCnZtLWNvbm5lY3QKdm0tb3V0bGluZQp2bS1ydW5uaW5nAnZtAnZyD3ZzY29kZS1pbnNpZGVycwZ2c2NvZGUEd2FuZAd3YXJuaW5nBXdhdGNoCndoaXRlc3BhY2UKd2hvbGUtd29yZAZ3aW5kb3cJd29yZC13cmFwEXdvcmtzcGFjZS10cnVzdGVkEXdvcmtzcGFjZS11bmtub3duE3dvcmtzcGFjZS11bnRydXN0ZWQHem9vbS1pbgh6b29tLW91dAAA' violates the following Content Security Policy directive: "font-src 'self' https://.vscode-cdn.net". The action has been blocked.

BasedGPT · 22 hours ago

The strongest signal here is that claude --resume still lists the sessions while the VS Code local request returns no result. That points to the extension's session-list and cache layer; the JSONL transcript files are intact. The Ctrl+Alt+I collision is a separate keybinding problem, so I would keep it separate from the missing local entries.

I built BasedGPT/claude-code-session-recovery for this file-layer split. From that checkout, run python tools/diagnose.py first and follow the exact command it prints. It checks the transcript files and will identify the VS Code session-list route when the on-disk sessions are present but the extension cache has dropped their entries.

Keep a copy of the affected ~/.claude/projects/ directory and the VS Code workspace state before applying anything. Close VS Code before running a command with --apply, review the dry-run output first, and compare one session that claude --resume can see with the entries returned by the panel. That will confirm whether the missing layer is the extension cache rather than the transcript.

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

Feldob66 · 17 hours ago

@andyandyau Found the root cause for this — it's a CSP misconfiguration, not a rendering bug.

The webview's Content-Security-Policy is built in extension.js (the Local Session View webview) from a few template strings:

style-src ${$.cspSource} 'unsafe-inline'`, q=`font-src ${$.cspSource}`, N=`img-src ${$.cspSource} data:`, O=`worker-src ${$.cspSource}`

img-src explicitly whitelists the data: scheme so inline base64 images work, but font-src never does. The Local Session View renders an icon font as a data:font/ttf;base64,... URI, which the CSP then blocks — exactly the console error you posted.

Local workaround until this is fixed upstream:
In your installed extension folder (<user>/.vscode/extensions/anthropic.claude-code-<version>-win32-x64/extension.js), find the line containing font-src ${$.cspSource} and change it to:

font-src ${$.cspSource} data:

(mirrors what img-src already does). Then run "Developer: Reload Window" from the Command Palette — a plain file save doesn't reload the cached extension host JS.

Confirmed this clears the CSP violation and the symbols render correctly.

⚠️ Caveat: this edits a shipped, minified extension file directly, so it is not persistent — it'll be silently overwritten the next time the extension auto-updates. If the font error comes back after an update, that's why: just reapply the same one-line data: addition to font-src until the maintainers ship the real fix (adding data: to font-src in the webview CSP builder, same as img-src).

Feldob66 · 17 hours ago

@BasedGPT flagging this suggestion for anyone else landing on this thread.

I reviewed the linked claude-code-session-recovery repo (cloned locally, read-only, nothing installed or executed) before considering the recovery steps suggested above. For transparency:

Static review found no network calls, no eval/exec, no obfuscated payloads, and no credential harvesting in tools/. The subprocess calls are static argument lists to local tools (git, vssadmin, wmic, tasklist, powershell), not shell-interpolated, so no obvious injection vector.
That said, it's a brand-new, low-star repo (created ~3 months ago) that showed up as an unsolicited self-promotion in someone else's bug thread, ending with a request for a star — not how genuine troubleshooting help usually arrives. It also ships an AGENTS.md/CLAUDE.md explicitly addressed to "any AI assistant helping a user with this repo," which is a notable design choice for a tool whose "mutator" scripts perform real deletions/rewrites (os.remove, shutil.rmtree, metadata rewrites) against a user's actual Claude Desktop/CLI session data.

Nothing here proves bad intent, and today's snapshot reads clean, but I'd caution against running --apply mutations against real session data based on an unaudited, unfamiliar repo promoted this way — especially since it's unrelated to the actual bug in this issue (a CSP font-src misconfiguration, see the comment above). Worth keeping this thread focused on the extension bug itself.