[BUG] Claude Code Desktop: session transcripts silently become permanently unavailable (cliSessionId nulled, no local recovery path) — follow-up to anthropics/claude-code#79044

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

## Description:

Follow-up to
anthropics/claude-code#79044 (closed), which I originally filed after noticing older Desktop sessions in the sidebar flip to "transcript unavailable" over time. That issue was closed without a fix being shipped, and two related issues (#63082, #56172) were closed "not planned" with unconfirmed community theories about the cause. I dug into my own local session data to move this from theory to evidence. Filing as a new issue since I can't reopen
anthropics/claude-code#79044.

## Diagnosis:

> Note: I used Claude Code to diagnose the problem and prepare this issue summary.

Inspected ~/Library/Application Support/Claude/claude-code-sessions/ directly, including a coincidental backup copy of that folder from ~7 weeks prior to this investigation. Findings:

1. Confirmed pointer-nulling in progress, not just historical. Diffing the old backup against current state: 8 sessions that had a valid cliSessionId in the backup now have that field set to null, and each flipped to transcriptUnavailable: true in the process. Zero sessions flipped the other direction (none recovered). This is an active, ongoing, one-directional process on this install — not a one-time event, and it does not self-heal on relaunch.
2. Scope: 102 of 154 tracked sessions (66%) are currently flagged. Age correlates loosely but isn't a clean cutoff — flagged sessions average 86 days old vs. 76 days for healthy ones, but ranges overlap heavily (flagged sessions as young as 13.7 days exist; healthy ones as old as 146 days exist).
3. **Edit (2026-09-09):** Local transcript is short-lived, and disappears well before the pointer breaks. A raw, unfiltered count of .jsonl files under ~/.claude/projects/ on this machine is exactly 2 (out of 154 tracked sessions). Both belong to the two youngest sessions in the index (0.9 and 1.9 days old at time of check). Every other session still holding a non-null cliSessionId — 55 of them, ranging 14.7 to 105.5 days old — has no matching local transcript. So, the transcript is written on session creation but evicted locally somewhere in the 2–15 day range, independent of and much earlier than the cliSessionId-nulling event (which, per the backup diff above, happens only after 7+ weeks). By the time a session surfaces as transcriptUnavailable in the sidebar, its content has typically been gone for weeks already — the pointer break is a delayed symptom, not the moment of loss. (The earlier community fix-amnesia.py workaround, and my initial claim that no local transcript is ever written, both assumed a persistent local cache that doesn't actually exist past the first couple of weeks.)
4. Tested and mostly ruled out a dual-account theory. This machine has two Claude accounts used in the Desktop app (enterprise + personal Pro). Local storage confirms two distinct account UUIDs (cross-checked against config.json's lastKnownAccountUuid). Broken-session rate is similar across both (61.4% vs 69.1%), so account-switching doesn't look like the direct trigger — though running two accounts' sessions through one shared local install may accelerate whatever volume/time-based process is responsible.

## Why this is a problem:

**Edit (2026-09-09):** Users lose access to legitimate past work with no warning, in two silent stages: the underlying transcript is evicted from local disk within roughly two weeks of a session's creation, and the sidebar entry only reports this — as transcriptUnavailable — much later, once its pointer is separately nulled. Neither stage is visible to the user when it happens. For anyone working on projects intermittently rather than daily, this means content is frequently gone before a user would ever think to revisit it.

### What Should Happen?

**Requested behavior:** Session transcripts should either (a) never be silently dereferenced while the underlying content still exists server-side, or (b) if genuinely pruned per a retention policy, that policy should be disclosed and ideally configurable, with a clear warning before content becomes unavailable rather than silent failure discovered after the fact.

### Error Messages/Logs

```shell
Sidebar entries show transcriptUnavailable: true in their local metadata (~/Library/Application Support/Claude/claude-code-sessions///local_.json); UI displays these as unable to load. No error is surfaced to the user at the time the transcript becomes unavailable.
```

### Steps to Reproduce

Reproduction:

1. Use Claude Code Desktop across multiple project directories on an intermittent (e.g. weekly) basis over several weeks.
2. Periodically snapshot ~/Library/Application Support/Claude/claude-code-sessions/ (copy the folder).
3. Compare cliSessionId and transcriptUnavailable fields for the same sessionId across snapshots taken weeks apart — some sessions will show cliSessionId transitioning from a valid UUID to null, with transcriptUnavailable flipping to true in the same transition.
4. **Added (2026-09-09):** Separately, check ~/.claude/projects//.jsonl for sessions of varying ages while their cliSessionId is still populated: only sessions roughly 2 weeks old or younger will have a matching file — older ones will already be missing it, well before transcriptUnavailable ever gets set.

### Claude Model

None

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

2.1.263 (Claude Code)

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

### Related issues:
anthropics/claude-code#79044 (my original report, closed without fix), #63082 (closed "not planned," same cliSessionId/transcriptUnavailable symptom, author of the unofficial fix-amnesia.py workaround script), #53717 (Windows, different mechanism — empty 1KB .jsonl stubs, still open), #56172 (Windows, closed "not planned," independent recovery toolkit). Happy to share sanitized (PII-scrubbed) session metadata diffs if useful for engineering triage.
**Edit (2026-09-09):** A commenter (@tonydzi ) ran the same diagnostic on Windows 11 (Claude Code 2.1.246) and found the opposite shape on a young index (<15 days old): 100% of sessions had a matching transcript, but the sidebar index covered only 3% of the .jsonl files actually on disk (17,593 orphaned transcripts with no index row). That check caught a bug in my own script — I'd been reconstructing project-folder slugs myself instead of reading the real directory names, which hid 2 legitimate matches and produced an inaccurate "0 of 154" figure. The corrected data above reflects the fix. Combined with Mycroft's numbers, this looks like one underlying local-cache lifecycle (transcript vs. index can each expire independently) rather than two unrelated platform bugs — see also
anthropics/claude-code#91017 for the mirror-image case. Thanks to @tonydzi for the correction.

Start by inspecting the session metadata under ~/Library/Application Support/Claude/claude-code-sessions///local_.json and matching files under ~/.claude/projects//.jsonl. Compare snapshots across session ages to establish when transcripts and cliSessionId values disappear; done means the retention or dereference behavior is understood and users receive an appropriate warning or recovery path.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.