Desktop app update deletes session history (sessions-index.json + .jsonl files)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/46621
2. https://github.com/anthropics/claude-code/issues/41591
3. https://github.com/anthropics/claude-code/issues/41458

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Same issue happened to me yesterday, sessions are completely gone, even on the browser version.

Confirming this on 2.1.126 (Windows 11) with two additional findings I haven't seen reported yet:

1. Manual restoration is not durable — the cleanup is recurring, not one-shot

When I copied a deleted .jsonl back into ~/.claude/projects/<encoded-path>/ from a backup, restarted the desktop app, and waited, the cleanup re-deleted the restored file on the next sync cycle. I reproduced this for 7 different sessions across 5 project folders. Plain file restoration on its own does not survive.

2. CLI re-registration appears to make a restored file persist (hypothesis, limited evidence)

Restoring the file and then running:

claude --resume <session-uuid> -p "(persistence marker)"

…from the original cwd seems to register the session with the cloud-side registry, after which the local .jsonl has not been re-pruned in my testing. I scripted this for 7 deleted sessions and all 7 are still present immediately after the operation. Caveat: small sample, limited verification window — I haven't yet confirmed durability across multiple cleanup cycles or app restarts. The strongest data point I have is one earlier session (f8780829) that was CLI-resumed several days ago and is still on disk now.

This is consistent with — but does not prove — a hypothesis that the cleanup uses cloud-registry membership as the retain/delete signal for local files, rather than just file presence on disk. Maintainer confirmation would be helpful here.

Forensic evidence consistent with the cloud-registry-mismatch hypothesis

• Files bypass the Recycle Bin entirely. Searched $Recycle.Bin for both .jsonl files and items originating from .claude\projects — zero hits in either case. So the deletion is DeleteFile() (Win32), not shell delete. Recovery via Recycle Bin is impossible.
• Affected UUIDs are absent from local Chromium storage. Searched %APPDATA%\Claude\IndexedDB\https_claude.ai_0.indexeddb.leveldb\ and %APPDATA%\Claude\Local Storage\leveldb\ for the deleted UUIDs — zero hits. Conversely, sessions that survived have entries in both.
• git-worktrees.json is empty ({"worktrees": {}}). This is not a Cowork-worktree GC. Project files (the actual work output Claude wrote) are intact — only the conversation transcripts are deleted.
• Sidebar entries persist after the file is deleted. Clicking them in the desktop app shows "No messages yet"; sending a message creates a new empty .jsonl with a fresh UUID, which is not linked to the deleted one. So the cloud-side label survives but the back-pointer to local content is broken.

Suggestion

A pragmatic interim fix that wouldn't require redesigning the cleanup: on app launch, scan ~/.claude/projects/ and import any local .jsonl UUIDs that are not yet in the cloud registry. That would self-heal the orphan state instead of treating registry-absence as a deletion authority.

