[BUG] Claude Desktop MSIX self-deregisters mid-session on Windows 10, leaving a working shortcut that errors with 'There's a problem with Claude'

Environment

• OS: Windows 10 (x64), build 10.0.19045
• Product: Claude Desktop (MSIX), Claude Code running inside the app
• Version after recovery: 1.26832.0.0 (Claude_1.26832.0.0_x64__pzs8sxrjxfjjc)
• CoworkVMService: not installed on this machine (sc.exe returned 1060 for both stop and delete)

What happened

I was in an active Claude Code session in the desktop app — Claude Code was mid-task, actively running a command/agent work — when the app quit unexpectedly and disappeared. No crash dialog, no error at the time, and no update prompt or auto-update activity had appeared beforehand.

On relaunch, Windows showed:

There's a problem with Claude. Reinstall the application from its original install location or contact your administrator.

What I found

This is not the CoworkVMService lock variant described in #49655 / #66635. On this machine, at the time of the failure:

• Get-AppxPackage -Name "Claude*" returned nothing — the package had already fully deregistered itself
• $env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc did not exist — no leftover AppData, no locked hives
• reg query HKU | Select-String Claude returned nothing — no mounted hives
• CoworkVMService had never been installed, so nothing was holding locks

So the package deregistered cleanly, but the Start menu entry survived and kept pointing at a package family name that no longer resolves. The user-facing result is a generic Windows error that gives no indication the app package is simply gone.

For context, this machine has needed the app reinstalled many times before this incident, so package-registration fragility appears to be recurring here rather than a one-off. For this recovery I went straight to the manual sideload below rather than the GUI installer.

Recovery

A manual MSIX sideload fixed it with no reboot required (no reboot was needed because nothing was locked):

curl.exe -L -o "C:\ClaudeTemp\Claude.msix" "https://claude.ai/api/desktop/win32/x64/msix/latest/redirect"
Unblock-File -Path "C:\ClaudeTemp\Claude.msix"
Add-AppxPackage -Path "C:\ClaudeTemp\Claude.msix" -ForceApplicationShutdown -ForceUpdateFromAnyVersion

Result: Status: Ok, IsPartiallyStaged: False. Verified after recovery: the package is registered under C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc with Status: Ok.

Expected behavior

1. The app should not deregister its own package mid-session.
2. If the package is missing at launch, the shortcut should surface something actionable ("Claude's app package is missing — reinstall from claude.com/download") rather than the generic Windows administrator error, which sends users toward uninstall/reinstall loops that fail with 0x80073CF6.
3. The installer should detect an orphaned shortcut with no registered package and self-repair.

Side note

After recovery, my Claude Code session list in the app was empty even though the transcripts were fully intact under ~/.claude/projects/ — 938 .jsonl files, including 351 top-level session transcripts across three project folders (177 + 173 + 1). The session-management API inside the app also reports zero other sessions, so the app has lost track of all of them while the data sits on disk. That matches #81907 — a "rescan sessions" action would have saved me from assuming the work was lost.