[BUG] Claude desktop session indexing bug

Same bug on macOS (Darwin 25.5.0, arm64), same app build 1.26832.0. Adding a root cause, the regression boundary, and impact numbers, since the report has Is this a regression: I don't know.

Yes, it's a regression, and it's narrower than "the sidebar fails to discover transcripts": the app has stopped persisting session-index entries at all.

The index lives in ~/Library/Application Support/Claude/claude-code-sessions/<accountUuid>/<orgUuid>/ as one local_<uuid>.json per session. Three observations pin the failure to the write path rather than to discovery, the filesystem, or account scoping:

1. The newest app-written local_*.json on this machine is dated 2026-08-04 15:54. Nothing since — across two Claude Code versions and ~35 sessions.
2. The app keeps writing to that exact directory the whole time. It creates deleted_<cliSessionId> tombstones normally; the newest is 2026-08-10 17:54. So the directory exists, is writable, and is in active use — only the "write an index entry" path is silent.
3. Upgrading 2.1.221 → 2.1.222 did not restore the writes.

Last version that wrote entries here: 2.1.220. Broke in 2.1.221, still broken in 2.1.222.

That explains why it is 100% reproducible on close/reopen, as reported: sessions created after the regression exist only in the running process's memory. They appear in the sidebar and picker while the app is up — and are gone the instant it restarts. Nothing is corrupted; the entry was simply never written.

A useful secondary symptom for confirming the same root cause: the ccd_session_mgmt MCP tools (list_sessions, search_session_transcripts, list_events) cannot see any session created after the regression, because they read the persisted index rather than process memory.

Impact

Restarting the app on 2026-08-11 dropped 35 sessions from 08-06 to 08-11 out of the sidebar, several substantial (973, 526, 483, 447, 409 user turns).

14 of those 35 are unrecoverable by any means available to a user, which I think is the part worth prioritising. The index filename / sessionId (local_<uuid>) and the transcript filename (cliSessionId) are unrelated uuids, and only the app knows the pairing. deleted_* tombstones are keyed by cliSessionId, not sessionId, so they can't be used to reconstruct it either. The single on-disk trace of the pairing is git-worktrees.json's leasedBy — and only while that worktree lease still exists. Once the lease is released, the mapping is gone for good. I recovered the other 21 by reconstructing index entries from raw transcripts, minting a synthetic local_<uuid5(cliSessionId)> where the real id was unrecoverable.

Asks, in priority order

1. Write the entry eagerly on session creation, not on quit. A crash or force-quit should never be able to lose history — and today an ordinary Cmd+Q silently discards days of it, with no warning.
2. Ship a one-time migration that rebuilds missing entries from ~/.claude/projects/. Transcripts carry cwd, gitBranch, timestamps, model, custom-title / ai-title, and turn count — everything an index entry needs except the CCD session id, which you can mint. Users who have already restarted can't get these back otherwise.
3. Until it's fixed, warn on quit when in-memory sessions have no persisted entry.

One note for whoever writes that migration: group transcripts into sessions by title, not by (cwd, gitBranch). Several distinct sessions routinely share one cwd and branch, so grouping on those silently merges them — I hit exactly that while recovering, and it collapsed 5 sessions into 1 with no indication the other 4 had been dropped.

The transcript files are intact, so the sessions may be made visible again if Desktop is missing their metadata entries. I have seen this split when the .jsonl layer survives but the session-list records do not.

Run python tools/diagnose.py on the affected machine. It compares %USERPROFILE%\.claude\projects\ with %APPDATA%\Claude\claude-code-sessions\ and tells you whether these are orphan transcripts. If it prints the metadata-synthesis command, run its dry-run first and review the proposed entries before applying; do not use Clear Cache & Restart as a first repair.

I built BasedGPT/claude-code-session-recovery with synth_session_metadata.py for the case where transcript files exist but the Desktop session list has no matching metadata. Keep a copy of both directories before any apply step, then fully quit Claude Desktop and verify claude.exe is gone. The missing Desktop session id may not be recoverable for every entry, but the transcript files themselves are the important source to preserve.

If diagnose.py instead shows metadata entries with cliSessionId but no matching .jsonl, that is a different case: keep the metadata and search backups rather than synthesising duplicates.

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

+1, same issue on Windows.

Confirmed the same root cause described here: transcripts on disk are complete and valid, but the Desktop sidebar/session-index only sees a fraction of them.

Project: ~/.claude/projects/<project>/ contains 19 session .jsonl files (oldest from ~6 weeks ago, most recent from today).
Desktop sidebar / session index after a reinstall: 1 session visible (only the new session created post-reinstall).
Confirmed the missing 18 are not corrupted — files are intact, non-empty, valid JSONL.
Checked the app's local session-index store at AppData/Roaming/Claude/claude-code-sessions/ — after reinstall it contained only a single fresh folder (timestamped at reinstall), with no trace of the pre-existing sessions. So it looks like the index isn't being (re)built from the existing .claude/projects/ transcripts on startup — reinstall (or a fresh index) starts from empty rather than scanning what's already there.
Did not try "Clear Cache & Restart" given the warnings in this thread that it's made things worse for others.
Workaround confirmed: sessions are still resumable via claude --resume <session-id> in the CLI even though Desktop can't list them.
OS: Windows.