[BUG] Windows: Claude Code Desktop app shows sessions in sidebar but all message content missing after auto-update — content not persisted to claude-code-sessions JSONL files

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/38691
2. https://github.com/anthropics/claude-code/issues/51412
3. https://github.com/anthropics/claude-code/issues/53417

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

my issue is different as my chat history really got wiped out and i have no idea how it was all wiped out

Adding a related diagnostic distinction from #56172 that may help triage/recovery here.

When Desktop shows session titles/sidebar entries but the pane is empty or says there are no messages, there are at least two materially different cases:

metadata local_*.json exists, cliSessionId missing → potentially recoverable by backfilling cliSessionId from the matching ~/.claude/projects/*.jsonl
metadata local_*.json has cliSessionId, but the referenced JSONL is missing or only a tiny stub → likely true transcript loss

For this report, the 1KB stubs suggest it may be the second bucket rather than the recoverable cliSessionId case, but checking the cliSessionId field in %APPDATA%\Claude\claude-code-sessions\<acct>\<org>\local_*.json is a quick way to avoid conflating the two.

Before touching any metadata files: fully quit Claude Desktop, including the tray process. Desktop holds metadata in memory and flushes back to disk — changes made while it's running get silently overwritten. Verify with tasklist /FI "IMAGENAME eq claude.exe" before proceeding.

---

Fix: cliSessionId-missing case

Step 1 — Diagnose

import glob, json, os
META = os.path.expandvars(r'%APPDATA%\Claude\claude-code-sessions\<account-uuid>\<org-uuid>')

broken = []
for f in glob.glob(os.path.join(META, 'local_*.json')):
    with open(f, 'r', encoding='utf-8') as fh:
        d = json.load(fh)
    if not d.get('cliSessionId'):
        broken.append((os.path.basename(f), d.get('title', '<no title>')))

print(f'{len(broken)} metadata files missing cliSessionId:')
for name, title in broken:
    print(f'  {name}  |  {title}')

Step 2 — Repair

Match each broken metadata file to its JSONL by timestamp (first-record timestamp within ±30s of metadata createdAt — deterministic in practice), then backfill cliSessionId. Run without --apply first to review matches.

import argparse, glob, json, os, shutil
from datetime import datetime, timezone

META = os.path.expandvars(r'%APPDATA%\Claude\claude-code-sessions\<account-uuid>\<org-uuid>')
PROJECTS = os.path.expanduser(r'~\.claude\projects')
SLUG_PREFIX = '<your-project-slug>'  # e.g. C--Users-You-Projects-MyApp
BACKUP_DIR = './repair-backup'
WINDOW_MS = 30_000


def index_jsonls():
    out = {}
    for entry in os.listdir(PROJECTS):
        if not entry.startswith(SLUG_PREFIX):
            continue
        slug_dir = os.path.join(PROJECTS, entry)
        for f in glob.glob(os.path.join(slug_dir, '*.jsonl')):
            sid = os.path.splitext(os.path.basename(f))[0]
            if len(sid) != 36:
                continue
            try:
                with open(f, 'r', encoding='utf-8') as fh:
                    first = json.loads(fh.readline())
                ts = first.get('timestamp')
                if ts:
                    dt = datetime.fromisoformat(ts.replace('Z', '+00:00'))
                    out[sid] = int(dt.timestamp() * 1000)
            except (OSError, json.JSONDecodeError, ValueError):
                continue
    return out


def find_match(created_at, jsonls):
    best = None
    for cli, jsonl_ts in jsonls.items():
        delta = abs(jsonl_ts - created_at)
        if delta < WINDOW_MS and (best is None or delta < best[1]):
            best = (cli, delta)
    return best


def main():
    parser = argparse.ArgumentParser()
    parser.add_argument('--apply', action='store_true')
    args = parser.parse_args()

    os.makedirs(BACKUP_DIR, exist_ok=True)
    jsonls = index_jsonls()
    repaired = 0

    for f in glob.glob(os.path.join(META, 'local_*.json')):
        with open(f, 'r', encoding='utf-8') as fh:
            d = json.load(fh)
        if d.get('cliSessionId'):
            continue
        match = find_match(d.get('createdAt', 0), jsonls)
        if not match:
            print(f'NO MATCH: {os.path.basename(f)}')
            continue
        cli, delta = match
        print(f'MATCH ({delta}ms): {os.path.basename(f)} -> {cli}')
        if args.apply:
            shutil.copy2(f, os.path.join(BACKUP_DIR, os.path.basename(f)))
            d['cliSessionId'] = cli
            with open(f, 'w', encoding='utf-8') as fh:
                json.dump(d, fh, indent=2)
            repaired += 1

    print(f'\n{"Repaired" if args.apply else "Would repair"} {repaired} files.')


if __name__ == '__main__':
    main()

After running with --apply, relaunch Desktop — repaired sessions should render correctly.

This won't help the second bucket (stub JSONL / genuine data loss). But if the JSONL content is on disk and only the pointer is missing, this fixes it.

This happened to me ... Sidebar projects all still exists in Claude Code Desktop but ALL content form chats completely wiped.

Affected on Windows 11, Claude Code v2.1.128 (desktop).
Lost session history for 10+ active projects after auto-update.
Months of accumulated context across parallel builds — gone.
Max subscriber. No warning, no migration prompt, no recovery path.

Sessions show in sidebar with correct titles but "No messages yet"
when opened. New empty .jsonl files created on first interaction,
old history nowhere on disk.

This is unacceptable for a paid product. Requesting:

1. Server-side recovery if any session telemetry was retained
2. Immediate rollback option to pre-2.1.128 storage format
3. Refund/credit for affected billing period

I'm seeing a very similar data-loss issue on macOS, with a slightly different failure mode that may help diagnose the root cause.

Environment

• macOS Sequoia
• Claude Code Desktop (current v1.8089.1; exact version during affected period unknown)

Observed behavior

20 early local Desktop sessions (2026-03-31 to 2026-04-16) are visible in the sidebar with correct titles, dates, and project paths. Opening them shows: "Session not found on disk".

These were not empty sessions: the Desktop metadata records non-zero completedTurns values, ranging from 2 to 185 across the affected sessions. The transcripts are missing, but the metadata clearly indicates these sessions had real completed conversation turns.

All sessions created after 2026-04-17 are intact. The affected sessions are all older than 30 days.

Metadata analysis

The session metadata JSON files under ~/Library/Application Support/Claude/claude-code-sessions/ are intact. The critical difference between broken and working sessions:

Broken session (one of 20):

{
  "sessionId": "local_2d5a8f6d-a893-4852-9550-5f296b2f1cfd",
  "title": "Session A (co-reading workflow)",
  "completedTurns": 7,
  "transcriptUnavailable": true
  // cliSessionId field is ABSENT
}

Working session:

{
  "sessionId": "local_a4650311-c925-4d0f-a31c-ccf94fd7c49f",
  "cliSessionId": "f6fc6bad-2d9a-41bc-a45e-7eaaf74d782b",
  "title": "Session B (co-reading workflow)",
  "completedTurns": 18,
  "transcriptUnavailable": false
}

For the working session, {cliSessionId}.jsonl exists at ~/.claude/projects/<project>/f6fc6bad-....jsonl.

For the broken sessions, cliSessionId is absent and transcriptUnavailable is true. The user recalls being able to read some of these sessions previously, suggesting the JSONL transcripts may have originally existed but were deleted by Claude Code's default 30-day transcript cleanup (cleanupPeriodDays). It appears that when cleanup deletes a JSONL, Desktop also removes the cliSessionId field from the session metadata and sets transcriptUnavailable: true — leaving a visible but unrecoverable session card.

Statistics

| Category | Count |
|---|---|
| Sessions with no cliSessionId + transcriptUnavailable: true | 20 |
| Sessions with cliSessionId but JSONL file deleted | 3 |
| Working sessions (JSONL intact) | 112 |
| Total affected | 23 |

All 20 no-cliSessionId sessions fall within the date range 03/31–04/16 — all older than 30 days. From 04/17 onward, all sessions are intact (none have exceeded 30 days yet or cleanupPeriodDays has since been set to a high value).

Audit script

import json, os, glob
base = os.path.expanduser("~/Library/Application Support/Claude/claude-code-sessions")
existing = {os.path.basename(f).replace('.jsonl','') 
            for f in glob.glob(os.path.expanduser("~/.claude/projects/**/*.jsonl"), recursive=True)}
