Windows: reinstall after failed update wipes app session index while transcripts survive, no rebuild path

What happened

The in-app updater on Windows hung during download, then failed with a "file in use" error dialog. After that the app would not start at all (same error on every launch), so I had to reinstall from the website. After the reinstall my entire session list in the app was empty.

Here is the part that makes this worse than it needs to be: the actual session transcripts were never lost. All 82 of my .jsonl transcripts going back a month are still sitting in %USERPROFILE%\.claude\projects\, untouched. What the reinstall wiped is only the app's session index in %APPDATA%\Claude\claude-code-sessions\. The app treats the missing index as "no sessions exist" and offers no way to rebuild it from the transcripts it can plainly read.

Steps to reproduce

1. Windows desktop app, click the in-app update when offered.
2. Updater hangs, then errors with a file-in-use dialog. Something still holds a lock on the install dir. I do not have the Chrome extension or a standalone CLI installed, this is a desktop-app-only setup, so the lock has to come from the app's own processes (tray process, bundled runtime) or the updater itself, not from third party integrations.
3. App is now broken, every launch shows the same error.
4. Reinstall from the website.
5. Session list in the app is empty, although %USERPROFILE%\.claude\projects\ still contains every transcript.

Expected

Either of these:

• The reinstall does not clear %APPDATA%\Claude\claude-code-sessions\. This is user data, not cache. Windows convention for Roaming is data that survives reinstalls.
• Or, on startup with an empty index, the app notices the transcripts in ~\.claude\projects\ and offers to rebuild the session list. The index entries are small JSON files with a cliSessionId pointing at a transcript, so a rescan that recreates minimal entries (cwd, timestamps, title from the transcript summary, permissions reset to safe defaults) looks very doable. I verified this manually: hand-writing an index entry pointing at an old transcript works.

Even just a message saying "your transcripts are still on disk" would have saved me from believing a month of sessions was gone.

Workaround for others hitting this

• Your transcripts survive in %USERPROFILE%\.claude\projects\. The bundled CLI at %APPDATA%\Claude\claude-code\<version>\claude.exe can resume them with --resume from the project directory.
• Before any reinstall, back up %APPDATA%\Claude\claude-code-sessions\ and restore it afterwards to keep the session list.

Prior reports

This has been reported before but never triaged, because each report was auto-closed as a duplicate: #62997 was closed as a dup of #58608, which was closed as a dup of #41591, which is a macOS issue closed as not planned after going stale. The closing bot says to file a new issue and reference them, so that is what this is.

To be clear about the difference: those reports describe the auto-update itself deleting session data. That is not what happened here. The auto-update did not wipe anything, it just left the installation broken. The wipe happened during the reinstall, which is the recovery step everyone is pushed toward when the update fails. And in my case the transcripts survived, so this is specifically about the index being treated as disposable app data and the missing rebuild path, not transcript deletion.

The updater file-lock failure that triggers the whole chain is also previously reported in #51954 and #45896 (both closed).

Environment

• Windows 11 Pro 10.0.26200
• Desktop app 1.25927.0 (Squirrel install under %LOCALAPPDATA%\AnthropicClaude)
• Bundled Claude Code runtime 2.1.221
• Minimal setup: desktop app only, no Chrome extension, no standalone CLI install