[BUG] Past Conversations not showing in VSCode extension despite valid sessions-index.json

Preflight Checklist

I have searched existing issues and this hasn't been reported yet
This is a single bug report (please file separate reports for different bugs)
I am using the latest version of Claude Code

What's Wrong?

Past Conversations are not appearing in the VSCode extension, even though all session files (.jsonl) and the sessions-index.json exist and are valid. After quitting and reopening VSCode, the conversation history is empty or missing sessions.

The extension logs reveal it's using a cached session index from a different project:
Using cached index entry for session: b186ea61-819c-4036-b856-26f113e06b80

This session ID belongs to Project A, but I'm working in Project B. The extension appears to cross-contaminate session caches between different workspace projects.

What Should Happen?

Sessions listed in ~/.claude/projects/{project-path}/sessions-index.json should appear in "Past Conversations" for that specific project. Each project's session index should be read independently without cache contamination from other projects.

Error Messages/Logs

From Claude VSCode.log (~/Library/Application Support/Code/logs/.../Anthropic.claude-code/):

2026-01-31 18:59:55.743 [info] From claude: 2026-01-31T17:59:55.743Z [DEBUG] Using cached index entry for session: b186ea61-819c-4036-b856-26f113e06b80

This session ID does not exist in the current project's sessions-index.json - it belongs to a completely different project workspace.

No other errors related to session loading are shown.

Steps to Reproduce

Open VSCode with multiple different project folders (separate windows)
Have conversations in each project
Quit VSCode completely (⌘+Q on macOS)
Reopen VSCode and open one of the projects
Check "Past Conversations" → list is empty or shows wrong/missing sessions
Verify that ~/.claude/projects/{project-path}/sessions-index.json contains valid entries
Verify that all .jsonl session files exist in the same directory

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.0.55 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

Environment:

Claude Code VSCode Extension: 2.1.27
OS: macOS 15.2 (Darwin 25.2.0)
Architecture: darwin-arm64

Verified manually:

sessions-index.json is valid JSON (confirmed with python3 json.load)
Contains 6 session entries with correct sessionId, fullPath, and metadata
All referenced .jsonl files exist with correct permissions (600)
File sizes range from 13KB to 21MB
Removed macOS extended attributes with: xattr -cr ~/.claude/projects/{path}/

Workarounds attempted (none successful):

Developer: Reload Window
Full VSCode restart (⌘+Q and reopen)
Manually editing/repairing sessions-index.json
Removing macOS extended attributes
Deleting lock files

The project folder is synced via Dropbox, but all files have correct permissions and no sync conflicts.

Found 3 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

Having same issue

Having a similar issue

Same issue

Having the same issue, how to fix?

Same problem here

Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

What's happening: VSCode extension caches session index globally instead of per-project. When switching between projects, the cached session IDs from Project A are used when loading Project B, causing sessions to not appear because the cached IDs don't match the current project's sessions-index.json entries.

What worked for us:

The fix correctly identifies the need to scope the session index cache key per-project. Beyond just the get operation, ensure that sessions are stored in the cache using a project-scoped key (${projectPath}:${sessionId}) and that mechanisms are in place to clear or refresh the cache for a given project when its sessions-index.json file changes or when the active workspace changes.

// For extension developers - the fix should scope cache by project for both set and get:
// Before (bug):
//   cache.get(sessionId)
//   cache.set(sessionId, sessionData)
// After (fix):
//   const cacheKey = `${workspacePath}:${sessionId}`
//   cache.get(cacheKey)
//   cache.set(cacheKey, sessionData)

Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying.

_{🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.}

Seeing a similar issue, used Claude itself to help me debug and this is what the final output was

Good news and bad news. Here's what I found:

Your conversations ARE being saved
The sessions are stored at ~/.claude/projects/current-project/ — 7 .jsonl files with full user/assistant message history. So nothing is being lost to the wrong location.

The Past Conversations dropdown sounds like a bug
The data exists on disk in exactly the right place, but the VSCode extension's UI isn't surfacing it. A few things worth noting:

There's no globalStorage entry for anthropic.claude-code under ~/Library/Application Support/Code/User/globalStorage/ — so the extension isn't using VSCode's standard extension storage for session discovery
There are 5 stale lock files in ~/.claude/ide/ (PIDs from previous sessions) — unclear if this interferes with session listing