for f in glob.glob(f"{base}/**/*.json", recursive=True):
    try:
        data = json.load(open(f))
        cli_id = data.get('cliSessionId','')
        title = data.get('title','')
        turns = data.get('completedTurns','')
        if not cli_id and title:
            print(f"NO cliSessionId: {title} (turns={turns})")
        elif cli_id and cli_id not in existing:
            print(f"JSONL missing: {title} -> {cli_id}")
    except: pass

Likely root cause: 30-day cleanup + Desktop metadata desync

Claude Code's default cleanupPeriodDays (30 days) deletes old JSONL transcript files from ~/.claude/projects/. However, Desktop's session metadata in ~/Library/Application Support/Claude/claude-code-sessions/ is not cleaned up in sync. This creates zombie session cards: visible in the sidebar with title, date, and turn count, but no backing transcript.

Worse, it appears Desktop reacts to the missing JSONL by removing cliSessionId from the metadata and setting transcriptUnavailable: true — erasing the link to the deleted file and making it impossible to determine what was lost.

Relation to this issue

This is the same class of bug: Desktop session metadata outlives the transcript backing store. The difference is:

• #53717: Windows, JSONL files exist but are empty 1KB shells, messages show "No messages yet"
• This report: macOS, JSONL files were deleted by 30-day cleanup, cliSessionId cleared from metadata, sessions show "Session not found on disk"

