Windows: in-app Browser pane deterministically crashes shared GPU process (exitCode 101457950, persists with HW accel off) + MSIX repair deadlock (0x80073D02/9641)

Two interacting defects in Claude Desktop for Windows (MSIX / Claude Code Desktop), reproduced across 1.37937.x and 1.40609.0. Evidence below is from main.log and the Microsoft-Windows-AppXDeploymentServer/Operational event log on the affected machine (Windows 11 Home 10.0.26200, Core Ultra 9 285K, RTX 5080, 64 GB RAM). All timestamps 2026, local ET.

Defect 1 — Opening the in-app Browser/preview pane crashes the shared GPU process (deterministic)

• main.log shows GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 } within 1–3 seconds of [Preview] Created browser preview — 9 occurrences since 08-04, same exit code every time (08-04 12:26:18, 12:35:32; 08-09 23:12:36; 08-17 11:14:46, 11:18:41, 11:31:07; 08-23 23:53:03; 08-31 22:45:05, 22:55:06; plus more on 08-26).
• Reproduces with hardware acceleration disabled: with isHardwareAccelerationDisabled: true loaded and the GPU process running --use-gl=angle --use-angle=d3d11-warp-webgl (WARP software rendering), the crash still occurred (08-31 22:55:06, 2 s after pane open). So this is not a GPU-driver fault — it looks like a deterministic assertion in the pane/GPU path.
• Triggers on both localhost dev-server previews and plain public HTTPS pages (e.g. a WordPress site). Often (not always) preceded ~1 s by [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }.
• One GPU process serves every window, so a single pane crash tears down all open sessions (16–19 claude.exe at the time).
• The built-in [gpu-recovery] never engages: it requires 3+ GPU deaths in one app session, but each crash causes a package re-register/teardown (Defect 2) that resets the counter.

Defect 2 — MSIX repair path can never succeed while the app runs ("Can't open this app — select Repair" loop)

• The package ships the auto-start LocalSystem packaged service CoworkVMService (depends on staterepository, binary inside the versioned package folder).
• Windows RepairPackageOperation (also what Settings → Advanced options → Repair invokes) uses RepairAppRegistrationOption, which does not force-close the app. With the app running it always fails: event 9641 0x80004004 Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude + 404/419/401 0x80073D02 "apps need to be closed". Each failed repair flags the package damaged → launching a window then shows "Can't open this app — select Repair", and the suggested Repair runs the same failing path, so the dialog's own advice can never work.
• The repair's Add step can also fail 0x80070020 (sharing violation on app\resources\cowork-svc.exe) because the running service holds its own binary inside the package folder.
• Every app update resets the service to AUTO_START from the manifest, re-arming the deadlock. Updates staged while the app runs produce event 658 deferred registrations, and event 1230 reports 8 orphaned old-version hardlink folders (1.13576.4.0 … 1.34493.0.0) left in WindowsApps.
• Example full chains: 08-31 21:14:45–21:14:57 and 22:55:25–22:55:50 (RepairPackageOperation → Add 0x0 → Register 0x80073D02 + 9641).

Interaction

Defect 1 causes teardowns/re-registers that both reset the GPU-crash auto-recovery counter and keep re-flagging the package for the repair that Defect 2 guarantees will fail. Net effect: the app "randomly crashes" several times a day (all windows at once) and periodically refuses to open.

Suggested fixes

1. Fix (or isolate/restart) the Browser-pane GPU crash — the constant exit code should make the assertion easy to locate; ideally one preview should not be able to kill the shared GPU process for every window.
2. Make the packaged service demand-start, or stop it before self-repair; ensure the repair path force-closes the app (or defers the register to next launch) instead of failing 0x80073D02.
3. Persist the GPU-death counter across app restarts so gpu-recovery can engage.

---
Filed with Claude Code on behalf of the account owner, from local log analysis on the affected machine. Happy to provide full log excerpts or run diagnostics on request.