If retention pruning is intentional (per #46621), please at minimum:

1. Expose a config flag ("sessionRetention": "indefinite" | "30d" | …) in settings.json.
2. Log every deletion with (uuid, original_path, timestamp, reason) so users can audit data loss.

Hit this bug on macOS (MacBook Pro M3). Lost all session history across multiple projects after a Claude Desktop app update.

What I found after investigating:

• ~/.claude/projects/ had only 1 project folder remaining (out of several I had worked in)
• ~/Library/Application Support/Claude/claude-code-sessions/ had only small metadata JSON files — no conversation content
• ~/Library/Application Support/Claude/local-agent-mode-sessions/ had no session files at all
• ~/.claude/backups/ was empty

The actual .jsonl conversation files were deleted by the update, not just the index. There is no recovery path.

The UI symptom was mixed — some sessions showed "No messages yet", others were missing from the sidebar entirely, and one session (the most recent one) was intact. This patchy pattern is what led me to investigate the filesystem directly.

This is a significant data loss issue. Weeks of conversation history and context are gone with no warning, no export option, and no way to restore. Please prioritize a fix — at minimum, the update process should never delete .jsonl files, and ideally, a backup should be made before any migration runs.

Hey ShreeshaJay,

The re-deletion on the next sync cycle is a key finding — it narrows the problem significantly. The Desktop's cleanup pass appears to be treating restored .jsonl files as orphans and removing them, which points to why your restoration didn't hold: without a corresponding local_*.json metadata entry in %APPDATA%\Claude\claude-code-sessions\, the Desktop has no record that the restored transcript belongs to any session. The cleanup pass sees an unregistered file and removes it.

Your CLI re-registration hypothesis is probably right — registering through the CLI likely creates enough of an entry for the cleanup pass to treat the file as legitimate. The more durable fix is synthesising the full metadata entry: a local_*.json file with the session title, timestamp, and cliSessionId wired to the restored transcript UUID. That's what synth_session_metadata.py in claude-code-session-recovery does — it creates metadata entries from transcript files, which should make the Desktop treat those files as owned sessions rather than orphans.

Worth trying on one session before applying it to all of them, since your finding that plain restoration doesn't survive a sync cycle is something I haven't seen documented elsewhere. Full write-up at #56172.

That massively sucks and I hope that I can help you recover it. Here's what I think might be going on:

From what you've described, it looks like the situation differs across your projects — so it might be worth treating them separately.

For Projects C and D — the .jsonl transcript files survived but the sessions-index.json was deleted. That's actually the more recoverable case: the conversation history is on disk, it's just that Desktop has nothing to render in the session list. On macOS the equivalent of the Windows metadata layer lives at ~/Library/Application Support/Claude/claude-code-sessions/ — if you check that directory and find it empty (or missing entries for the affected projects), that confirms the index was the only casualty. I built a tool for exactly this — synth_session_metadata.py from claude-code-session-recovery. It walks ~/.claude/projects/, finds transcript files with no valid metadata pointer, and synthesises the entries needed to surface them back in the session list. The toolkit is Windows-tested but the file formats are identical on macOS — the scripts need path adjustments for the macOS metadata location, but the logic transfers directly.

For Projects A and B — the .jsonl files were also deleted. Before concluding those are gone, check Time Machine (if enabled) and any cloud sync covering your home directory; ~/.claude/projects/ often falls outside typical backup scope, but it's worth checking. If a snapshot covers the period before the update, the transcripts would be there.

Full write-up at #56172.

Following up on my earlier comment. I ran the recovery toolkit today on macOS (MacBook Pro M3) and wanted to document the full findings for anyone else hitting this on Mac.

Environment

• macOS, MacBook Pro M3
• Claude Desktop (latest)
• Python 3.x, no extra dependencies

Running the toolkit on macOS

The toolkit is Windows-native so the path detection doesn't work directly on Mac. The fix is to create a fixture directory with symlinks pointing at the macOS equivalents, then pass --state:

mkdir -p ~/Desktop/claude-state/appdata
ln -s "$HOME/Library/Application Support/Claude" ~/Desktop/claude-state/appdata/Claude
ln -s "$HOME/.claude/projects" ~/Desktop/claude-state/projects

python3 tools/diagnose.py --state ~/Desktop/claude-state

The --state flag is also required for the repair script and find_missing_jsonls_in_backup.py, otherwise they either error with "state schema not recognised" or compute a different diagnosis ID (token mismatch). Passing --state to both resolved this.

What diagnose.py found

Diagnosis ID : 0e7dfd9d
Metadata     : 10 files  (4 with cliSessionId,  6 missing)
JSONL files  : 2

PROBLEM FOUND: Sessions appear in the session list but open with no conversation history
PROBLEM FOUND: Session is in the session list but its conversation history is missing from disk

Dry-run output from repair_session_metadata.py

All 6 sessions missing cliSessionId came back as ORPHAN — no JSONL match in window. The sessions lost were:

• <Project_Name> 1 (2026-03-10)
• <Project_Name> 2 (2026-03-13)
• <Project_Name> 3 (2026-03-24)
• <Project_Name> 4 (2026-03-25)
• <Project_Name> 5 (2026-03-27)
• <Project_Name> 6 (2026-04-12)

Repaired: 0 / Refused: 0 / Orphan: 6 — nothing to repair because the .jsonl files themselves were deleted by the app update, not just unlinked from metadata.

find_missing_jsonls_in_backup.py output

Sessions with cliSessionId but no live JSONL: 2
Recoverable from backup: 0
Not found in any backup: 2
Summary: 0 recoverable from backup, 2 not found.

Conclusion

The toolkit worked correctly and the macOS path workaround is straightforward. The data loss in my case is confirmed unrecoverable — the .jsonl files were deleted outright by the app update, not just orphaned from their metadata. The toolkit correctly diagnosed this and didn't attempt a false repair.

For anyone else on macOS hitting the token mismatch error: add --state <your-fixture-path> to the repair script invocation, same as diagnose. That resolves it.

Update: while testing I also noticed that find_missing_jsonls_in_backup.py was the only script that didn't receive the native macOS/Linux path detection from commit 0609930 — diagnose.py and repair_session_metadata.py were both updated but this one was missed. I've submitted a fix upstream: https://github.com/BasedGPT/claude-code-session-recovery/pull/6

Hope this macOS walkthrough helps others. Thanks to the maintainer for building this — even a confirmed-unrecoverable diagnosis is genuinely useful closure.

Also affected — Windows 11, v2.1.149

Confirming this with additional technical detail in case it helps diagnosis.

Inspecting the session metadata files at:
%APPDATA%\Roaming\Claude\claude-code-sessions\{workspace-uuid}\{store-uuid}\local_{session-uuid}.json

All affected sessions have "transcriptUnavailable": true with no cliSessionId field.
Post-redesign sessions that work correctly have a cliSessionId pointing to a .jsonl
file under ~\.claude\projects\{project}\. No such file exists for any pre-redesign session.

Scale: 25 of 27 sessions affected, oldest dating to 2026-02-01.

The session metadata (title, cwd, completedTurns, timestamps) survives intact — only
the transcript content is gone. This points to a storage format migration that was never
performed, rather than accidental file deletion.

Workaround for future sessions: back up these two locations incrementally:

• ~\.claude\projects\ (transcript JSONL files)
• %APPDATA%\Claude\claude-code-sessions\ (session metadata index)

Thanks for documenting this, legend — it's the first confirmed macOS run of the toolkit and it's genuinely useful to have the --state fixture approach written up in a public thread.

The key result: the toolkit correctly identified both failure modes present in your setup — six sessions with missing cliSessionId, two with a cliSessionId pointing at transcript files that don't exist on disk — and returned Repaired: 0 / Orphan: 6 without attempting a false repair. That's the right outcome. No JSONL to link to, so no link gets synthesised.

The --state fixture approach (symlinks to the macOS equivalents, then passing --state to each script) confirms the core logic transfers without modification. Path detection is the only platform-specific part. I'll add native macOS path detection so the workaround isn't needed in a future release, and I'll document your steps in the meantime.

Full write-up at #56172.

Hey jmichelmore,

The transcriptUnavailable: true flag with no cliSessionId is a pattern I haven't seen documented before.

My guess: those 25 sessions predate the current .jsonl transcript format. The Desktop is marking them explicitly unavailable rather than just missing a pointer — which to me suggests the app knows no transcript was ever written in the current format, rather than that one existed and got lost. That's a different failure mode from the ones the toolkit handles, where the JSONL exists but the metadata layer lost track of it.

Before writing them off — the completedTurns field surviving in the metadata is worth paying attention to. If those sessions show non-zero values, the Desktop was tracking turn activity for them, which may mean there was a storage format before .jsonl that's now unread. Worth checking %APPDATA%\Claude\ for any subdirectory that isn't claude-code-sessions\ — there may be an older transcript store somewhere.

If nothing surfaces there, the toolkit (claude-code-session-recovery) can confirm the diagnosis but can't recover transcripts that were never written in the current format. The backup guidance in your comment is the right mitigation going forward. Full write-up at #56172.

As a work around I have setup Claude Code to backup all my project files every four hours using duplicati, so I have only lost 4 hours work at the most and anything that I want to make sure that I don't lose I use a /backup command to force a backup.
The loss of these projects would only have been with the second or third last update last week as I'm pretty sure they were all there prior to that.
It is just lucky that one of my projects was a project continuation app that created a number of MDs that contained the most important information for each project so I can revive most of the lost projects.

Thanks
John Michelmore

________________________________
From: BasedGPT @.*>
Sent: Wednesday, May 27, 2026 11:37 PM
To: anthropics/claude-code @.*>
Cc: jmichelmore @.>; Comment @.>
Subject: Re: [anthropics/claude-code] Desktop app update deletes session history (sessions-index.json + .jsonl files) (Issue #48334)

[https://avatars.githubusercontent.com/u/131253485?s=20&v=4]BasedGPT left a comment (anthropics/claude-code#48334)<https://github.com/anthropics/claude-code/issues/48334#issuecomment-4555017203>

Hey jmichelmore,

The transcriptUnavailable: true flag with no cliSessionId is a pattern I haven't seen documented before.

My guess: those 25 sessions predate the current .jsonl transcript format. The Desktop is marking them explicitly unavailable rather than just missing a pointer — which to me suggests the app knows no transcript was ever written in the current format, rather than that one existed and got lost. That's a different failure mode from the ones the toolkit handles, where the JSONL exists but the metadata layer lost track of it.

Before writing them off — the completedTurns field surviving in the metadata is worth paying attention to. If those sessions show non-zero values, the Desktop was tracking turn activity for them, which may mean there was a storage format before .jsonl that's now unread. Worth checking %APPDATA%\Claude\ for any subdirectory that isn't claude-code-sessions\ — there may be an older transcript store somewhere.

If nothing surfaces there, the toolkit (claude-code-session-recovery) can confirm the diagnosis but can't recover transcripts that were never written in the current format. The backup guidance in your comment is the right mitigation going forward. Full write-up at #56172<https://github.com/anthropics/claude-code/issues/56172>.

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/48334?email_source=notifications&email_token=AN7HHS4UXMWE3C3PIW5UFK3443VSDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVGUYDCNZSGAZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4555017203>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AN7HHS55C55Q6KG4YEMZT2D443VSDAVCNFSM6AAAAACXZZYRW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNJVGAYTOMRQGM>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AN7HHSY5WM2OOIUHWNFWXBD443VSDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVGUYDCNZSGAZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/AN7HHS7PFDGVYN22SMSLNRL443VSDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVGUYDCNZSGAZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today!
You are receiving this because you commented.Message ID: @.***>

Thanks for the quick follow-up and for confirming the behaviour was correct — knowing it was a true unrecoverable state rather than a tool gap actually helps close it out mentally.

Glad the --state fixture approach transferred cleanly. And while testing, I noticed that find_missing_jsonls_in_backup.py was the only script that didn't receive the native macOS/Linux path detection from commit 0609930 — diagnose.py and repair_session_metadata.py were both updated but this one was missed. I've submitted a fix: PR #6.

I've also written up the full incident — root cause, recovery steps, and the broader lesson about keeping the engineering mindset sharp even when leaning on AI tools — as a blog post if it's useful for anyone landing here from search: When AI Ate My Work: A Claude Code Data Loss Incident

Thanks again for building this. Even a confirmed-unrecoverable result is far better than uncertainty.

You're welcome, glad it helped — just merged the PR fix too, cheers.

That's good to hear — same solution I ended up with. Four-hour window is a reasonable safety net.

If you're on macOS and your .jsonl transcripts got deleted, I built a tool that restores them from Time Machine or local APFS snapshots: garrettmoss/restore-claude-history. If a backup or snapshot predates the deletion, it'll pull the lost transcripts back.

It covers a different piece than @BasedGPT's claude-code-session-recovery (Windows): his toolkit rebuilds the Desktop metadata so sessions show up again, mine (MacOS) gets the deleted transcript file back.

I think this is in line with @rpranjan11's recommendation in his blog post to enable TM backups right away. Here's how to actually use those to recover your chats.

Also filed #62272 on the underlying deletion behavior.

Thanks for building this @garrettmoss — this is exactly the missing piece for Mac users who still have Time Machine or APFS snapshots available.

In my case, unfortunately, neither was set up at the time of the deletion, so the transcripts were unrecoverable. That experience is what pushed me to write about it — both to document the incident and to make sure other engineers don't end up in the same situation.

I wrote two articles covering the full story if it's useful for anyone landing here:

1. When AI Ate My Work — the incident, root cause, and why TM backups matter
2. Claude Code Session Recovery on macOS — step-by-step toolkit guide

Your tool + @BasedGPT's toolkit together now cover the full recovery surface on macOS. Good to see the ecosystem filling in.