Both point to a gap between Desktop's session UI and the underlying transcript lifecycle.

Warning: "Send a message to start fresh" silently masks the bug

Sending a message in a broken session does not recover the old conversation. Instead, Desktop binds a new cliSessionId to the same session card, creating a fresh transcript that overwrites the broken state:

Before sending a message:

{
  "sessionId": "local_c44f4db2-c60b-492b-84fc-246bd7093a86",
  "title": "Session C (article discussion)",
  "completedTurns": 4,
  "transcriptUnavailable": true
  // cliSessionId: ABSENT
}

After sending "hi":

{
  "sessionId": "local_c44f4db2-c60b-492b-84fc-246bd7093a86",
  "title": "Session C (article discussion)",
  "cliSessionId": "995a48fd-2281-44d4-9cba-3bc9bb0604ed",
  "completedTurns": 4
  // transcriptUnavailable: field REMOVED entirely
}

The new JSONL (995a48fd-....jsonl) contains only 9 lines — just the new "hi" and its response. The original 4-turn conversation from April 12 is permanently lost.

This is dangerous because:

1. Users who see "Send a message to start fresh" may assume they're resuming their old session
2. After sending, the session card looks "fixed" — transcriptUnavailable is gone, a valid cliSessionId exists
3. The original broken state can no longer be diagnosed
4. completedTurns still shows the old count (4), which is misleading since the new transcript only has 1 turn

Users affected by this bug should avoid sending messages in broken sessions, as it permanently destroys the diagnostic evidence.

Impact

These include the user's first-ever sessions — initial project setup, research workflows, and early tool configuration. This content cannot be recreated. No backup mechanism exists for session transcripts.

@1nwooozip — your macOS case is the one I built for: cleanup deleted the JSONLs, so they have to come back from a snapshot before the metadata pointer can be repaired. Two scripts that do that on macOS:

garrettmoss/restore-claude-history

restore_claude_code.py pulls the deleted JSONLs back from Time Machine / APFS snapshots; restore_claude_desktop.py then backfills cliSessionId and drops transcriptUnavailable. Hinges entirely on whether a snapshot from before the 30-day cleanup still has the file — mine reached back to early March and caught most of them.

One amplification of your warning, since it matters for recovery: don't send a message in a broken session — it rebinds cliSessionId, so a later restore points the metadata at the wrong transcript. Leave them untouched until you've restored from a snapshot.

(Also filed #62272 on the cleanup behavior itself.)

Same symptom on Linux CLI (not just Windows/Desktop) — v2.1.177

Reproducing the core of this issue — session metadata persists but the message body never reaches the JSONL — on the Linux CLI (no Desktop app, no Electron/IndexedDB involved), which suggests the root cause is in the session-persistence/flush path itself, not the Desktop renderer cache.

Environment

• Claude Code: 2.1.177 (CLI), native install via nvm (node v22.21.1)
• OS: Ubuntu 24.04, gnome-terminal (a VS Code window was open on a file in the same project, but the affected sessions ran in standalone terminals)
• The affected long-running session was resumed repeatedly across 2.1.168 → 2.1.177 (the version field in its events shows both 2.1.168 and 2.1.177)

Symptom 1 — title-only "stub" session files

Two sessions produced JSONL files containing only an ai-title line and zero message events:

{"type":"ai-title","aiTitle":"<title>","sessionId":"b70c4aac-…"}

{"type":"ai-title","aiTitle":"<title>","sessionId":"fbfc4385-…"}

That's it — one line, ~130 bytes, no user/assistant/system events at all. The session clearly ran (it got an AI-generated title), but the conversation body was never written.

Symptom 2 — truncated tail on a resumed session

A separate long session (db6953e4-…, version 2.1.177):

• Last persisted event: 14:08
• Not held open by any live process at investigation time (verified by scanning /proc/*/fd — it was a closed session, not mid-flush)

But that session demonstrably kept working until ~14:37, proven by on-disk artifacts it created after its last JSONL event:

| Time | Artifact |
|-------|----------------------------------------------|
| 14:31 | new output directory created |
| 14:33 | __pycache__ (a Python script was executed) |
| 14:35 | a ~11 KB script + two output files written |
| 14:37 | a memory .md file edited |

None of these ~30 minutes of activity exist in the JSONL — no Write/Edit tool_use, none of the files' unique strings, no tool results. The trailing turns were lost on session exit.

Why this matters / why it was hard to detect

• --resume and all transcript-search tooling correctly find nothing — the content was never written, so there's nothing to index or recover.
• The only reason I could prove the work happened is the filesystem side-effects (the script + outputs the session produced). A read-only conversation would have vanished without a trace.

Possible contributing factor: /cd

The session wrote files under one project path while editing a memory file under a different project's path — consistent with a /cd having occurred (/cd was introduced in 2.1.169). This overlaps with #22566 ("assistant responses stop persisting to JSONL after cd"). Flagging in case the flush target (project dir) goes stale after a working-directory change.

Relevant changelog history

• 2.1.170: "Fixed sessions not saving transcripts (and not appearing in --resume) when launched from the VS Code integrated terminal" — same bug class; the fix implies it was live in 2.1.168/169, where this session began.
• 2.1.177: "Fixed background-session respawn rejecting malformed resume IDs from corrupted state files" — session-state corruption still being patched in current.

Ask

Please confirm whether the persistence/flush path has an exit//cd window where message events are buffered but not flushed (producing title-only stubs and truncated tails), independent of the Desktop/Electron layer. A periodic flush, or a flush-on-exit/flush-on-/cd guarantee, would prevent silent data loss like this.

Same issue on:
OS: Windows 11
Claude Desktop app v1.12603.1, released June 11, 2026

Updated to this version and all chats older than April 25 (~10:00pm EST is the oldest last-message chat - all prior give this error) are missing transcripts.

Is this expected functionality? Is this recoverable? Lots of valuable context is now missing and there doesn't seem to be a toggle or notice to prevent this arbitrary deletion with no backup.

Same issue here. I can't even reboot my machine now so i wont loss all my chat history.
Claude itself says that the json's are there, but the desktop UI wont show/use them.

How is this not being addressed?!??

@jgabriel98 The desktop version of Claude doesn't automatically scan for matching JSONL files in the working directory. Instead, it uses a database that registers all previous sessions. Therefore, restored JSONL files do not appear in the app because they aren't indexed in the Claude desktop app's database.

@garrettmoss Have you found any way to reindex the metadata?

Same core failure — session content not persisted to the JSONL — reproduces on a very different platform and trigger, which suggests the root cause isn't specific to Windows / the Desktop app / auto-update, but lives in the core session-persistence layer.

My environment: Claude Code 2.1.197, Linux x86_64, CLI (not Desktop), model claude-opus-4-8. No auto-update involved — just a long session resumed with --resume across three calendar days.

What I saw

During one span, the assistant did real, verifiable work — an Artifact tool render (which produced a still-accessible artifact) plus several Write/Edit calls to project files. After a later resume, the model had no record of any of it and denied it happened. The work was only recoverable from on-disk side effects.

Concrete evidence: file-history and the transcript disagree within the same session

• ~/.claude/file-history/<session-id>/ retained the file writes from that span (snapshots dated on the missing day — a rendered HTML doc and a package.json edit).
• The session transcript ~/.claude/projects/<slug>/<session-id>.jsonl has no Artifact/Write/Edit tool_use and no assistant text for that span. The only transcript references to that work appear days later, when the user re-pasted an artifact URL and it was re-fetched.

So the file-write path persisted while the conversation turns (assistant text + tool_use) did not. This is not a display/index issue (cf. #22030, stale sessions-index.json where data is present but not loaded) — here the turns are genuinely absent from the .jsonl, so the reasoning/decisions from them are unrecoverable; only file outputs survive.

Likely related and apparently regressed

This matches two issues that are now closed and locked as resolved, but the behavior is back on 2.1.197:

• #21751 — "Assistant text messages not written to transcript … on /resume, messages before the break become unreachable"
• #26208 — "User text messages in continuation sessions are not persisted to the JSONL transcript file"

Given those are CLI/cross-platform and this Desktop/Windows report is the only open thread on JSONL non-persistence, it'd be worth treating this as a platform-independent session-persistence defect rather than a Windows-Desktop-only one.

Repro (CLI)

1. Start a CLI session; do work including tool calls that write files / render an artifact.
2. Resume across multiple days, continuing work.
3. Compare file-history/<session-id>/ against the session .jsonl: file snapshots exist for a span with no corresponding assistant text/tool_use entries in the transcript.

Happy to share the parsing script that cross-checks file-history against the .jsonl.

---

Update — found the write gap, and a likely trigger (worktree / cwd drift)

Digging further on disk turned up a concrete signature and a plausible mechanism. The two persistence stores are keyed differently:

• file-history/<session-id>/ is keyed by session id (independent of cwd).
• The transcript lives under projects/<project-slug>/<session-id>.jsonl, where the slug is derived from the project / launch cwd.

On the affected day there is a ~2.5-hour window where file-history recorded file writes but the transcript has ZERO entries:

• file-history captured file writes (an HTML document + a package.json edit) at ~T.
• The transcript's first entry of that day is ~2.5h later — nothing was written to the .jsonl during the window, even though the session was demonstrably active (it wrote files).
• Those turns are not relocated to any other project slug or session — they simply don't exist in any transcript on disk.

The correlating condition: during that silent window the session's working cwd had drifted into git worktrees created under the project (and other sibling repo dirs), i.e. away from the original launch-cwd project root, while the session's project association stayed pinned to the launch dir. The session-keyed store (file-history) kept writing; the project-keyed store (transcript) went silent. That asymmetry is exactly why file outputs survived while the conversation turns were lost.

Hypothesis: when the working cwd moves into a git worktree / away from the launch project root, the project-keyed transcript write path can silently stop persisting turns (while session-keyed file-history is unaffected).

Reproducible signature to look for: entries in file-history/<session-id>/ whose mtimes have no corresponding turns in projects/<slug>/<session-id>.jsonl for the same window — especially after git worktree add + working inside the worktree.

I can't prove causation from disk alone (the drift is strongly correlated with the gap, not provably its cause), but the keying asymmetry + the empty transcript window + the worktree cwd drift line up cleanly. Environment unchanged from above (CLI, Linux, 2.1.197, claude-opus-4-8).

@mon-jai yes, this is what my tool is for. https://github.com/BasedGPT/claude-code-session-recovery

@BasedGPT It does not work for me unfortunately :(

{
  "diagnosis_id": "73974c09",
  "tested_against": {
    "claude_desktop": "1.17377.2",
    "claude_code_cli": "2.1.197",
    "windows": "11"
  },
  "schema_probe": "unrecognised",
  "install_type": "exe",
  "msix_real_path": null,
  "desktop_running": false,
  "matched_problems": [
    {
      "id": "orphan-jsonl-no-metadata",
      "domain": "session",
      "mutator": "tools/sessions/synth_session_metadata.py",
      "next_command": "python tools/sessions/synth_session_metadata.py --diagnosis-id 73974c09",
      "safety_preconditions": [
        "Quit Claude Desktop fully before any mutation. Diagnose is read-only and safe to run anytime."
      ]
    }
  ],
  "audit_only_problems": [],
  "schema_mismatch": true,
  "snapshot": {
    "total_metadata_count": 0,
    "metadata_with_cli_count": 0,
    "metadata_missing_cli_count": 0,
    "metadata_dangling_cli_count": 0,
    "metadata_duplicate_cli_count": 0,
    "cwd_junction_mismatch_count": 0,
    "jsonl_orphan_count": 84,
    "cwd_slug_mismatch_count": 0,
    "truncated_jsonl_count": 0,
    "cwd_prefix_types": {
      "junction": 0,
      "canonical": 0,
      "bare_root": 0,
      "other": 0
    },
    "jsonl_count": 84,
    "schema_version": "unrecognised",
    "desktop_version": "1.17377.2",
    "cli_version": "2.1.197",
    "desktop_running": false,
    "running_inside_desktop": false,
    "install_type": "exe",
    "msix_real_path": null,
    "mapped_drive_unc_mismatch_count": 0,
    "mapped_drive_affected_drives": []
  }
}

---

Edit: Never mind, it works now.