[BUG] Claude Desktop main-thread blocking during CLI auto-update causes Application Hang + Cowork VM session loss + MSIX corruption
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Claude Desktop periodically downloads and installs updates to its bundled Claude Code CLI tool (claude-code\<version>\claude.exe) as a background task. This download-and-unpack operation runs on the main UI thread instead of a worker thread. When it runs, the main thread blocks for multiple seconds at a time, which either: (1) causes Windows to detect the process as unresponsive and forcibly close it ("Application Hang"), or (2) causes the app itself to trigger beforeQuit and shut down shortly after the blocking episode.
If a Cowork VM session is active at the time, the resulting main-thread block causes the persistent RPC connection between the app and CoworkVMService to drop (EOF). This connection loss subsequently corrupts the app's MSIX package state (Modified, NeedsRemediation), producing the system dialog "This app can't open — Reinstall the app from its original installation location" on next launch.
Root cause confirmed via Sentry breadcrumbs / app logs: at 20:23:32 the app began a background download of its CLI tool update ([download:1] Resuming: 10485680/71120125 bytes already on disk), 71 MB downloaded then unpacked to 307 MB and installed to claude-code\2.1.229\claude.exe. The overlap of the CLI unpack step with the app's own auto-updater check appears to compound the main-thread block into a long enough freeze that either Windows or the app itself terminates the process.
Confirmed via Windows Event Log: three identical "Application Hang" events for claude.exe, same fault signature (6a550db4) in all three occurrences, across two different physical machines and across an app version bump — confirming this is one reproducible bug, not random crashes.
What Should Happen?
The CLI update download/unpack step (and ideally the app's own update-check step) should run off the main UI thread, on a worker thread or background process, so that multi-second I/O and decompression operations cannot block the UI event loop. As a result: the app should remain responsive during background updates, should not be killed by Windows as an "Application Hang", should not self-quit, should not lose the Cowork VM RPC connection, and should never place the MSIX package into a "Modified, NeedsRemediation" state requiring reinstall.
Error Messages/Logs
Main-thread freeze events recorded during the update window:
| Time | Freeze duration | Concurrent activity |
|---|---|---|
| 20:23:36 | 1716 ms | download of 71 MB had just completed |
| 20:23:42 | 544 ms | unpacking |
| 20:23:43 | 799 ms | unpacking |
| 20:23:47 | 2376 ms | unpacking |
| 20:23:57 | 3559 ms | immediately after install completed, the app's own separate updater also kicked off ("Checking for updates"), compounding the block |
| 20:24:01 | — | app initiated shutdown (beforeQuit ... going down) |
Windows Event Log — three identical Application Hang events for claude.exe, same fault signature 6a550db4 in all three:
- 2026-08-14 09:07:50 (v1.30096.0.0)
- 2026-08-15 17:23:15 (v1.30096.5.0, after a clean reinstall — recurred regardless)
- 2026-08-15 18:55:55 (v1.30096.5.0)
cowork-service.log shows the persistent RPC connection between claude.exe and CoworkVMService ending with "failed to read length: EOF" at the same time as the main-thread freeze/app termination.
`Get-AppxPackage Claude` subsequently reports "Modified, NeedsRemediation", and the app can no longer be launched without a full uninstall/reinstall.Steps to Reproduce
Step 1: Install Claude Desktop (MSIX, Windows 11) and start an active Cowork VM session, leaving the app running in the background.
Step 2: Wait for the background Claude Code CLI updater to begin downloading/unpacking an update (visible in logs as [download:1] Resuming: ...).
Step 3: If this overlaps with the app's own auto-update check ("Checking for updates"), the main thread blocks for multiple seconds (observed 544 ms-3559 ms per freeze in this report).
Step 4: Observe one of two outcomes: Windows shows an "Application Hang" dialog and kills claude.exe, or the app self-terminates (beforeQuit).
Step 5: Check Windows Event Viewer for an Application Hang event for claude.exe with fault signature 6a550db4.
Step 6: If a Cowork VM session was active, check cowork-service.log for an RPC disconnect ("failed to read length: EOF") at the same timestamp.
Step 7: Run Get-AppxPackage Claude and observe the package status is now "Modified, NeedsRemediation"; the app can no longer be launched without uninstall/reinstall.
Reproduced 3/3 times, identical fault signature, across two different physical machines and across an app version bump (1.30096.0.0 to 1.30096.5.0 - auto-update did not resolve it).
Full technical writeup attached below:
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude Desktop 1.30096.5.0 (also reproduced on 1.30096.0.0); bundled CLI updated to claude-code 2.1.229
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Downstream effects observed: active Cowork sessions were lost mid-task, reproduced during an active FTP-based plugin management session (Apex Hosting Minecraft server) and during an active local dev session (Tauri/Node.js project). In both cases, resuming the session after reinstall was possible via claude-code-sessions backup restore and/or claude --resume (session history itself was not corrupted, only the app package/UI state).
Secondary, likely unrelated finding: a separate, high-frequency log pattern was also observed, repeated "Blocked permission check" entries for background-sync originating from https://newassets.hcaptcha.com/ on https://claude.ai/login (52 occurrences within a few seconds around app startup, approximately 19:01:49 to 19:01:51). This does not correlate in time with the main-thread freeze events and does not appear to be the cause of the hangs; noting it here in case it is a separate, minor issue worth cleaning up (log spam without apparent throttling/backoff).
Ruled out during diagnosis: malware (checked via Get-MpThreatDetection, only an old already-remediated detection unrelated to this issue); disk health (Get-PhysicalDisk reported Healthy on all disks involved); missing admin rights (reproduced even with the app installed and run with full administrator privileges); hardware virtualization firmware setting (VirtualizationFirmwareEnabled was False on both test machines, but the Sentry-log findings above provide a direct, reproducible mechanism that fully explains the observed Application Hang events independent of virtualization state, and the same fault signature occurred across both machines regardless of VT-x status).
Suggested fix for Anthropic: move the CLI tool download-and-unpack step (and ideally the app's own update-check step) off the main UI thread and onto a worker thread or background process, so multi-second I/O and decompression operations cannot block the UI event loop. Additionally: avoid corrupting the MSIX package state when the Cowork VM RPC connection drops unexpectedly (this looks like a separate edge case in error handling), and add a debounce/backoff to the CLI updater so it doesn't overlap with the app's own auto-update check.
Note: this was already filed via /bug in Claude Code with a full session transcript attached, and flagged separately to Anthropic support/Product Support for routing. Happy to share the full technical writeup (attached above) if useful.