[BUG] Past conversations not showing in dropdown - sessions-index.json not being updated.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/12872
2. https://github.com/anthropics/claude-code/issues/16290
3. https://github.com/anthropics/claude-code/issues/12908

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

I don't believe this is exactly a duplicate...

#12872: describes conversations disapearing after a restart, but mine never show up at all
#16290: is not very specific and i'm not sure exactly what they're describing
#12908: similarly seems out of date and describes a past update.

Adding evidence from macOS (Claude Desktop App 1.1.351) that confirms this issue:

Key finding: The sessions-index.json file is not just failing to update - it's not being created at all for some projects.

Filesystem evidence:

# Project WITH index (sessions appear in UI):
~/.claude/projects/-Users-kmyers-atomo-commercialization-dsl/
  ├── sessions-index.json  ✅ EXISTS
  └── 4 session .jsonl files

# Project WITHOUT index (sessions MISSING from UI):
~/.claude/projects/-Users-kmyers-Kelly-Customers-Definium-Therapeutic--MindMed----Matt-Wiley-/
  ├── NO sessions-index.json  ❌ MISSING
  └── 4 session .jsonl files (30MB+ of data)

# Another project WITHOUT index:
~/.claude/projects/-Users-kmyers-Kelly-Customers-White-Plains-Hospital---Tony-Mercando--WPH-Data/
  ├── NO sessions-index.json  ❌ MISSING
  └── 2 session .jsonl files

The session data is fully intact - it's only the index that's missing. This suggests the index file creation may be failing silently for certain project paths.

Feature request: A claude sessions reindex command (or automatic detection) would recover all these "lost" sessions.

(Closing my duplicate #18897 in favor of this issue)

This may or may not be related but I am experiencing this issue and, in my particular scenario, I installed claude-code through brew --cask install in a different user than the user I normally invoke claude in.

I found that there were unamed (with empty 'firstPrompt') sessions after executing the following command:
$ nano /home/user/.claude/projects/-home-user-my-project/sessions-index.json
So, I just filled the adequate name for that session, saved the file, executed claude --resume, and found the session

Hope it helps

@claude fix this issue

@claude do you see a problem fixing this issue?

seems like sessions-index.json gets populated the next time I start claude code, not when I shut it down after completing a conversation. It would for sure be nicer to populate immediately when I shut down

Investigation Report: Past Conversations Empty in VS Code Extension

I asked Claude Code to help me debug this issue. Here's what we found:

### Initial Investigation

We cloned the claude-code repository, but discovered that the extension source code is not open source - the repository only contains plugins and
documentation. The actual CLI and VS Code extension code is minified and bundled.

### Root Cause

The bug is a path resolution inconsistency between CLI and VS Code extension:

• CLI resolves symlinks and uses the canonical path (e.g., /data2/home/user/project)
• VS Code extension uses the path as provided by VS Code (e.g., /home/user/project if opened via symlink)

This causes sessions to be stored in different directories under ~/.claude/projects/:

• CLI stores in: -data2-home-user-project/
• Extension looks in: -home-user-project/

This affects anyone whose home directory or project path involves symlinks or bind mounts.

### Workaround

We found two workarounds:

1. Create symlinks in ~/.claude/projects/ mapping the extension's expected path to CLI's actual path:

```bash
ln -s ./-data2-home-user-project ./-home-user-project

1. Modify VS Code's stored paths in ~/.config/Code/User/globalStorage/state.vscdb to use resolved paths, so VS Code opens projects with the same path CLI uses.

Proposed Fix

The CLI and extension should use consistent path resolution. Options:

1. Both resolve symlinks - Call realpath() / fs.realpath() on the project path before generating the storage directory name
2. Both use paths as-is - Don't resolve symlinks in CLI
3. Normalize at storage level - Resolve symlinks when determining the ~/.claude/projects/<name> directory, regardless of how the path was provided

Option 1 or 3 would be the cleanest solution, ensuring sessions are always stored and retrieved from the same location regardless of how the project was opened.

Environment

• OS: Linux (Debian)
• VS Code Extension: anthropic.claude-code
• Home directory on separate disk mounted via symlink

Same issue on Aurora Linux. I also originally installed via brew --cask install claude-code

May not be exactly related, but having a similar issue on MacOS DevContainer for sessions with {"type": "file-history-snapshot", ...} instead of {"type": "summary"
https://github.com/anthropics/claude-code/issues/16579

This may or may not be related but I am experiencing this issue and, in my particular scenario, I installed claude-code through brew --cask install _in a different user than the user I normally invoke claude in_.

No I have the same issue, and a buddy of mine too, using the VSCode IDE.

Bumped! This issue is locking me out of very important sessions, i have to find them call them by session id only and am forced to keep my session count low. when i need at least a few to work properly in Worktree.

Yeah, just ran into this one as well. Pretty bad UX to not be able to find your sessions.

I am also seeing this, my session index for some projects is truncated and not showing all sessions from the actual project folder of jsonl files, and some projects have no session index at all.

The following workaround helped in my case: Manually create the missing sessions-index.json file with the following content:

{ "version": 1, "entries": [] }

When I open the project again and start a new conversation with Claude Code, it automatically recalls the previous conversations again.

Escalation: project directory never created — sessions never persisted to disk

Adding a more severe variant from native Linux (not WSL).

Environment

• Claude Code: 2.1.41
• OS: Fedora 43, kernel 6.18.8-200.fc43.x86_64
• Shell: CLI terminal (not IDE)

The finding

For the project ~/Documents/RustroverProjects/cosmic-term, the entire project directory under ~/.claude/projects/ was never created. Not the index — the directory itself and all session .jsonl files are missing.

Evidence that Claude Code sessions occurred:

$ cd ~/Documents/RustroverProjects/cosmic-term
$ git log --format='%h %ai %s' --since=2026-02-10 --until=2026-02-13 | head -10
bb125c5 2026-02-12 21:21:39 -0500 fix: restore sessions as independent processes with split layout support
5138171 2026-02-12 17:38:30 -0500 fix: graceful exit saves all tabs, not just pinned
3624fa9 2026-02-12 17:27:14 -0500 feat: show restore banner with session timestamps
3809a2f 2026-02-12 16:49:37 -0500 fix: prevent zombie processes on session restore
94c4537 2026-02-11 12:22:16 -0500 fix: only restore sessions on first launch
a8e562f 2026-02-11 11:02:02 -0500 fix: add 10s timeout to AI title suggestion API call

Every one of these commits has Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>, proving multi-hour Claude Code sessions happened from this project directory.

What is missing:

$ ls ~/.claude/projects/-home-lcstyle-Documents-RustroverProjects-cosmic-term/ 2>&1
ls: cannot access '...': No such file or directory

No project directory. No sessions-index.json. No .jsonl files. Zero session data on disk.

Why this is different from other reports

Every other report in this thread (and in #23614, #23421, #22205) describes .jsonl session files that exist on disk but are not indexed/shown in the picker. Those are recoverable — you can rebuild the index or claude --resume <id>.

This variant is permanent data loss. The project directory was silently never created, so session data was never written. There is nothing to recover.

Same machine confirms the index bug too

On the same machine, a different project (~/.claude/projects/-home-lcstyle/) has 39 .jsonl files but only 7 indexed entries (stale since Jan 21). This confirms the index-staleness bug from #23614 exists in parallel. But for the cosmic-term project, the problem is one level deeper: the persistence layer itself failed silently.

Possible root cause

The project path is ~/Documents/RustroverProjects/cosmic-term which maps to -home-lcstyle-Documents-RustroverProjects-cosmic-term. Nothing obviously pathological about this path (no special chars, reasonable length). The mkdir-equivalent that should create the project directory under ~/.claude/projects/ may be failing silently, or there may be a race condition where session data is written to a path that was never created.

Update: sessions found — root user path split, not data loss

Correction to my previous comment. The "missing" cosmic-term sessions were found under /root/.claude/projects/ rather than /home/lcstyle/.claude/projects/. The user had been running claude as root (via sudo), so sessions were persisted under root's home directory. Not permanent data loss — the sessions exist and are resumable.

However, this reveals a different UX problem: running claude as root vs. as the normal user splits session storage across two separate ~/.claude/ trees, and the /resume picker only shows sessions for the current user. There's no indication this is happening and no way to see sessions from the other user's store.

What was actually broken (still valid)

The sessions-index.json staleness bug is confirmed on both user accounts on the same machine:

| User | Project dir | .jsonl files on disk | Indexed entries | Index stale since |
|------|-------------|---------------------|-----------------|-------------------|
| lcstyle | -home-lcstyle/ | 39 | 7 | Jan 21 |
| root | -home-lcstyle/ | 247 | 39 | ~late Jan |
| root | -home-lcstyle-Documents-RustroverProjects/ | 15 | 5 | Jan 23 |
| root | -home-lcstyle-Downloads/ | 9 | 3 | stale |
| root | -home-lcstyle-Documents-RustroverProjects-cosmic-kb/ | 3 | 0 | never |

9 additional root project directories had no index at all despite having session files.

Environment

• Claude Code: 2.1.41
• OS: Fedora 43, kernel 6.18.8
• Both root and normal user affected identically

The following workaround helped in my case: Manually create the missing sessions-index.json file with the following content: { "version": 1, "entries": [] } When I open the project again and start a new conversation with Claude Code, it automatically recalls the previous conversations again.

Is it actually populating the sessions-index file though? The latest versions ignore this file completely and populate the recent chat lists from just recently modified jsonl files from the project directory, it skips the session index entirely.

+1. macOS 15.4, Claude Code CLI (not VS Code extension).

97 session files on disk, 8 entries in sessions-index.json. Only seeing ~8% of my history in /resume.

Discovered it while trying to find a session from a week ago where I built a Google Apps Script workflow. Had to grep through the raw JSONL files to recover the context.

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: https://github.com/anthropics/claude-code/issues/33165#issuecomment-4070011372) for the full root cause analysis, all related issues collected, and a working workaround (persistent title registry + hook).

Any updates?

Any ETA? The history is still missing. I feel this extension UI is much better than any terminals on Windows - it's easy to copy shell commands by just one click without selecting anything - compared to the standard terminal behavior.