Desktop app session list omits sessions created by the VS Code extension or terminal CLI (private index vs shared transcript store)

Correction (2026-08-05): this issue originally claimed a second, reverse-direction gap (desktop-created sessions missing from the VS Code extension's history). That was wrong and has been removed — the extension lists desktop sessions correctly. See the correction comment below for the evidence. Only the desktop-side gap described here is real.

Summary

Claude Code has one shared transcript store, but the desktop app maintains a separate private session index and lists only sessions it created itself. Sessions started in the VS Code extension or the terminal CLI never appear in the desktop app — not in its session picker, not in resume, not in its history search — even though their transcripts sit in the same directory in the same format, and the extension reads them fine.

Environment

• Claude Code 2.1.221 (desktop app), VS Code extension anthropic.claude-code 2.1.221 / 2.1.222
• Linux (Ubuntu), single project directory used for all sessions

The gap

• Shared transcripts: ~/.claude/projects/<slug>/<cliSessionId>.jsonl → 206 files for this project (379 at time of writing)
• Desktop app's private index: ~/.config/Claude/claude-code-sessions/<accountId>/<projectId>/local_<uuid>.json → 10 descriptors
• Net effect: 196 transcripts exist on disk and are invisible in the desktop app

Each descriptor is thin metadata pointing at a transcript via cliSessionId:

{"sessionId":"local_<uuid>","cliSessionId":"<transcript-uuid>","cwd":"/…/source",
 "title":"…","model":"claude-opus-5","lastActivityAt":1785849781804, …}

The desktop session list, resume, and history search read only this index, and neither the extension nor the CLI ever writes into it — so nothing created outside the desktop app can ever become visible in it.

Reproduces through the desktop app's history search, which is scoped the same way:

• searching a term from a desktop-created session (hibernate) → 2 hits
• searching a term appearing across dozens of extension/terminal sessions (sonar) → No matching sessions found

Meanwhile claude --resume in a terminal lists all of them, confirming the transcripts are intact, origin-agnostic, and readable.

Why the data is already sufficient

Nothing is missing from the shared store — the desktop app simply isn't reading it:

1. Transcripts from every frontend are structurally identical and carry no origin marker. A desktop-created session is keyed by the plain CLI session uuid, not its local_ id:

desktop-created 53d77c85-….jsonl → keys: content, operation, sessionId, timestamp, type
extension/term ab60ee41-….jsonl → keys: operation, sessionId, timestamp, type

1. Titles are already in the transcript, in two record types:

``json
{"type":"custom-title","customTitle":"…","sessionId":"…"}
{"type":"ai-title","aiTitle":"…","sessionId":"…"}
``

So a frontend can render a full, titled session list straight from ~/.claude/projects with no private index at all — which is exactly what the VS Code extension does.

Expected

For a given project directory, every session should be listable, resumable, and searchable from the desktop app regardless of which frontend created it — by indexing ~/.claude/projects directly (titles included, per above), or by having all frontends register descriptors in one shared index.

Impact

Work started in the VS Code extension or terminal can't be found, resumed, or searched from the desktop app, so context has to be re-established manually when switching — the normal flow being IDE for editing, desktop app for longer agent runs. The only local workaround is reverse-engineering the private claude-code-sessions/ descriptor format, which is undocumented and breaks on app updates.