[BUG] Session transcripts expire/disappear silently while still listed in the sidebar — should not happen unless archived
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Here's a draft you can paste directly into a new issue at github.com/anthropics/claude-code/issues:
---
Title: Session transcripts expire/disappear silently while still listed in the sidebar — should not happen unless archived
Environment:
- Claude Code desktop app version: 1.22209.3 (babe11), 2026-07-19
- macOS (Darwin 24.6.0)
- Usage pattern: project sessions worked on intermittently (e.g. weekly), not daily
Description:
Older sessions still appear in the recent-sessions sidebar with their correct titles, but clicking them shows:
Session not found on disk Send a message to start fresh in this directory.
with only Archive/Delete as options.
Diagnosis:
I inspected the underlying session metadata files directly (~/Library/Application Support/Claude/claude-code-sessions/*/*/*.json). Each broken session's JSON contains an explicit flag:
"transcriptUnavailable": true
This is present on a large number of session files, not an isolated case — it does not appear to be file corruption, a pathing bug, or related to using multiple accounts on one machine (I confirmed both a working and a broken session live under the identical account/org folder). It looks like transcript content is being pruned/expired after some retention period, while the lightweight metadata entry (title, timestamps, isArchived: false) is retained indefinitely and continues to render normally in the sidebar.
Why this is a problem:
- Data loss without consent or warning. Sessions disappear (their content becomes unrecoverable) with no indication this will happen, and no way to opt out short of manually archiving every session before it ages out. Users who work intermittently (e.g. weekends only) are disproportionately affected, since more time elapses between visits.
- Misleading UI state. A session with
transcriptUnavailable: trueis visually indistinguishable from a healthy one in the sidebar — same title, same normal appearance — until you click it and hit a dead end. There's no visual cue (graying out, icon, badge) that content is gone or at risk.
What Should Happen?
Requested behavior:
- Transcripts should not be deleted/expired for sessions the user has not explicitly archived. If storage/retention limits require pruning, archiving should be the mechanism that opts a session in or out of it — not a silent, time-based purge applied uniformly.
- If some form of expiry must remain (e.g. for storage management), the sidebar should visually distinguish sessions whose transcript is no longer available (or approaching expiry) before the user clicks in, rather than presenting them identically to live sessions.
Error Messages/Logs
Steps to Reproduce
Reproduction:
grep -l "transcriptUnavailable" ~/Library/Application\ Support/Claude/claude-code-sessions///*.json
returns numerous session files where this flag is true, spanning sessions from several weeks back, while more recent sessions do not have it set.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude Code desktop app version: 1.22209.3 (babe11), 2026-07-19
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
3 Comments
Please let me know if you need further information to find a resolution to this problem.
The
transcriptUnavailableflag gets written by the Desktop startup scanner even when the transcript file is sitting on disk untouched. I've had it set on sessions whose.jsonlnever went anywhere, and when the scanner does this it also stripscliSessionIdout of the metadata file, which is what actually stops the session opening. It's an open regression upstream at #63082, and it's been confirmed on Windows as well as macOS.That leaves the pruning conclusion untested. Your grep tells you the flag is set; it doesn't tell you whether the conversation history is still on disk. Look in
~/.claude/projects/for the.jsonlfiles belonging to the affected sessions and sort by modified date. If they're there, nothing has expired and the metadata layer is just no longer pointing at them.That case is recoverable and I built a tool for it:
repair_session_metadata.pyinBasedGPT/claude-code-session-recovery, which backfills the missingcliSessionIdand clears thetranscriptUnavailableflag so the sessions open again. Rundiagnose.pyfrom the same toolkit first, since it maps yourclaude-code-sessionsdirectory against~/.claude/projects/and shows which sessions still have a surviving transcript before you change anything.One thing worth separating in the report: the scanner regression normally presents as "No messages yet" when you open the session, because
cliSessionIdis gone entirely. "Session not found on disk", which you've quoted, is the other case, wherecliSessionIdis still present and names a file that genuinely isn't there. If some of your affected sessions show one and some show the other, that's two different problems in one batch, and they have different answers.Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.