Desktop app (Windows/MSIX) intermittently fails to start after self-inflicted race condition on native-host install; recovery wipes local session index

Summary

Claude Desktop (Windows, MSIX package) intermittently fails to start with "This app can't be opened / There's a problem with Claude. Reinstall the app..." after a normal, non-forced restart (PC never lost power, never crashed at the OS level). The only visible recovery path (uninstall -> reinstall) wipes the local session index used by the sidebar, making it look like all Claude Code chat history was deleted, even though it wasn't. This has now happened at least twice to the same user.

Environment

• App version: 1.24012.1 (MSIX package Claude_1.24012.1.0_x64__pzs8sxrjxfjjc)
• OS: Windows 10 Pro, build 10.0.19045, x64
• Install type: MSIX from WindowsApps (windowsStore=true)
• No third-party antivirus installed - only Microsoft Defender (confirmed via SecurityCenter2 / Get-MpComputerStatus), Real-Time Protection + Tamper Protection both enabled

Root cause (evidence-based, from %APPDATA%\Roaming\Claude\logs\main.log)

On the startup that led to the failure, the entire initialization sequence ran twice back-to-back within the same wall-clock second, timestamps identical down to the second, for essentially every log line from growthbook load through Chrome Extension MCP setup, including two independent invocations of the native-host install routine:

2026-07-22 19:29:52 [error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile
  'C:\Program Files\WindowsApps\Claude_1.24012.1.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe'
  -> 'C:\Users\<user>\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'

This EBUSY strongly suggests two internal code paths in the same process attempting to write the same destination file concurrently, without a mutex/idempotency guard - i.e., a self-inflicted race condition, not external interference. We specifically ruled out:

• Antivirus interference: Get-MpThreatDetection returned zero detections ever for this file; Microsoft-Windows-Windows Defender/Operational log had zero events in the exact failure window (19:29:00-19:30:30).
• Tampering/compromise: Get-AuthenticodeSignature on Claude.exe returns Valid, signed by "Anthropic, PBC". All running claude.exe/chrome-native-host.exe processes resolve to the legitimate signed install path or the CLI binary the app itself downloaded from downloads.claude.ai.

We also found a related AppX Deployment Server event from a previous install attempt:

Event ID 503: "Package filesystem entries for Claude_pzs8sxrjxfjjc could not be cleaned up after reboot.
The package was removed from the pending list."

suggesting incomplete cleanup from a prior uninstall/update can leave stale staging state that compounds the problem on the next install/repair.

Secondary issue: "Repair" (Windows Settings -> Apps -> Advanced options -> Repair) hangs indefinitely

Repair invokes the AppX TerminateApplications step, which appears to only know about processes launched as part of the MSIX package tree. Two processes that are NOT part of that tree kept running independently and were never targeted for termination:

• chrome-native-host.exe (spawned separately, not a child of the packaged Claude.exe)
• The standalone Claude Code CLI at C:\Users\<user>\AppData\Roaming\Claude\claude-code\<version>\claude.exe (downloaded by the app itself post-install, runs outside the package)

If either holds an open handle on a file the repair operation needs, Repair appears to hang with no progress and no error, forcing users toward the destructive uninstall/reinstall path instead.

Data-loss illusion (not actual data loss)

Real Claude Code conversation transcripts live in ~/.claude/projects/<project-folder>/<sessionId>.jsonl and are untouched by uninstall/reinstall, confirmed intact across two separate incidents. What gets wiped by a clean reinstall is %APPDATA%\Roaming\Claude\claude-code-sessions\<accountId>\<orgId>\*.json, a separate, thin index (one JSON file per chat: sessionId, cliSessionId, cwd, timestamps, title, etc.) that LocalSessionManager uses to populate the sidebar. Because this index has no relationship persisted back to the authoritative .jsonl files it's supposed to reflect, users reasonably conclude their chat history was permanently deleted, when it's fully recoverable by hand (we did this manually by reconstructing index JSON files from data embedded in the .jsonl transcripts).

Also worth noting: LocalSessionManager only loads claude-code-sessions/ at startup — it does not appear to watch that directory for changes while running, so even a manual fix requires a full app restart (not just closing the window; the tray-icon "Exit" is required since background processes persist otherwise) to take effect.

Suggested fixes

1. Add a mutex/single-flight guard around the native-host install/copy routine so it can't run twice concurrently within one process launch.
2. Have Repair's termination step enumerate and terminate all processes under the package's install path and its known spawned children (native host, bundled CLI), not just the primary packaged executable.
3. Investigate the AppX cleanup-after-reboot failure (event 503), stale staging entries from a previous install/uninstall should not be allowed to persist into the next deployment operation.
4. Consider making claude-code-sessions/ index reconstructable automatically from ~/.claude/projects/*.jsonl on startup if the index is empty/missing, since the authoritative data already exists on disk. This would make the "chats disappeared" symptom self-healing without user intervention.