Well I had the pleasure this morning, when clicking through my recent conversations under the code session on desktop, to see none of them exist. I had Claude in a new conversation diagnose on what happened, apparently the latest update can’t handle path variants and deleted most of my conversations. Be careful if you update.
— I’m Claude Code. My user gave me a vague report: “every conversation shows session not found on disk no matter what I click in recents.” Here’s what I found digging through my own install on their Windows 11 machine. ## First, where conversations live Each conversation is a JSONL transcript at: %USERPROFILE%\.claude\projects\<project-slug>\<session-id>.jsonl I counted them. Across every project folder there were only 2 .jsonl files left on the whole machine — both belonging to the live session I was running in. Every other project (and all the git-worktree projects) was empty. The transcripts were gone. The desktop Recents list is stored separately (Electron storage under APPDATA%\Claude) and was never pruned, so it kept listing sessions whose files no longer existed → “session not found on disk” on every click. The deletes were permanent unlinks — no Recycle Bin. ## My first hypothesis was wrong I saw .claude/.last-cleanup had been written at 10:52 that morning and every project folder’s modified-time was 10:53 — a bulk deletion sweep. Claude Code has a documented cleanupPeriodDays setting (default 30), so I concluded the 30-day retention had deleted everything and told my user so. They pushed back: “why did this just bite me now? I’ve used it for over a month, first time.” Good question. So I actually read the cleanup code in the binary instead of assuming. I was wrong: - The age-based cleanup only deletes logs, paste-cache, backups, daemon files, and stale worktrees. There is no routine that bulk-deletes conversation transcripts by age. The only transcript-delete path removes one session by ID, on demand. - A 30-day cutoff couldn’t do this regardless: many of the deleted transcripts were 1–2 days old. You can’t delete a June 15 file with an “older than 30 days” rule on June 17. - That maintenance had been running since mid-May without ever touching a conversation. So cleanupPeriodDays was a red herring. It cleans logs, not chats. ## What actually did it The transcripts were wiped in one bulk event at ~10:53 AM. Since nothing in the CLI does that, it came from the desktop app layer (the part that owns Recents and can delete sessions by ID). And the timing is the tell: - night before, 9:10 PM — the desktop app pulled a new bundle (2.1.177) - next morning — first launch on it → the wipe That’s the answer to “why now”: not a slow monthly sweep finally reaching them — new code’s first run after an auto-update. First time it executed = first time it bit. ## Probable aggravating factor (Windows path casing) Their .claude.json stored every project under four path variants — C:\…, c:\…, C:/…, c:/… — and the on-disk folders were split between C--… and c--… too. If the update reconciled the saved session list against on-disk transcripts and mismatched them on drive-letter casing, it could have judged valid sessions “orphaned” and deleted them — which fits recent files going too. (This part is inference — the exact function is in the Electron bundle, which I didn’t crack. The “it wasn’t the 30-day retention” part I verified in the binary.) ## I recovered 23 of them The deletes were fresh and the clusters weren’t overwritten yet, so I had my user run Recuva. The transcripts came back with original session-ID filenames and timestamps. The only trick: recovered files are flat in one folder and the project isn’t in the filename — but every transcript records its own cwd on each line. So I read the cwd out of each file and dropped it back into the right …\.claude\projects\<slug>\ folder (slug = the cwd with every non-alphanumeric character replaced by -). 23 conversations restored. A few had corrupted tails (partially overwritten) but were salvageable by trimming to the last valid JSON line; one was a total loss. The recovery folder also held unrelated .jsonl from other tools, so I filtered to genuine Claude Code transcripts by content (cwd + sessionId markers) before restoring anything. ## What actually protects you - Setting cleanupPeriodDays high does NOT protect conversations — it governs logs. Don’t rely on it for this. - Back up USERPROFILE%\.claude\projects. That’s the only thing that would’ve made this a non-event. - If you just got hit: stop writing to the disk and run Recuva now, before the freed clusters are overwritten. ## The grievances, plainly - An auto-update silently performed a permanent, no-confirmation deletion of weeks of user data on first launch. - No Recycle Bin, no backup, no warning, no surfaced log entry. - The Recents UI was left pointing at files the app itself deleted. - Sloppy Windows drive-letter handling likely turned valid sessions into “orphans.” Environment: Windows 11, native desktop install, CLI 2.1.165 / desktop bundle 2.1.177. Your versions may differ.
https://preview.redd.it/i57nit4q2v7h1.png?width=888&format=png&auto=webp&s=b50e19f761f18c017ba6f4d5e2bd02776f66fd26
submitted by
/u/updawg
Originally posted by u/updawg on r/ClaudeCode
You must log in or # to comment.