Desktop app (macOS): Code sessions repeatedly vanish from sidebar while transcripts AND pointer files remain intact — IndexedDB desync, no rebuild on launch (4 incidents in 9 days)

Status Open
Reported on v2.1.197
Maintainer reply None cached
Activity 0 comments · opened Jul 18, 2026

Summary

Local Claude Code sessions created/used in the Claude Desktop app (macOS) repeatedly vanish from the Code tab session list. Four separate incidents in nine days (Jul 9–18, 2026) on the same machine. In every case the underlying data is fully intact on disk — only the app's list stops showing the sessions. Remote Control sessions are never affected.

This appears to be the same family as #59736 / #51412 / #58670 / #29172 / #25524, but with a forensic detail that narrows the cause: the per-session pointer files are intact — it is the app's render/index layer (IndexedDB) that has desynced, and the app never rebuilds the list from the pointer files on launch.

Environment

  • macOS (Darwin 25.x), Apple Silicon MacBook Pro
  • Claude Desktop app, 1p deployment, appVersion ~1.20186.x
  • Claude Code CLI during the period: 2.1.197 → 2.1.205 (auto-update Jul 11, 22:28) → 2.1.207 → 2.1.209
  • Sessions affected: local Desktop-created sessions AND CLI-resumed local sessions. Remote Control sessions: never affected.

Timeline of incidents

| Date | What vanished |
|---|---|
| Jul 11–12 | ~70 sessions disappeared from the Code list after auto-update to 2.1.205 (Jul 11 22:28). Full app quit + relaunch did not restore the list. |
| Jul 14 | A freshly created Desktop session (started 12:31, actively used until 17:15 same day) vanished after an app restart. |
| Jul 17 | A session started at 19:40 vanished the same evening — without any app restart. An in-session /remote-control attempt had failed just before (CLI login had silently expired). |
| Jul 18 | Another session, last active 15:25, vanished "minutes later" while the user was still working. |

Forensic evidence (collected while the bug was live)

  1. Transcripts intact: all vanished sessions exist as healthy JSONL under ~/.claude/projects/<project>/<uuid>.jsonl (one is 22 MB and still being written by a live process).
  2. Pointer files intact: the app's own per-session pointer files under

~/Library/Application Support/Claude/claude-code-sessions/<workspaceId>/<subId>/local_*.json
are present for the vanished sessions, with correct title, cwd, timestamps, valid cliSessionId, and isArchived: false. (So this is NOT the missing-pointer case of #58670, and NOT the transcriptUnavailable scanner case of #63082.)

  1. IndexedDB desync: ~/Library/Application Support/Claude/IndexedDB/https_claude.ai_0.indexeddb.leveldb contains 0 of 67 cliSessionIds referenced by the pointer files.
  2. No rebuild on launch: full quit (⌘Q) + relaunch does not repopulate the list, despite all pointer files being present and valid. There is no top-level manifest in claude-code-sessions/ — nothing on disk explains the empty list.
  3. Control group: three long-running Remote Control sessions (20+ days uptime, server-side listed) never disappeared from the app during any incident.

Expected behavior

On launch (or via a "reload sessions" action), the app should rebuild the Code list from the on-disk pointer files (and ideally reconcile with ~/.claude/projects/), instead of trusting an IndexedDB cache that can silently desync.

Actual behavior

Once the internal index desyncs, sessions are permanently invisible in the UI. The only recovery is claude --resume <id> from the CLI, which works perfectly every time — confirming data integrity.

Impact

Non-technical users experience this as losing a day of work, repeatedly. The data is never actually lost, but there is no UI path to it. We now route everything through Remote Control as a workaround, which defeats the purpose of the Desktop app's local session management.

Suggested fixes

  1. Rebuild the session list from claude-code-sessions/ pointer files at launch (they are already the durable store — trust them over the IndexedDB cache).
  2. Add a manual "Rescan sessions" action as a stopgap.
  3. Surface CLI auth expiry in the UI — a silently expired login also caused an in-session /remote-control activation to fail with a misleading "available with Claude for Enterprise" message.

Happy to provide sanitized copies of pointer files, timestamps, or logs on request.

View original on GitHub ↗