[BUG] VSCode sidebar "Past conversations" empty - extension filters out its own sessions via includeProgrammaticSessions=false (regression in 2.1.191)

Can corroborate the root cause from the transcript side. Inspecting my own on-disk sessions under ~/.claude/projects/:

$ grep -ohm1 '"entrypoint":"[^"]*"' ~/.claude/projects/*/*.jsonl | sort | uniq -c
    251 "entrypoint":"cli"
      9 "entrypoint":"sdk-cli"

So sdk-cli is not an "SDK script only" marker — it's stamped on real, resumable interactive transcripts that live right next to the cli ones. That lines up exactly with your trace: if includeProgrammaticSessions = false drops everything whose entrypoint is in ["sdk-cli", "sdk-ts", "sdk-py"], it throws out legitimate interactive history, not just programmatic SDK runs. The bug is the conflation of entrypoint == sdk-cli with "programmatic / non-interactive."

Two things that may help others landing here:

• Your conversations aren't lost — only the sidebar view is filtering them. The .jsonl transcripts are all still on disk under ~/.claude/projects/<encoded-cwd>/, so nothing was deleted by the 2.1.191 update.
• Workaround until it's fixed: resume from the CLI (claude --resume) in the same project directory — the resume picker reads those transcripts directly rather than going through the extension-side includeProgrammaticSessions filter, so the "missing" VSCode sessions are still reachable there.

For the maintainers: the fix probably shouldn't key the interactive/programmatic distinction off entrypoint at all, since sdk-cli now covers interactive extension sessions too. A dedicated flag (e.g. isInteractive / a real headless marker written into the transcript) would separate "spawned by an SDK script" from "interactive session that happens to be launched via the sdk-cli entrypoint" without false-filtering user history.

The 87 transcript files are still on disk, but the extension's includeProgrammaticSessions=false setting treats the sdk-cli marker as a reason to hide them. The result is a session-list filter problem, not evidence that those transcripts were deleted.

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 reports dropped VS Code entries, recover_vscode_sessions.py reads complete JSONL files and rebuilds the cache instead of relying on the extension's head/tail scan. Keep VS Code closed before applying a cache repair.

The sdk-cli evidence also points to the upstream distinction that matters: the extension is writing a resumable interactive session with that marker, so it isn't a reliable synonym for an external SDK script.

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

Still present in 2.1.226 (win32-x64, Windows 11) — the stale label looks premature. Same defect, but it now presents differently: the entrypoint written is sdk-ts rather than sdk-cli, the VS Code host class is now _o extends zB, and the symptom is partial rather than total. CLI sessions list fine; Agent-window sessions vanish the moment they are closed.

That partial form is more confusing than the original empty list — a session is visible while live, disappears on close, and claude --resume still lists it, so it reads as data loss.

Repro:

• Start a session in the VS Code Agent window.
• It appears in the Sessions sidebar while live.
• Close it — it disappears.

claude --resume still lists it; the transcript is intact in ~/.claude/projects/<project>/.
grep '"entrypoint"' <transcript>.jsonl → sdk-ts.
Seven interactive sessions from one day were hidden this way here. Nothing was lost, but the sidebar and CLI disagreeing makes it look like it.

Workaround: rewrite "entrypoint":"sdk-ts" → "cli" in affected transcripts (durable), and/or flip includeProgrammaticSessions=!1 to !0 in extension.js (reverted by each update). Preserve file mtime — the sidebar sorts on it.

Hey upt75, those seven Agent-window sessions are still on disk; it is the VS Code session list hiding them, not transcript loss.

The newer sdk-ts marker looks like the same filter family as the earlier sdk-cli case. claude --resume proving the sessions are reachable is the useful split: the CLI can enumerate the transcript files while the extension drops them after close.

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 reports dropped VS Code entries, run the printed dry-run for recover_vscode_sessions.py; keep VS Code closed before applying a cache repair. I would preserve the transcript files and avoid rewriting entrypoint by hand until the upstream filter is fixed, because an extension update can put the filter back.

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