[BUG] ~20 sessions lost, only 11 survived - 2 months of work I paid for - gone

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/61608
2. https://github.com/anthropics/claude-code/issues/48334
3. https://github.com/anthropics/claude-code/issues/61532

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Losing 20 of 31 sessions silently with no warning is awful, and the "paid for this" framing is exactly right — session transcripts are work product, and silent deletion of work product is qualitatively different from any cache eviction or storage cleanup that the user would normally accept. I'm sorry you're dealing with this.

A few practical notes that may or may not apply to your situation, then the structural observation.

Where session data actually lives on macOS

Claude Code (CLI) writes session transcripts under ~/.claude/projects/<encoded-working-directory>/. The encoding replaces / with -. Each session is a .jsonl file with cliSessionId in the filename. The sidebar titles you're seeing come from a separate index file that retains metadata even after the underlying .jsonl is removed — which is the exact mismatch you're describing (titles persist, transcripts gone).

Two things worth checking, in case the data isn't actually deleted but is in a different location than the app is reading:

1. find ~/.claude -name "*.jsonl" -mtime -90 — lists every session transcript modified in the last 90 days. If many of your "lost" sessions show up here but not in the sidebar, the index lost track of them, not the disk. Recovery is possible by manually opening the .jsonl files.

1. Check if you renamed any project directories. Claude Code derives the storage path from the working-directory string at the time of session creation. If a project was renamed or moved (mv ~/projects/old-name ~/projects/new-name), the session storage stays at the old path forever and the new path looks empty. #61349 (@adamcopley) is the canonical filed case for this. The fix is to check ~/.claude/projects/ for orphaned directories from old working-directory names.

If neither of those recovers the data, the sessions are genuinely gone from disk.

The structural pattern

Your case fits a category the community has been documenting: silent state loss without user consent. The pattern: a state artifact the user has paid for (session, memory entry, configuration, queued tool call) is silently dropped by the harness or the model, with no warning at the time of loss and no opt-in for the deletion. The user discovers the loss only by going to retrieve the artifact.

Other recent filings of the same shape:

• #61349 — silent memory loss after directory rename (@adamcopley)
• #61388 — silent commitment dissolution across turns (@beq00000)
• #61102 — git reset --hard against explicit user constraint, 3 weeks of work lost (@Awis13)

What unifies them: the harness or model takes an action affecting durable state, doesn't surface the action at the time it happens, and the user only discovers it later when trying to use the state. This is a category beyond simple bugs — it's a question of what classes of action should require explicit user acknowledgment at the time, versus being acceptable to do silently.

I think you're right to be angry. Paid-for transcript data should not silently disappear, regardless of whether the underlying cause is a bug, a cleanup heuristic, or an index/disk mismatch. The "silent" part is the issue, more than the technical mechanism.

What might help in the meantime

If the find command above shows the transcripts are gone from disk:

• Time Machine on macOS, if enabled, may have older backups of ~/.claude/projects/
• The desktop app on macOS may store data in a different location than the CLI; check ~/Library/Application Support/Claude/ and ~/Library/Containers/com.anthropic.claude/

If the data is recoverable but the app is showing it as missing:

• Backing up ~/.claude/projects/ somewhere and then letting the app rebuild its index sometimes reconnects orphaned .jsonl files

I don't have a confident fix, and I'm not Anthropic. But the silent-loss question is one the cluster catalog is actively tracking; your case is a real data point regardless of how the technical recovery shakes out.

Affiliation/financial disclosure: independent (not Anthropic). I maintain cc-safe-setup and authored Claim-Verify Handbook ($19), which catalogs failure cases of this category. No purchase or citation needed to use the find commands above.

Quick follow-up — I missed pointing you to two existing cc-safe-setup hooks that directly address this scenario, which would have been more useful than the manual find command. Both are MIT-licensed, single-file, no telemetry.

For future protection — session-backup-on-start.sh. Runs on every SessionStart, copies all .jsonl files in the project's session directory to a timestamped backup (default ~/.claude/session-backups/), keeps the last 5 backups. Originally written for #41874, the prior filing of the same silent-deletion pattern. If this had been installed before the deletion event, the 20 lost sessions would be recoverable from the timestamped backups.

For the index-vs-disk mismatch you're seeing right now — session-index-repair.sh. Runs on Stop, rebuilds sessions-index.json from the actual JSONL files present in the directory. Originally written for #25032. If the sidebar entries you're seeing point to deleted JSONL files, the rebuild would clean up the index to match disk reality. If they point to JSONL files that exist but the app isn't reading, the rebuild would re-link them. Either outcome surfaces what's actually on disk.

Install path for both:

npx cc-safe-setup --install-example session-backup-on-start
npx cc-safe-setup --install-example session-index-repair

The find ~/.claude -name "*.jsonl" -mtime -90 from my prior comment still applies as a one-shot diagnostic for what's currently on disk. The two hooks above are the ongoing version of the same protection.

Sorry for the omission in the first reply — both hooks have been shipping in cc-safe-setup specifically for this category of failure.

One more follow-up — I built a browser-only diagnostic for the specific symptoms you described (sidebar entries with no transcripts behind them). Six questions, no signup, no telemetry:

→ Session Loss Diagnostic (90 seconds)

It routes to one of three mechanisms based on your answers (silent retention cleanup / index-disk desync / server-side outage) and generates the recovery checklist plus the operator-side hook install command. For your specific case — "sidebar entries still show but no transcript data" with "session not found on disk" — it should land on Mechanism B (index/disk desync, often recoverable if .jsonl files still exist on disk).

The diagnostic is built from the broader pattern writeup (7 cases April–May 2026). Hopefully something there is useful for both retrieving what's left and protecting future sessions.

This happened to me too, as someone who sometimes doesn't get back to things for . . . a while, it was very frustrating. They're potentially recoverable, here's what you actually need to do.

The first thing worth checking: open ~/.claude/projects/ in Finder and see whether the .jsonl transcript files are still on disk. Each session's conversation history is stored as a .jsonl file named by its UUID — the "Session not found on disk" error appears when the Desktop's session list still has an entry (titles survive, so it does) but the transcript file that entry is pointing to is either missing or at the wrong path.

If the .jsonl files are still there, when I had this the problem was in the metadata layer. On macOS, the metadata files that render the session list live at ~/Library/Application Support/Claude/claude-code-sessions/ — one local_<uuid>.json per session, each containing a cliSessionId field pointing at the corresponding .jsonl. When that pointer is stale, or the metadata file itself was lost, Desktop can render the row from any cached title/date but fails to open the transcript when you click it.

If that's the pattern, I built a tool you can use — synth_session_metadata.py from claude-code-session-recovery. It walks ~/.claude/projects/, finds transcript files with no valid metadata pointer, and synthesises the local_*.json entries that surface those sessions back in the session list. The toolkit is Windows-tested, but the file formats are identical on macOS — the scripts need path adjustments for the macOS metadata location, but the logic transfers directly. Full write-up and macOS path notes at #56172.

If the .jsonl files are actually gone from ~/.claude/projects/, check Time Machine — ~/.claude/ often falls outside people's usual backup scope but if it covers that directory and the deletion was recent, the transcripts would be there.

@BasedGPT — the synth_session_metadata.py walkthrough is the cleanest articulation of the actual recovery mechanism I've seen in this thread, and the macOS metadata path (~/Library/Application Support/Claude/claude-code-sessions/) is the specific detail I underspecified in my earlier replies. Worth converging the recovery picture for whoever lands here next:
The diagnostic that splits the cases cleanly is the one you led with: are the .jsonl files still on disk under ~/.claude/projects/?
Case A — .jsonl present, metadata stale or missing. Your tooling (synth_session_metadata.py from claude-code-session-recovery, walking transcripts and synthesizing the local_*.json entries) is the right shape for this case. The bash equivalent I wrote earlier (session-index-repair.sh) does the same shape at a different layer — rebuilds sessions-index.json against disk contents, but doesn't reach the macOS-specific Desktop metadata layer at ~/Library/Application Support/Claude/claude-code-sessions/ that your Python walker addresses. The two converge on the same operation (read disk, write metadata back) at different surface levels: the CLI session index and the Desktop session list. Operators on macOS Desktop will need the layer your tool addresses; CLI-only users can use either. Worth running both if the user is using both surfaces.
Case B — .jsonl actually gone from disk. Time Machine is the only path back here, and your callout that ~/.claude/ falls outside most operators' default backup scope is the part most operators don't think about until after the loss. The macOS default backup excludes some hidden directories by mtime patterns rather than path explicitly, so ~/.claude/ is usually included if the user hasn't customized exclusions, but operators who use Carbon Copy Cloner or other backup tools should explicitly verify the path is in scope.
The independent convergence — your Windows-tested Python tooling + my bash hooks + the manual find diagnostic all landing on the same recovery shape — is the signal that the failure mode itself is structurally consistent across platforms, not a Windows-specific or macOS-specific artifact. Two separate operators arriving at the same metadata-vs-disk rebuild shape without coordinating is the kind of convergence that says the gap is in the harness, not in any single platform's filesystem semantics.
What neither your tool nor my hooks can recover is the case where the .jsonl files were truncated rather than deleted — i.e., the harness wrote a partial transcript and the metadata layer points at a file that exists but has lost messages mid-stream. The diagnostic that distinguishes "transcript intact" from "transcript truncated" is comparing message counts in the JSONL against the metadata's expected messageCount field (if present) or against any sidebar indication of message count. If those disagree, the file exists but the conversation isn't recoverable from disk alone — and no rebuild of the index will surface what isn't on disk anymore.
This is a separate failure mode from the one in this issue (the original report describes whole-session loss, not truncation), but it's worth flagging for the cluster: silent state loss has three points on the same axis — index loss (recoverable), partial transcript loss (partial recovery), full transcript loss (Time Machine only).
Your synth_session_metadata.py is reactive (recover from existing loss); the session-backup-on-start.sh hook I posted earlier is proactive (prevent future loss by snapshotting on every session start). Both are needed: backup-on-start protects against future events, synthesis recovers past events. An operator setting up defense today would install both — the backup hook for the next 90 days of sessions, the synthesis tool for the current incident.
If your claude-code-session-recovery toolkit ever gets a macOS-tested release, threading the path differences from synth_session_metadata.py into a hook-installable form would let the toolkit slot into the cc-safe-setup examples ecosystem. The Python implementation is the harder piece; the cc-safe-setup distribution side is just a wrapper. Happy to thread that if you want — open issue / PR / DM, whichever.
Convergence on diagnosis + complementary tools (Python recovery + bash hooks + 6-question diagnostic) at this point. Useful triad for the next operator who lands here.

Hey, thanks for the breakdown — the truncation case is really useful for the toolkit.

diagnose.py currently surfaces "JSONL present vs JSONL missing" but doesn't check message counts against the metadata's completedTurns field. A truncated transcript looks identical to an intact one from the outside, which means the current report can give a clean bill of health to a file that's missing half its messages. I'll add an explicit check for that — the symptom would otherwise show up as "session opens but looks shorter than expected," which isn't a case I've handled. Great catch.

The layer distinction is accurate — session-index-repair.sh and synth_session_metadata.py converge on the same operation but at different surfaces: the CLI session index and the Desktop local_*.json files respectively. For macOS Desktop users, both layers are in play. Worth noting in the docs so users know which tool addresses which surface.

On the proactive side — the toolkit has backup_claude_state.py which snapshots both directories on demand (same intent as your session-backup-on-start.sh, different invocation model). There's also a worktrees/ suite — backfill_recovery_stubs.py, worktree_shrink.py, worktree_inspector.ps1 — that handles the worktree lifecycle specifically: preventing orphaned sessions when worktrees are removed and recovering sessions from deleted branches. That's territory your hooks don't cover, so the two toolsets end up genuinely complementary rather than just overlapping at the bash/Python layer.

Happy for the cc-safe-setup integration — wrapping synth_session_metadata.py as an installable example once macOS paths are natively detected makes sense. I'll open an issue on the recovery side to track the macOS path work, and we can thread the wrapper from there. Full write-up at #56172.

I also experienced somethnig like this with Claude Code launched via the MacOS Claude Desktop App.
My bug report describes the problem and links to a simple, safe, and effective fix-it script.

• #63082
• https://github.com/John-D-B/Claudes/tree/main/2026-05-27.Claude-Amnesia

I have also lost all of my work. This will take a LOT of tokens and time to get things back to working state. This is insane. May be time to move to another solution that doesn't auto-delete all your your work and time :(

@SkeevaVR : I also keep experiencing this behavior, but the fixit scripts described here do fix the problem.

Reproduced on Windows, Claude Code desktop v1.11187.1. ~19 of 49 sessions lost ("Session not found on disk" on desktop / disconnected on mobile). Notable pattern: 11 of the 19 lost sessions had been bridged to remote/cloud sessions, vs only ~5 of the ~30 survivors — so the loss correlates with bridged sessions, not age (sessions from ~10 weeks ago survive while ones from the day before are gone). Persists after updating to the latest version and fully restarting. Local metadata flags the lost ones with transcriptUnavailable: true while keeping the title/folder, so they appear as ghost entries in the sidebar.

Hey DSP2012,

The transcriptUnavailable: true flag is the key data point. When I've hit this pattern, the Desktop's startup scanner has run and removed cliSessionId from those metadata entries — the title stays (that's why they appear in the session list) but the pointer to the transcript file is cleared.

The "Session not found on disk" message is what Desktop shows when it has a metadata entry but no valid cliSessionId to follow — so it doesn't necessarily mean the .jsonl transcript files have been deleted from disk.

First thing worth checking: open ~/.claude/projects/ (on Windows: %USERPROFILE%\.claude\projects\) and see whether .jsonl files exist for the affected sessions. If they're there, I built a toolkit (claude-code-session-recovery) that handles exactly this state — diagnose.py maps each session's state across both the metadata directory and the transcript directory, and repair_session_metadata.py backfills the cliSessionId links and removes the transcriptUnavailable flag for sessions where the transcript is present on disk.

The bridged-session correlation is an interesting pattern. My guess is that bridged sessions either write transcripts to a different location or don't create a local .jsonl at all — the transcript lives server-side rather than in ~/.claude/projects/. When the startup scanner can't find a local file to match, it flags transcriptUnavailable. That would mean those 11 bridged sessions are a different failure class from the sessions that may still be on disk. Running diagnose.py will tell you which of the 19 have local transcript files before you do anything irreversible.

BasedGPT/claude-code-session-recovery

Adding ours to the pile. Same silent loss, but with a twist that made it worse for us.

We had a session that actually did something with side effects: it ran a curl that hit a third-party email API and sent a real customer a billing email. We know it happened because the email provider's dashboard shows the request (curl/8.20.0 user-agent, timestamped about an hour before we went looking). So the action definitely ran from a Claude Code session.

The session itself? Gone. I grepped every .jsonl under ~/.claude/projects, then the whole home directory. Nothing. I checked ~/.claude/history.jsonl too, which is supposed to keep your prompts even after a transcript gets deleted, and there's just a gap with nothing from that day. No .json.tmp index leftover, no backups (we hadn't set any up).

So this isn't the "hidden from the UI but still on disk" case some people are hitting. A direct disk grep finds zero. The transcript is actually gone.

What bugs me most isn't losing chat history, it's that a session touched a billing/email system and left no local record of what it did or why. We had to reconstruct it from the email provider's logs. For anything involving money or customers, that's not okay.

We've since added a SessionStart hook that backs up the jsonl files (the cc-safe-setup one mentioned upthread), but that only helps from here on. Everything already lost stays lost. Please stop deleting transcripts silently, and give us some kind of export or recovery path.

@al3rez — the side-effect angle is the part of this bug that should worry people most, and it's genuinely different from the "recover the lost transcript" cases the rest of us have been chasing here. Losing chat history is annoying; losing the only local record that a session hit a billing API is a different category of problem.
It's worth being explicit about why the transcript-backup SessionStart hook you added won't fully close this case: it snapshots whatever transcripts exist when a new session starts. A session that runs, fires the curl, and has its transcript deleted before the next SessionStart leaves nothing to back up — which matches exactly what you saw (direct disk grep finds zero, history.jsonl has a gap).
What does survive is an independent, append-only audit written at the moment each command runs, to a path outside ~/.claude/projects (the directory the cleanup actually prunes). A tiny PreToolUse hook on Bash does it:

INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // empty'); [ -z "$CMD" ] && exit 0
SID=$(echo "$INPUT" | jq -r '.session_id // "unknown"')
CWD=$(echo "$INPUT" | jq -r '.cwd // "unknown"')
LOG="$HOME/.claude-command-audit.log"   # NOT under ~/.claude/projects
jq -nc --arg ts "$(date -u +%FT%TZ)" --arg sid "$SID" --arg cwd "$CWD" --arg cmd "$CMD" \
  '{ts:$ts,session:$sid,cwd:$cwd,cmd:$cmd}' >> "$LOG"
exit 0   # audit only, never blocks a tool call

Register it:

{ "hooks": { "PreToolUse": [ { "matcher": "Bash",
  "hooks": [ { "type": "command", "command": "~/.claude/hooks/command-audit.sh" } ] } ] } }

I ran it against a payload identical in shape to your case (a curl -X POST https://…/send to an email API) and it appends one line:

{"ts":"2026-06-15T14:22:47Z","session":"abc-123","cwd":"/home/u/proj","cmd":"curl -X POST https://api.email.example/send -d to=customer@x.com"}

So next time a session touches money/customers and then vanishes, you reconstruct it from your own machine instead of the provider's dashboard.
Two honest limitations: (1) it records the command, not its output or exit status — enough to answer "what did it do," not "what did the server return"; and (2) it only covers Bash (where curl/network side effects live), not Edit/Write. If you want the result too, a PostToolUse variant can also append tool_response, at the cost of a noisier log.
Agreed on the core ask, though — none of this should be necessary. A session silently deleting its own only record of a side-effecting action is the part that needs fixing upstream; the hook is just a seatbelt until then.

I have also stumbled into this issue. I left a project I was working with on Claude Code for a month or two, came back, noticed that --resume didn't see the session, searched, looked in ~/.claude/ — nothing. The transcript and any evidence of it (outside Claude Code statistics) is just... gone.

This wouldn't be so bad if there was a way to configure _how long to wait until pruning old sessions_, because sessions even a year or so old can become important at critical points in time.