claude --resume <session-id> always returns 'No conversation found' even though session files exist

[luffyYH]

Bug Description

claude --resume <session-id> consistently returns "No conversation found with session ID: <id>" even though the corresponding .jsonl session files exist on disk.

Environment

• Claude Code version: 2.1.74
• OS: macOS Darwin 24.6.0
• Node: (via npm global install)

Steps to Reproduce

1. Start a Claude Code session and have a conversation
2. Exit the session
3. Check that the session file exists:

   ls ~/.claude/projects/<project-dir>/<session-id>.jsonl
   

4. Try to resume:

   claude --resume <session-id>
   

5. Result: No conversation found with session ID: <session-id>

Session File Structure

The .jsonl files exist and contain valid data. Each message entry has both a uuid (matching the filename) and a sessionId field. For example:

{"parentUuid":null,"type":"user","uuid":"b11d010a-...","sessionId":"b11d010a-...","gitBranch":"feature/xyz"}

The last entry in the file is a custom-title record:

{"type":"custom-title","customTitle":"ws_sharing","sessionId":"b11d010a-..."}

Also Tried

• /resume inside an active session → "No conversations found to resume"
• claude --continue → starts a new session instead of resuming
• Multiple different session IDs → all return the same error

Expected Behavior

claude --resume <session-id> should successfully resume the conversation from the stored .jsonl file.

[afh]

ℹ️ I've noticed that resuming sessions is possible with versions 2.1.50 and 2.1.81, but not when using version 2.1.72.

[youdie006]

Reproducing on v2.1.90 (Linux/WSL2, Ubuntu).

Symptoms:

• claude --resume (no args): Error: --resume requires a valid session ID when used with --print
• claude --resume <session-id>: No conversation found
• Session .jsonl files exist on disk in ~/.claude/projects/<project>/

Root cause identified: sessions-index.json is completely out of sync with actual .jsonl files on disk. In my case:

• 16 entries in the index point to non-existent files (ghost entries)
• 26 actual .jsonl session files exist but are not indexed (orphans)

Since --resume relies on this index, it can never find any session.

Workaround: Rebuilding sessions-index.json from the actual .jsonl files on disk restores all sessions to the picker.

This appears to be the same underlying issue as #25032, #22205, #26485, #29331 — the session index silently stops syncing with disk state.

[petekp]

Reproducing on macOS Darwin 24.6.0, Claude Code 2.1.90.

Symptoms:

Same as OP and @youdie006 — claude --continue starts a fresh session instead of resuming the most recent one in the current directory. /resume inside an active session finds the session fine.

Evidence of index desync:

Session index (~/.claude/sessions/) contained 4 entries:

48793.json → d842163d (cwd A)
64576.json → b20dfdd9 (cwd A)
83681.json → 03f0f779 (cwd A)
87096.json → 35d1148b (cwd B)

Actual .jsonl session data files in the project directory had 10+ sessions, most not indexed:

b20dfdd9.jsonl ← indexed
03f0f779.jsonl ← indexed
d842163d.jsonl ← indexed
cce695e6.jsonl ← NOT indexed
07f45cd7.jsonl ← NOT indexed
dd0dbc88.jsonl ← NOT indexed
5a0fdec9.jsonl ← NOT indexed
d7df04f7.jsonl ← NOT indexed
bbc95cf8.jsonl ← NOT indexed
a059f8c2.jsonl ← NOT indexed

Repro steps (same terminal, same directory):

1. Start a CLI session (claude --permission-mode auto) in a project folder with claude having been initialized already
2. Have a conversation
3. Exit the session
4. Run claude --continue from the same directory in the same terminal
5. Result: fresh session instead of resuming

/resume inside an active session finds all sessions (presumably scanning .jsonl files directly rather than the index).

Confirming @youdie006's diagnosis: The session index silently stops syncing with disk state. Since --continue and --resume both rely on the index, they can't find unindexed sessions.

Workaround

Claude and I created a script you can run to rebuild your index when you start to notice sessions getting dropped: https://gist.github.com/petekp/fa2e778f276739d400a0a67e8fad696c

[SRHSoulja]

I can reproduce this and have data from my own system that may help narrow the root cause.

My system (WSL2, latest CLI):

• 7 index entries in ~/.claude/sessions/
• 60 .jsonl session files in the project directory
• 55 orphans (92% -- exist on disk, no index entry)
• 2 ghost entries (indexed but .jsonl doesn't exist)
• 5 of 7 index entries point to dead PIDs

Structural observation: the index is keyed by PID (<pid>.json), not by session ID. Each entry maps one process to one session. This creates a specific failure path: when the OS reuses a PID for a later Claude Code session, the new <pid>.json overwrites the previous entry. The earlier session loses its only index pointer and becomes an orphan.

On Linux, PID space is bounded (default max is 32768 or 4194304 depending on kernel.pid_max). With hundreds of sessions over time, PID collisions are expected.

This would explain:

• High orphan rates -- PID reuse silently overwrites old entries over time
• Ghost entries -- session .jsonl was removed or never fully written, but the index entry persists (nothing cleans dead entries)
• @petekp's observation that /resume inside a session finds all sessions -- it likely scans .jsonl directly, bypassing the PID-keyed index

An alternative possibility: the index entry is only written on clean exit, not on session start. Sessions killed by Ctrl+C, OOM, or terminal close would never be indexed. This would also produce high orphan rates but through a different path. Checking my own ghost entries: both point to PIDs that are dead and sessions that don't exist, which is consistent with either mechanism.

Testable check:

1. Start a session, note the PID file created in ~/.claude/sessions/. Kill the session with kill -9 (not clean exit). Check if the index entry persists, was removed, or was never written.
2. Compare ls ~/.claude/sessions/*.json | wc -l vs find ~/.claude/projects/<dir>/ -name "*.jsonl" | wc -l on your system. If the ratio is consistently low (mine is 7:60), this is systemic, not per-user corruption.

This may be a separate mechanism from #44346 and #38089 (which involve path scoping). The index desync here appears to be a write-path or retention issue in the PID-keyed session registry, not a lookup-time visibility problem.