What to do
File a bug report — the sessions are there on disk, the UI just isn't showing them

@carlosbelardi

Updating my earlier analysis based on further findings in this thread.

Correction to my previous comment: My per-project cache key theory was directionally right (cache contamination IS happening per OP's logs), but the TypeScript code example was speculative — I don't have access to the extension source, and the actual implementation may differ.

What we know (with evidence):

Session data is intact — both OP and @carlosbelardi independently confirmed that .jsonl files and sessions-index.json exist and are valid under ~/.claude/projects/
Cross-project cache contamination — OP's extension logs show Using cached index entry for session: b186ea61... where that session ID belongs to a different project (this is from the original bug report)
No globalStorage entry — @carlosbelardi found the extension doesn't use VSCode's standard globalStorage for session discovery, which is an interesting data point about the architecture
The UI doesn't surface existing sessions — data on disk, not in the dropdown

What remains unclear:

Whether the lack of globalStorage is the root cause, or just how the extension is designed (it may intentionally read from ~/.claude/projects/ directly)
Whether stale lock files in ~/.claude/ide/ contribute to the problem (OP already tried deleting lock files without success)

Workaround that works: claude --resume from terminal can access past sessions.

Credit to @carlosbelardi for the additional data points.

Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying.

_{🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.}

Same issue on Windows 11, Claude Code v2.1.71, VS Code extension.

Session files exist on disk at ~/.claude/projects// and are fully intact (verified by reading the .jsonl files directly). However, they don't appear in the Past Conversations dropdown after restarting VS Code.

Workaround that works: claude --resume from the terminal finds and loads the session perfectly — confirming the data is there, just not indexed by the extension.

Workaround that doesn't work: Reloading the VS Code window (Developer: Reload Window) does not make the missing sessions appear.

This is happening regularly — not a one-time occurrence.

Same issue on Windows 11, Claude Code v2.1.71, VS Code extension.

Session files exist on disk at ~/.claude/projects// and are fully intact (verified by reading the .jsonl files directly). However, they don't appear in the Past Conversations dropdown after restarting VS Code.

Workaround that works: claude --resume from the terminal finds and loads the session perfectly — confirming the data is there, just not indexed by the extension.

Workaround that doesn't work: Reloading the VS Code window (Developer: Reload Window) does not make the missing sessions appear.

This is happening regularly — not a one-time occurrence.

It works if you rename the session. Any session whose name is just a hash value is not visible in VSCode but visible in the CLI.

I rolled back a week to plugin version 2.1.63 and all my chat history returned,

This issue is part of a family of ~20 bugs that all stem from the same root cause: the VS Code extension reads titles by raw-string-scanning the last 64KB of each JSONL file, which causes title eviction on long sessions, cross-session contamination from tool result content, and overwrite-on-resume.

See #33165 (comment: #33165 (comment)) for the full root cause analysis, all related issues collected, and a working workaround (persistent title registry + hook).

Navigation Menu

Repository navigation

[BUG] Past Conversations not showing in VSCode extension despite valid sessions-index.json #22215

Preflight Checklist

What's Wrong?

What Should Happen?

Error Messages/Logs

Steps to Reproduce

Claude Model

Is this a regression?

Last Working Version

Claude Code Version

Platform

Operating System

Terminal/Shell

Additional Information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] Past Conversations not showing in VSCode extension despite valid sessions-index.json #22215

Description

Preflight Checklist

What's Wrong?

What Should Happen?

Error Messages/Logs

Steps to Reproduce

Claude Model

Is this a regression?

Last Working Version

Claude Code Version

Platform

Operating System

Terminal/Shell

Additional Information

Activity

github-actions commented on Jan 31, 2026

asalcedo29 commented on Feb 3, 2026

utibeokodi commented on Feb 8, 2026

dibbla commented on Feb 14, 2026

igrushkas commented on Feb 18, 2026

olcor1 commented on Feb 21, 2026

sstklen commented on Feb 24, 2026

carlosbelardi commented on Feb 24, 2026

sstklen commented on Feb 26, 2026

robsonsilvaof commented on Mar 9, 2026

silkfire commented on Mar 9, 2026

Razseal commented on Mar 10, 2026

interconnectedMe commented on Mar 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions