# Bug: VS Code extension 2.1.193 — sessions sidebar omits externally-created/modified session transcripts ## Summary After the Claude Code VS Code extension updated, the "Local" sessions sidebar stopped listing session transcript files (`~/.claude/projects/ / .jsonl`) that were **created or last modified by a process other than the extension itself** (e.g. `claude -p` / `claude --resume` headless runs from an external automation). Only sessions the extension itself created or opene

VS Code extension: sessions sidebar omits externally-created session transcripts (regression in 2.1.187–2.1.191)

Status Open

Reported on v2.1.193

Maintainer reply None cached

Activity 4 comments · opened Jun 26, 2026

Bug: VS Code extension 2.1.193 — sessions sidebar omits externally-created/modified session transcripts

Summary

After the Claude Code VS Code extension updated, the "Local" sessions sidebar
stopped listing session transcript files (~/.claude/projects/<project>/<uuid>.jsonl) that were
created or last modified by a process other than the extension itself (e.g. claude -p /
claude --resume headless runs from an external automation). Only sessions the extension itself
created or opened are shown.

Confirmed by bisecting via downgrade: 2.1.186 works, 2.1.191 AND 2.1.193 are broken.
So the regression was introduced somewhere in 2.1.187 – 2.1.191. Downgrading to
2.1.186 fully restores the list (all externally-written sessions reappear).

Environment

Extension: anthropic.claude-code — broken: 2.1.191, 2.1.193 / works: 2.1.186 (all win32-x64)
Regression range: 2.1.187–2.1.191
OS: Windows 11 (10.0.26200)
VS Code: stable
2.1.193 auto-installed 2026-06-26 08:58 local; mirroring broke around that update.

Expected behavior (as in 2.1.191 and earlier)

The Local sidebar lists every session .jsonl present on disk for the current project,
minus hiddenSessionIds, regardless of which process wrote the file. This made the sidebar a
faithful mirror of the on-disk session set (used here to mirror against an external Telegram
remote-control daemon that drives claude headless).

Actual behavior (2.1.193)

Sessions whose .jsonl was created/last-written by an external claude CLI process do not
appear in the sidebar, even though:

the file exists in the correct project folder (C--Users-bagel),
the session is not in Anthropic.claude-code.hiddenSessionIds (verified via state.vscdb),
the session is not trashed,
the file is structurally identical to visible sessions (same first entry type

queue-operation, same keys operation/sessionId/timestamp/type, isSidechain:false,
gitBranch:HEAD, no summary),

Reloading the window and waiting do not surface them.

Sessions that were opened/created inside VS Code itself still show normally. Net effect: only
externally-driven (headless/automation) sessions are dropped.

Investigation notes (what was ruled out)

Not hiddenSessionIds (DB read live, missing sessions are show, not hidden).
Not trash, not the per-session file content/structure (byte-level fields identical).
No session-list cache found in globalStorage, workspaceStorage, or history.jsonl — the list

appears to be built at runtime by the extension host, and that logic now excludes
externally-written files.

agentSessions.model.cache in workspaceStorage holds only built-in VS Code chat sessions,

unrelated to the Claude sidebar.

Repro

With the extension running, create/append a session transcript via an external process

(e.g. claude -p --session-id <uuid> "..." then claude --resume <uuid> ...), writing to
~/.claude/projects/<proj>/<uuid>.jsonl.

Open the Local sessions sidebar in VS Code. Reload the window.
The externally-written session does not appear (2.1.193). On 2.1.191 it appears.

Workaround

code --install-extension anthropic.claude-code@2.1.186 --force, disable extension auto-update
(extensions.autoUpdate: false), then fully quit and relaunch VS Code (a plain Reload Window
is not enough — the extension host keeps the old version cached).

Impact

Breaks any workflow that drives Claude sessions via the CLI/headless and relies on the VS Code
sidebar reflecting the true on-disk session set.

View original on GitHub ↗

4 Comments

github-actions[bot] · 2 months ago

Found 2 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

BasedGPT · 2 months ago

The bisection to 2.1.186 vs 2.1.187–2.1.191 pins this cleanly — the regression introduced a filter that excludes sessions not originated by the extension itself, rather than indexing all sessions from disk.

What I’ve seen in the general vscode_session_list_dropped pattern is the extension maintaining its session index in a SQLite cache (state.vscdb). In prior versions the 64KB read-limit was the mechanism; your case is different: the extension appears to have changed which files it considers when building the runtime enumeration. Sessions it didn’t create simply aren’t candidates.

I built a toolkit for injecting missing sessions back into that index: recover_vscode_sessions.py in BasedGPT/claude-code-session-recovery reads full transcript files from ~/.claude/projects/ and rebuilds missing entries in state.vscdb. Worth running diagnose.py from the same toolkit first; it maps the transcript directory against the extension’s current index and shows which sessions are absent. Close VS Code fully before running recover_vscode_sessions.py --apply.

One honest caveat: based on what I’ve seen with the mapped-drive variant of this bug, if the extension’s session listing is being rebuilt from a source that ignores externally-authored files, injected entries may not survive the next time a session is created inside VS Code. The downgrade to 2.1.186 is the cleaner path until Anthropic fixes the regression. The toolkit gets your sessions accessible now; it doesn’t correct the underlying exclusion.

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

bagelife2 · 2 months ago

This is the same root area as #61058 and #66499 — externally / -p-created session .jsonl files exist on disk but aren't surfaced in the UI because they aren't registered in the session index.

Adding a data point those issues don't have: this is a regression in the VS Code sessions sidebar, and I bisected the exact range.

✅ 2.1.186 — the sidebar shows ALL sessions, including ones created / last-written by an external claude CLI process (here, a Telegram remote-control daemon driving headless claude).
❌ 2.1.191 and 2.1.193 — those externally-written sessions vanish from the sidebar. They are not hidden (hiddenSessionIds checked), not trashed, files are intact on disk and byte-identical in structure to the sessions that still show.

So the regression was introduced somewhere in 2.1.187 – 2.1.191.

Corroborating the index theory from #61058: on 2.1.186 there is no sessions-index.json on my machine, and the sidebar appears to enumerate the project's .jsonl files directly (so external sessions appear). The newer versions appear to depend on an index that external / headless writes never update — matching #61058's root cause, now affecting the VS Code sidebar specifically.

Workaround: code --install-extension anthropic.claude-code@2.1.186 --force, set "extensions.autoUpdate": false, then fully quit & relaunch VS Code (a plain Reload Window isn't enough — the extension host keeps the old version cached).

Please keep this open / tie the regression to the index-discoverability bug — the bisect range above should make it straightforward to find what changed between 2.1.186 and 2.1.191.

bagelife2 · 1 month ago

Still reproduces on the latest 2.1.220 — one month after this report, with the bisect range already provided.

Retested today (2026-07-27):

code --install-extension anthropic.claude-code@2.1.220 --force
Fully quit and relaunched VS Code (not just Reload Window).
Sessions whose .jsonl was last written by an external claude CLI process (a headless claude -p daemon) are present and intact on disk under ~/.claude/projects/, but do not appear in the sessions sidebar. Not hidden (hiddenSessionIds checked), not trashed.
Rolled back to 2.1.186 + full relaunch → the exact same sessions reappear immediately.

So the regression I bisected to 2.1.187–2.1.191 is still unfixed all the way through 2.1.220. Related #66499 is also still open.

The issue already has the bug/regression/platform:vscode labels, a bisected version range, and clear repro steps — but no assignee and no team response in a month. Could someone triage this? The externally-authored-session case is the same index-discoverability root cause as #61058 (now closed), just surfacing in the VS Code sidebar instead of the --resume picker. The 2.1.186 → 2.1.191 diff should make it straightforward to locate.