claude-code - 💡(How to fix) Fix [BUG] Session visible in UI but "Session not found on disk" — JSONL file exists but has mismatched internal session ID

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?

I had a session called "GC v2 Figma Screens" that appeared in my Claude Code session list and showed "Session not found on disk" when clicked. It has since disappeared from the list altogether after attempts to repair it.

What happened: I moved C:\Users\Mark\.claude to Dropbox, deleted the original, and created a junction so C:\Users\Mark\.claude points to the Dropbox folder. During this process, Dropbox sync had pre-existing Mac session data in that folder. The result was that several JSONL session files ended up with mismatched content — the filename UUID does not match the sessionId field in the first line of the file.

Specifically: The session "GC v2 Figma Screens" had a session cache entry at: %APPDATA%\Claude\claude-code-sessions\...\local_282095ab-bd18-4eb8-9628-22c5926f8923.json

That cache entry originally had cliSessionId: "282095ab-bd18-4eb8-9628-22c5926f8923" but the file 282095ab-bd18-4eb8-9628-22c5926f8923.jsonl actually contains sessionId: "92415a95-4272-4a42-bee3-153bef9166c2" internally — a different session's data was written into that file by Dropbox sync.

When I removed the transcriptUnavailable: true flag from the cache JSON, Claude restarted, detected the mismatch, cleared the cliSessionId field, re-set transcriptUnavailable: true, and hid the session from the list entirely.

What I have tried:

• Restoring the cliSessionId field manually and pointing it at a valid JSONL file (29ee4e3a) whose internal sessionId matches its filename — Claude Code still rejects it
• Creating new session cache JSON files for valid JSONL files that have no cache entry — Claude Code ignores externally created cache files entirely
• Restoring from VSS shadow copies — shadow copies followed the junction to Dropbox and captured current (corrupted) state, not historical
• Dropbox version history — the JSONL files show "Added today" with only one version, meaning they were never in Dropbox prior to tonight

Questions:

1. Is there an official way to register an existing JSONL file as a session in the Claude desktop app on Windows?
2. Is there a format requirement or validation check on session cache files that prevents externally created ones from being loaded?
3. Does the app maintain a secondary index or database (e.g. LevelDB, SQLite) beyond the claude-code-sessions JSON files that controls which sessions appear in the sidebar?
4. Is there any recovery path for a session whose cache entry exists but whose cliSessionId has been cleared by the app?

The underlying JSONL files with the actual session content are intact and valid — the problem is purely that the app will not associate them with the session list entries. Any guidance on the internal session resolution mechanism would be enormously helpful.

Account: WebGuy / Mark Mumma / [email protected]

What Should Happen?

Valid JSONL session files with matching internal session IDs should be loadable by the app, and externally created session cache entries should either be accepted or there should be a supported mechanism to register existing JSONL files as sessions in the sidebar.

Error Messages/Logs

Session cache entry shows transcriptUnavailable: true with cliSessionId cleared by the app after it detected a mismatch between the cache's expected session ID and the internal sessionId field in the JSONL file. No error surfaced to the user — the session silently disappeared from the sidebar.

Steps to Reproduce

1. On Windows 11, move C:\Users{user}.claude to a Dropbox folder that already contains Claude session data synced from another machine (Mac)
2. Delete the original C:\Users{user}.claude folder
3. Create a junction: mklink /j C:\Users{user}.claude D:\Dropbox\path\to.claude
4. Dropbox sync overwrites some JSONL session files with content from other sessions — the file's UUID filename no longer matches the sessionId field in the first line of the file
5. Claude for Desktop shows the affected session in the sidebar with "Session not found on disk"
6. Remove transcriptUnavailable: true from the session's cache entry in %APPDATA%\Claude\claude-code-sessions...\local_{uuid}.json
7. Restart Claude for Desktop
8. Claude detects the filename/internal sessionId mismatch, clears cliSessionId, re-sets transcriptUnavailable: true, and removes the session from the sidebar entirely
9. Session is now completely gone from the UI with no way to recover it through the app

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.156

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Extensive debugging was performed before filing this report. Key findings:

• The claude-code-sessions cache directory contains local_{uuid}.json files that control which sessions appear in the sidebar. Claude Code appears to validate these files and ignores any that were not created by its own process — externally created cache files with correct format and valid cliSessionId values are silently ignored on startup.
• Pointing an existing cache entry's cliSessionId at a different valid JSONL file (one whose internal sessionId matches its filename) is also rejected — Claude Code clears the cliSessionId and re-sets transcriptUnavailable: true on next launch.
• The JSONL files themselves are intact, valid, and accessible via the junction. The issue is entirely in the session resolution/registration layer.
• The app scanned "51/51 transcript files" on startup (confirmed in %APPDATA%\Claude\logs\main.log) but did not surface any JSONL files that lacked a corresponding cache entry — suggesting the sidebar is driven entirely by the cache, not by scanning JSONL files directly.
• All three VSS shadow copies on the system were taken after the junction was already in place, so they reflect current Dropbox state rather than the original local Windows session data.
• Dropbox version history showed the affected JSONL files as "Added today" with no prior versions — the original session data was never synced to Dropbox.
• The core feature request implicit in this bug report: provide a way to import or re-register an existing JSONL transcript file as a session, either via a UI option or a supported CLI/config mechanism.