[BUG] Session transcripts silently auto-deleted after 30 days; sidebar shows ghost entries that error on click

[ashpat00]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Environment
• Claude Code: 2.1.149
• Claude Desktop on Windows 11 Pro
• Entrypoint: claude-desktop
Summary
The default cleanupPeriodDays: 30 silently deletes session transcript JSONL files with no notification, no opt-in, and no exposure in the desktop UI. The sidebar continues to advertise those sessions because the cleanup leaves their metadata records behind. Clicking any of them shows "session not found on disk." Of my 38 sidebar entries, 26 are broken and the conversation content is unrecoverable — months of work on a real product, gone with no warning.

What Should Happen?

I should be able to continue in the session where I left off.

Error Messages/Logs

Steps to Reproduce

Reproduction (visible to user)

1. Use Claude Code Desktop normally for 30+ days.
2. Click a session in the sidebar dated more than ~30 days ago.
3. Error: "session not found on disk."
4. There is no UI affordance to recover, explain, or clean up the broken entry.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.149

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

Root cause (from investigation of the local files)
Two stacked problems:

1. Silent cleanup with orphaned sidebar metadata. cleanupPeriodDays (default 30, per strings in claude.exe) deletes JSONL transcripts at ~/.claude/projects//.jsonl based on file age, but does NOT remove the corresponding sidebar metadata file at ~/AppData/Roaming/Claude/claude-code-sessions/.../.json. The sidebar therefore lists sessions whose transcripts no longer exist. ~/.claude/.last-cleanup confirms cleanup ran today.
2. Schema-upgrade gap in older metadata. Sidebar metadata was extended at some point with a cliSessionId field that points to the transcript filename. Records created before that change were never backfilled, so even if the transcript still existed on disk, the desktop app has no way to map the sidebar entry to it.

The boundary lines up exactly with a 30-day retention window. There was no Recycle Bin entry, no Windows File History (not enabled by default), no OneDrive backup (AppData isn't synced by default), and no other backup — so the deletion is final.

Why this is a UX failure, not just a bug
"Cleanup" should not mean "delete the user's work history without telling them." There's a real difference between housekeeping (caches, stale locks, process state) and chat/code session transcripts. The current product collapses both under one buried config key. A user who never reads the binary's embedded help has no way to know any of this is happening.

[BasedGPT]

This happened to me too, which is why I built a tool to prevent it happening again, it sucks.

One check worth running before concluding those transcripts are gone if you haven't already: Windows Volume Shadow Copies ("Previous Versions"). This is distinct from Windows File History, which you mentioned isn't enabled. VSS takes automatic point-in-time snapshots of the system drive — separate mechanism, often on by default for Windows 11 Pro. Right-click %USERPROFILE%\.claude\projects\ → Properties → "Previous Versions" tab. If there's a snapshot predating today's cleanup run, the deleted .jsonl files should be retrievable from there.

If VSS doesn't have anything, diagnose.py in claude-code-session-recovery will give you a clean read on which sessions fall into which failure mode — useful to run before concluding anything, especially since your two issues overlap.

The root cause is upstream: my toolkit can't fix the settings-loading bypass that lets cleanup run with the wrong period. But it addresses the file-layer side of what you're describing, and your diagnosis on both failure modes is accurate.

The two things coexisting here are:

Sessions with no cliSessionId (schema-upgrade gap): these were already broken before cleanup ran. If the corresponding transcript files still exist on disk (they may have survived if their age was under 30 days), repair_session_metadata.py in claude-code-session-recovery can backfill the pointer by matching against transcripts in ~\.claude\projects\. Whether those sessions are recoverable depends on whether the transcripts survived.

Sessions with cliSessionId intact but transcript deleted: the metadata entry is fine; the file it points to is gone. This is the harder case.

For going forward: the two directories worth backing up are %APPDATA%\Claude\claude-code-sessions\ (metadata files) and %USERPROFILE%\.claude\projects\ (transcripts). Both need to be intact for a session to surface and open correctly. A simple scheduled robocopy covers the exposure.

Full write-up on claude-code-session-recovery at #56172.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.