Desktop app's "Resume a session" dialog finds zero sessions after migrating project folders to a new path (CLI --resume finds them fine)

Environment

• Claude Desktop app, Windows, installed as an MSIX/Store package (package family name Claude_pzs8sxrjxfjjc)
• Bundled Claude Code version: 2.1.260 (also present: 2.1.258)
• OS: Windows 11 Pro
• Native CLI install (~/.local/bin/claude.exe) was missing/broken (claude doctor flagged it); repaired via claude install. Bug persists after repair + full app restart.

What happened
I migrated ~11 Claude Code projects to a new machine. The project root's drive letter ended up changing (from what would have been D:\Claude Code to C:\Claude Code). I correctly renamed the matching session-history folders under ~/.claude/projects/ to match the new hashed path (e.g. C--Claude-Code-CyB-Avicola), and confirmed the .jsonl transcripts inside are valid, uncorrupted, and match the exact session IDs from before the move.

In the desktop app's Code tab, opening any of these folders shows only sessions created after the migration (via the app itself). The "Reanudar una sesión" / Resume a session dialog (triggered by /resume or its icon), with "Todas las carpetas" / All folders selected and the Estado / Status filter set to "Todo" / All, reports:

"No se encontraron sesiones de Claude Code en esta computadora." (No Claude Code sessions were found on this computer.)

...even for a folder that has a valid, non-empty, correctly-placed transcript file.

What I expected
The dialog should list all valid sessions found under ~/.claude/projects/<matching-hashed-folder> for the current folder (or all folders, in "All folders" mode).

Isolating the bug
To rule out data corruption, I ran a byte-level validation of every .jsonl line in all 23 session files across the 11 migrated projects (including a 144 MB one) — 100% valid JSON, no corruption.

To rule out a CLI-level resume problem, I repaired the native standalone install (claude install, since it was missing) and ran the native, non-packaged claude.exe --resume directly from inside one of the same project folders (outside the packaged app entirely). It found the historical session immediately, with the correct title, size, and age, and successfully resumed it with full content.

So: the underlying data and the core resume/session-discovery logic both work correctly. The bug appears isolated to the packaged desktop app's own session-listing feature (both the per-folder sidebar list and the "Resume a session" dialog) — it seems to not be looking in the same place the CLI resolves for ~/.claude/projects. My guess (unconfirmed) is that this may be related to how MSIX/Store packaging redirects %APPDATA%\Claude for the packaged process vs. how the renderer resolves paths for its own session index — but I don't have visibility into the app's internals to confirm.

Repro steps

1. Have a project with existing Claude Code session history under ~/.claude/projects/<hashed-path>/.
2. Move the project folder to a different path such that the drive letter or a higher-level path segment changes.
3. Rename the corresponding ~/.claude/projects/<old-hashed-path> folder to the new hash matching the new path (so the folder-name-to-path mapping is correct).
4. Open the (new-path) folder in the Claude Desktop app's Code tab.
5. Trigger "Resume a session" → "All folders".
6. Result: no sessions found, despite valid transcripts on disk for that exact path.

Workaround found
Running the native claude.exe --resume (or -c) directly from a terminal in the project folder works correctly and finds/resumes the migrated sessions.