VS Code sidebar loses all session history after restart — sessions-index.json not updated for new sidebar sessions
Description
When Claude Code conversations are started from the VS Code sidebar, the session history is not preserved after VS Code is closed and reopened. The sidebar appears blank on restart, and historical conversations are invisible even though their .jsonl files are fully intact on disk.
The root cause is that sessions-index.json is not being updated when new sessions are created — the index becomes the bottleneck for sidebar session discovery, and it's only partially written.
Reproduction Steps
- Open VS Code with Claude Code extension
- Start several conversations from the sidebar
- Close VS Code
- Reopen VS Code → sidebar is blank / shows only old sessions
Diagnostic Findings
Environment
- OS: Windows 10 x64
- Claude Code version: 2.1.167 (vscode entrypoint), 2.1.138 (cli entrypoint)
- Sessions directory:
~/.claude/sessions/(12 session JSON files) - Project directory:
~/.claude/projects/<project-name>/(16.jsonlfiles)
Evidence
1. sessions-index.json is stale and incomplete
.jsonl files on disk: 16
Entries in index: 6
Missing from index: 10 sessions10 sessions have valid .jsonl history files but are completely absent from the index, making them invisible to the sidebar.
2. Status never transitions from active to idle
{
"sessionId": "2d2b6524-39b3-4c1f-b268-301509be8508",
"status": "active" // ← session ended 3 days ago, still "active"
}The session ended on 2026-06-06 but remains stuck as "active". The close callback does not appear to fire or update the status.
3. New sidebar sessions are not indexed
Two sessions created today (entrypoint: claude-vscode) exist in ~/.claude/sessions/ as JSON files but are NOT in sessions-index.json. This means even current sidebar-started sessions won't survive a restart.
4. Incomplete session JSON files from VS Code
{"pid":38528,"sessionId":"8aa6c44d-...","entrypoint":"claude-vscode"}
// Missing: "status" field, "updatedAt" fieldSome VS Code session JSONs are missing status and updatedAt fields entirely — suggesting the session record was never properly finalized.
Summary Table
| Issue | Severity |
|---|---|
| Index covers only 6/16 sessions (37%) | Critical |
| Status stuck as "active" after close | High |
| New sessions never added to index | Critical |
| Incomplete session JSON from vscode entrypoint | Medium |
Expected Behavior
- Every new session should be added to
sessions-index.jsonat creation time - On VS Code close, all active sessions should transition to
status: "idle" - The sidebar should be able to reconstruct session lists from
.jsonlfiles on disk as a fallback (not rely solely on the index)
Workaround
Manually scanning all .jsonl files and rebuilding the index. Users can run:
for f in ~/.claude/projects/*/sessions-index.json; do
project_dir=$(dirname "$f")
# Rebuild index from .jsonl files...
doneBut this requires terminal knowledge and shouldn't be necessary.
Related Issues
May be related to:
- #16716 (terminal/sidebar integration gap)
- #22718 (native terminal streaming)
- The broader pattern of sidebar↔CLI session lifecycle mismanagement
6 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Related open issues:
All confirmed still broken on v2.1.169 as of 2026-06-10.
Root cause identified
The
claudeCode.environmentVariablessetting in VS Code only passes environment variables to spawned child processes (claude.exe), but NOT to the extension's own Node.js process.This means:
claude.exeinheritsCLAUDE_CONFIG_DIRand reads sessions from the correct pathlistSessions) runs in the VS Code extension host process, which does NOT receive the custom env vars. It falls back to~/.claude(default path) where the project doesn't existWorkaround
Set
CLAUDE_CONFIG_DIRas a system/user Windows environment variable (not just inclaudeCode.environmentVariables):Then restart VS Code completely. The extension's Node.js process will now inherit the correct path.
Suggested fix
The extension should either:
claudeCode.environmentVariablesto its own process environment (process.env), not just child processesCLAUDE_CONFIG_DIRfromsettings.jsonenvsection (whichclaude.exealready does)Environment
CLAUDE_CONFIG_DIRon different drive (F:)settings.json)I have the same issue on macOS. Any workaround?
Two separate directory roots is the problem.
claude.exeinheritsCLAUDE_CONFIG_DIRfromclaudeCode.environmentVariables, but the extension's own Node.js process doesn't — so sessions accumulate in the custom path while the extension's session index reads from the default~/.claude/projects/.I built a toolkit that handles the injection side:
recover_vscode_sessions.pyinBasedGPT/claude-code-session-recoveryreads transcript files from any project directory and injects missing entries into the extension's workspace SQLite cache (state.vscdb). Pointing it at theCLAUDE_CONFIG_DIRpath rather than the default~/.claude/projects/should get those sessions visible in the extension while the upstream env var inheritance fix lands.Run
diagnose.pyfrom the same toolkit first; it maps whatever directory you point it at against the extension's index and shows which sessions are absent. Close VS Code fully before runningrecover_vscode_sessions.py --apply.For ylligashi on macOS: if your setup doesn't use a custom
CLAUDE_CONFIG_DIR, the cause is more likely the extension's 64KB read limit, which silently skips session titles embedded in the middle of large transcript files. Same tool, same process, with macOS transcript path~/.claude/projects/.Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)
Adding a UX symptom of the same session-indexing gap, on VS Code extension v2.1.217 (Windows):
When I use the extension's "fork/branch conversation from here" action, it opens a new chat — and I can then no longer scroll back through the original conversation in the UI, nor is it obvious whether the prior context was carried into the forked session. Combined with the sidebar not reliably listing past sessions (this issue), the original thread just disappears from view once it's no longer in the "Past Conversations" dropdown.
To be clear, the conversation is not lost — the original
.jsonlis intact on disk, andclaude --resumein the terminal finds and resumes it. In practice Claude Code itself is also quite good at locating the right transcript file when asked. So this is a surfacing problem, not data loss: the data is there, the extension UI just can't bring it back after a fork or after it falls off the dropdown. A UI fallback that reconstructs the session list directly from the.jsonlfiles (as suggested in the issue body) would cover both the sidebar case and the fork case.