Desktop app loses session history after sessions are closed

[lucasvicente-com-ar]

Description

The Claude Code desktop app (Windows) does not persist session history in the sidebar after sessions are closed. Only currently active sessions appear in the UI.

Steps to reproduce

1. Open Claude Code desktop app on Windows
2. Create several sessions across different project directories
3. Close the sessions normally
4. Reopen the app — only the most recent/active sessions appear in the sidebar

Expected behavior

All previous sessions should remain visible in the session list/sidebar, similar to how they were displayed before.

Actual behavior

Only currently running sessions are listed. Historical sessions disappear from the UI once closed.

Root cause investigation

• Session transcripts (.jsonl files) are intact in ~/.claude/projects/ — no data loss.
• The ~/.claude/sessions/ directory only contains JSON files for currently active sessions (PID-based files). When a session ends, its index file is cleaned up.
• The desktop app does not re-scan ~/.claude/projects/ to rebuild the session list from existing transcripts.
• claude --resume from the CLI correctly finds and lists all sessions for a given project directory by reading the transcript files directly.

Environment

• Platform: Windows 11 Pro (10.0.26200)
• Claude Code version: 2.1.170
• Entrypoint: claude-desktop

Workaround

Users can resume old sessions via the CLI:

cd "path/to/project"
claude --resume

This reads the .jsonl transcripts directly and lists all available sessions for that project.

🤖 Generated with Claude Code

[github-actions]

Found 3 possible duplicate issues:

1. Desktop 3p Code sessions disappear from UI after restart while JSONL transcripts remain on disk #59736
2. Desktop Recents list doesn't surface sessions previously created via the CLI #62515
3. [FEATURE] Desktop Recents to enumerate ~/.claude/projects/ directly. #54911

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

[BasedGPT]

Ran into this same symptom diagnosing the Desktop session list. When transcripts are intact but sessions vanish from the sidebar, it almost always comes down to the metadata layer.

The Desktop sidebar and ~/.claude/sessions/ are two separate layers. ~/.claude/sessions/ holds ephemeral PID-based files for active sessions (those clean up on close by design). The persistent session list is driven by %APPDATA%\Claude\claude-code-sessions\: one local_<uuid>.json metadata file per session, each with a cliSessionId field pointing at the corresponding .jsonl.

Worth checking that directory: %APPDATA%\Claude\claude-code-sessions\<your-account>\<org>\. If it's empty or has far fewer entries than the sessions you're missing, that's the gap: transcript files on disk with no metadata to render them in the sidebar.

If that's the pattern, I built a toolkit for exactly this — synth_session_metadata.py in claude-code-session-recovery walks ~/.claude/projects/, finds .jsonl files with no corresponding metadata entry, and synthesises the local_*.json files. After a Desktop restart, those sessions should surface in the list.

Running diagnose.py first gives you the full picture: it maps both directories and identifies which sessions are in which state before writing anything.

BasedGPT/claude-code-session-recovery

If it helps, a ⭐ on BasedGPT/claude-code-session-recovery is always appreciated.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[Genmain]

@BasedGPT's diagnosis matches what I arrived at independently — the sidebar is driven by local_<uuid>.json metadata files linked to transcripts via cliSessionId, and synthesising the missing ones does restore the sessions. I regenerated 5 orphaned entries this way and all of them came back in the sidebar and resumed with full context.

One addition that matters for Windows, since it breaks the diagnosis as written: on MSIX (Store/packaged) installs, %APPDATA%\Claude does not exist at all.

Windows redirects packaged apps' roaming data, so the real location is:

%LOCALAPPDATA%\Packages\Claude_<publisher-hash>\LocalCache\Roaming\Claude\claude-code-sessions\<accountId>\<orgId>\

On my machine (Claude_1.24012.9.0_x64__pzs8sxrjxfjjc) checking %APPDATA%\Claude\claude-code-sessions returns a plain "path does not exist" error. Any tooling that probes only the unpackaged path will report nothing found on these installs, which reads as "no metadata layer" rather than "looked in the wrong place". Worth resolving the directory via (Get-AppxPackage *Claude*).PackageFamilyName instead of hardcoding %APPDATA%.

Two other things that cost me time:

• The app must be fully exited while writing metadata, otherwise it rewrites the directory from its in-memory state on close.
• Files must be UTF-8 without BOM. PowerShell's Set-Content adds one and the app then skips every session silently, with no error and no log entry.

For the underlying fix: since resume works fine once metadata exists, the missing piece is only the index. Scanning ~/.claude/projects/ on startup for transcripts with no matching cliSessionId and backfilling entries would close this out without touching the resume path.

Script, if useful to anyone: https://gist.github.com/Genmain/26a2d9019b9063839c9fac823c76a3a8

Auto-detects the store for both packaged and unpackaged installs, -DryRun
first, backs up before writing, skips sessions that already have metadata.