[BUG] Session history silently wiped after app update — no server-side backup, no export, no warning

This happened to me too, it sucks.

I built a toolkit to try help you fix it. Running diagnose.py from claude-code-session-recovery on those two directories tells you exactly which sessions are in which state. It splits them into: transcript present + metadata present (healthy); transcript present + metadata missing (recoverable via synth); metadata present + transcript missing (transcript needs backup first); both missing (depends on backup).

Before running any repairs, one clarification on the storage layers that might shape what's recoverable: the Desktop's session list renders from two separate places. The ~/Library/Application Support/Claude/IndexedDB/ directory is the cloud/bridge cache — it holds titles and cloud sync state. The file layer the toolkit works with is:

• Metadata files (what surfaces sessions in the local session list): ~/Library/Application Support/Claude/claude-code-sessions/<acct>/<org>/local_<uuid>.json
• Transcript files (conversation history): ~/.claude/projects/<project-slug>/*.jsonl

The cleanup pass that's typically behind mass transcript deletion targets the .jsonl files — it usually leaves the metadata JSON files alone. So the "15 session titles in UI" most likely means 15 metadata entries still exist, each pointing at a transcript file that's now gone. The 5 surviving transcripts may or may not have matching metadata entries.

For the deleted transcripts: Time Machine is the first thing worth checking before concluding they're gone. The ~/.claude/projects/ directory is hidden and sometimes falls outside default backup scope, but it's often covered. Check whether you have a snapshot predating the update via the Time Machine UI or tmutil listbackups. If a snapshot exists, find_missing_jsonls_in_backup.py in the toolkit can scan it for the deleted .jsonl files.

Toolkit is Windows-tested but the file formats are identical on macOS — paths above are the macOS equivalents. Full write-up at #56172.

I have the same issue on Pro plan with Claude Code desktop app on Windows 11.

For anyone who wants a proactive backup layer before the next update: I built Clean My Agent to scan and back up Claude Code session files to a safe local location on demand.

Updates need migration receipts.

Before any local metadata migration or IndexedDB cleanup, write a small receipt outside the app cache: app version, migration id, session count before/after, transcript roots scanned, backup/export path, and recoverable failures. If UI metadata is lost but JSONL remains, the app should offer a rebuild from transcripts.

The warning should be explicit too: which data is local-only, which is synced, and where to export. Silent local-only history is fine only if users can back it up before the update touches storage.

---

_Generated with ax._

[DATA LOSS] Cowork local sessions wiped without warning after update — paying Pro user

I'm a Claude Pro subscriber. After a recent automatic update, all my local Cowork sessions have disappeared with no migration, no warning, and no recovery option.

I had critical ongoing work sessions (client deliverables, hours of agentic work) that are simply gone. Checking ~/Library/Application Support/Claude/local-agent-mode-sessions/ confirms only one session remains — all others were destroyed.

This is not an inconvenience. This is a data loss event affecting paying customers.

Additional grievance: your data retention policy states Cowork activity is stored up to 30 days on your backend. Yet when sessions disappear client-side, there is apparently no way to recover them from that backend. So what exactly is being retained, and for whose benefit?

What I'm asking for:

1. A clear explanation of what happened to local sessions during the migration to remote sessions
2. A recovery path, or confirmation that data is permanently lost
3. A commitment that this will never happen again without explicit user consent and data export

A product update that silently destroys user work is a serious failure. Please treat it as such.

Adding a related-but-distinct trigger for this same symptom class (session shows blank/"No messages yet" while the transcript is fully intact on disk), since it might help narrow down the root cause.

Environment: Claude desktop app (Cowork) 1.24012.9, bundled Claude Code CLI 2.1.219, macOS.

Unlike the IndexedDB-purge-on-update scenario described above, I reproduced this without any app update, via a completely different path: an idle-session resume failure. ~/Library/Logs/Claude/main.log shows the exact mechanism:

[warn] [CCD CycleHealth] local_7c678c5d-... cli_execution_error (error_during_execution): No conversation found with session ID: fbcc7cac-c196-4ac8-9947-aca11b51c335
[info] [CCD] clearStaleResumeHandle session=local_7c678c5d-... reason=cli_resume_not_found_result dropping cliSessionId=fbcc7cac-c196-4ac8-9947-aca11b51c335 unarchivedCliSessionId=undefined
[error] Session local_7c678c5d-... query error: Claude Code returned an error result: No conversation found with session ID: fbcc7cac-c196-4ac8-9947-aca11b51c335
    at Cu.readMessages (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.chunk-DwT2CckN.js:100:21898)

A second variant with reason=getTranscript_empty fired on 14 sessions within a 15-second window while an external tool was simply reading those sessions' transcripts back-to-back (nothing destructive) — so this is easy to retrigger just by touching several idle/older sessions in quick succession.

Confirmed in every case: the backing .jsonl file is present and intact on disk (correct size, full line count) — it's just filed under a project-path key that changes when the session's cwd is a git worktree, e.g. ~/.claude/projects/-Users-...-claude-worktrees-<name>/<cliSessionId>.jsonl, which may be part of why the resume lookup fails to resolve it. Once clearStaleResumeHandle drops the mapping, the app appears to give up permanently rather than retry or re-resolve the path — so this looks like a resume/pointer bug rather than actual deletion, at least in this case.

Happy to share the full log excerpts if useful for debugging.