Desktop app: previously working sessions show "Session not found on disk" despite transcripts existing; "Import CLI sessions" reports nothing to import

Environment:

• OS: Windows 11 Pro 10.0.26200
• Claude desktop app version: 2.1.258 (leftover 2.1.255 folder also present under %APPDATA%\Claude\claude-code, suggesting an incomplete/partial update)

Description:

After an app update, all previously working sessions in a project directory (Downloads) became inaccessible. Clicking into any old session shows:

Session not found on disk Send a message to start fresh in this directory.

with options to Import CLI sessions / Archive / Delete.

Clicking Import CLI sessions returns:

No CLI sessions to import All importable Claude Code sessions on this computer, whether started in the Code tab or the terminal, are already in your session list, were previously deleted, or are in folders you haven't trusted in Claude yet.

This appears to be an app-side index/cache bug, not data loss — the underlying session transcript files are present and intact on disk under ~/.claude/projects/C--Users-<user>-Downloads/, e.g.:

• 763da05f-80c5-4d91-acb9-34dfb58c57e5.jsonl (~395 KB, last modified 2026-09-03)
• aa9dabbe-3475-4fd2-91d7-f2ca40be25a3.jsonl (~1.2 MB, last modified 2026-09-03)
• (plus 3 more .jsonl files in the same directory, all readable and non-empty)

So the app's session list "knows" these sessions exist (hence "already in your session list" in the import dialog) but cannot resolve them to their files.

Steps to reproduce:

1. Have existing Claude Code sessions in a project directory.
2. Update the desktop app (in this case, to 2.1.258).
3. Open the Code tab and click into a previously existing session.

Expected: Session loads normally from its .jsonl transcript.

Actual: "Session not found on disk" error; re-import does not fix it.

Tried already:

• Fully quit the app (via system tray Quit and via Task Manager End Task on all Claude processes) and relaunched — issue persists.
• Confirmed transcript files exist and are non-empty via direct filesystem inspection.

Additional question: Does this only affect sessions orphaned during/before the update, or could the same index desync recur for newly created sessions after a future update?