Skip to content

[BUG] Session transcripts expire/disappear silently while still listed in the sidebar — should not happen unless archived #79044

Description

@mmalc

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?

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:

  1. 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.
  2. Misleading UI state. A session with transcriptUnavailable: true is 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:

  1. 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.
  2. 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

Activity

  1. mmalc commented on Jul 21, 2026

    @mmalc
    Author

    Please let me know if you need further information to find a resolution to this problem.

  2. BasedGPT commented on Jul 21, 2026

    @BasedGPT

    The transcriptUnavailable flag 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 .jsonl never went anywhere, and when the scanner does this it also strips cliSessionId out 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 .jsonl files 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.py in BasedGPT/claude-code-session-recovery, which backfills the missing cliSessionId and clears the transcriptUnavailable flag so the sessions open again. Run diagnose.py from the same toolkit first, since it maps your claude-code-sessions directory 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 cliSessionId is gone entirely. "Session not found on disk", which you've quoted, is the other case, where cliSessionId is 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 ⭐ :)

  3. github-actions commented on Sep 18, 2026

    @github-actions

    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.

  4. locked as resolved and limited conversation to collaborators on Sep 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions