[BUG] Windows MSIX: clicking an external link in the chat transcript crashes the app (GPU exit 0x060C201E) and forces an MSIX repair cycle - expected: open in default browser

Clarification from further use on the affected machine: other external links in the chat transcript have always opened normally in the default browser — only ietf.org links have ever triggered this crash (both incidents, the two URL patterns in the report: mailman3.ietf.org/mailman3/lists/... and mailarchive.ietf.org/arch/browse/...).

So this does not look like all link clicks being routed through the in-app preview machinery; the common path presumably is shell.openExternal and works. Something specific to these URLs (or their content) causes the preview context creation seen in the log seven seconds before the GPU death — e.g. a link-preview/unfurl behavior for certain URLs, or whatever loads in that hidden preview probing Vulkan/WebGL/WebRTC and hitting the CIG kill from #81341.

That narrows the repro: it is deterministic 2/2 on those ietf.org URLs and 0/N on everything else clicked on this machine.

Correction and root-cause refinement after more information from the affected machine, superseding part of my previous comment:

Corrected behavior model: transcript link clicks open in the in-app Claude browser by design (not shell.openExternal — my earlier assumption was wrong). Other sites render fine in that in-app browser. Only these ietf.org URLs crash it, 2/2. Explicitly asking for the link to be opened in the OS default browser works fine, including for these URLs.

Why these URLs specifically — they are Cloudflare bot-challenge pages:

• https://mailman3.ietf.org/mailman3/lists/ responds to a non-browser client with HTTP 403 + Cf-Mitigated: challenge and a CSP referencing https://challenges.cloudflare.com (Turnstile interstitial).
• https://mailarchive.ietf.org/arch/browse/... serves content but injects Cloudflare's invisible challenge-platform detection script (/cdn-cgi/challenge-platform/scripts/jsd/main.js) into a hidden iframe. Both hosts report Server: cloudflare.

Cloudflare's challenge/JSD scripts perform WebGL/canvas fingerprinting. That is precisely the probe that causes Chromium's GPU process to load vk_swiftshader.dll, which CIG (MicrosoftSignedOnly) rejects fatally under MSIX packaging — the verified mechanism in #81341, and consistent with #80978's "GPU/viz process crashes on WebGL/Cloudflare pages". The user's regular browser presumably passes or survives the same challenge because the signing-level rejection is only escalated to process death inside an MSIX package.

Refined chain: click link → in-app browser loads a Cloudflare-challenged page → challenge script probes WebGL → GPU process loads vk_swiftshader.dll → CIG kill (0x060C201E) → app dies → MSIX repair (initially failing 0x80073D02 while the packaged service holds files, #84992).

Testable prediction: any page serving a Cloudflare challenge/interstitial to the in-app browser should reproduce this on an MSIX install — the ietf.org URLs above are just a deterministic public instance. (Not re-tested on the affected machine; each occurrence costs a repair cycle.)

Confirming this on the current build, with one data point that may help narrow the mechanism: CIG is not enabled on this machine, yet the crash still occurs.

Environment

• Claude Desktop 1.30096.5.0 (MSIX), Windows 11 Home 10.0.26200
• GPU: Intel HD Graphics 620, driver 31.0.101.2140 (2025-11-04)
• Get-ProcessMitigation -System → Cig.MicrosoftSignedOnly = NOTSET
• Get-ProcessMitigation -Name claude.exe → no per-app entry
• vk_swiftshader.dll is present in the package (5.4 MB)

Trigger

Clicked an ordinary external https:// link (a Cloudflare dashboard URL) that the assistant had produced in the chat transcript. Expected it to open in the default browser.

Result

~9 seconds later, from logs/main.log:

2026-08-17 12:00:09 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
2026-08-17 12:00:09 [warn] [Preview] capturePreviewScreenshotIfChanged failed: {
  error: [Error: UnknownVizError]

A second, identical crash (same exit code) occurred 17 minutes later. Recovery required an MSIX Repair from Windows Settings plus a reboot.

Two details that may aid triage

1. No crash artifact is produced anywhere. Crashpad/ contains only settings.dat — zero dumps. No WER report and no entry in %LOCALAPPDATA%\CrashDumps either. Anyone diagnosing this locally will find nothing in the usual places, which makes it look like a clean exit rather than a crash.

2. The reboot requirement appears to come from the VM service, not the GPU crash. C:\ProgramData\Claude\Logs\cowork-service.log logs this on every single start:

Warning: failed to configure recovery actions (a crashed service will stay down
until reboot): open service: Access is denied.

So CoworkVMService cannot register its own SCM recovery actions, and once it goes down it stays down until the machine reboots. That would explain why this consistently presents as "needs a reboot and a Repair" rather than "relaunch the app".

Preceding instability

53 GPU-dependent screenshot failed entries appear in main.log over the ~24 hours before the first hard crash, alongside 4 UnknownVizError entries — the GPU process was degrading before it died outright.

Follow-up to my previous comment — I dug into why CoworkVMService cannot configure its own recovery actions, and it turns out the reboot requirement is not repairable by the user at all.

The service ships with this DACL:

> sc.exe sdshow CoworkVMService

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)
  (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)

Only two ACEs:

| Trustee | Rights | Has DC (SERVICE_CHANGE_CONFIG)? |
|---|---|---|
| AU (Authenticated Users) | CC LC SW RP WP DT LO CR RC | No |
| S-1-5-80-… (the service's own SID) | CC DC LC SW RP WP DT LO CR SD RC WD WO | Yes |

Two consequences:

1. There is no BA (Builtin Administrators) ACE, so an elevated admin gets only the AU rights. Running the obvious fix from an Administrator shell fails exactly the same way an unelevated one does:

> sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/restart/10000/restart/30000
[SC] OpenService FAILED 5:  Access is denied.

2. AU lacks DC, which is the specific right required to set failure actions — so the service's own startup attempt fails with the same error it logs on every single launch:

Warning: failed to configure recovery actions (a crashed service will stay down
until reboot): open service: Access is denied.

Net effect: when the GPU crash brings the service down, nothing can restart it — not the service, not the user, not an administrator — so a reboot becomes the only recovery path. That is what turns this bug from "relaunch the app" into "reboot, then run an MSIX Repair."

A user could take ownership and rewrite the descriptor with sc sdset, but that means modifying a vendor-installed service's security descriptor, which risks the same MSIX integrity checks that already force the Repair cycle. I would not suggest anyone do that.

Suggested fix: either grant DC to BA in the service DACL, or configure the failure actions at install time (while the installer still holds the necessary rights) rather than from the service's own startup path. Either would let the service auto-restart after a GPU crash and remove the reboot + Repair step entirely — a worthwhile mitigation even while the underlying GPU crash remains open.

Third data point from the same machine, and I think it identifies the mechanism behind a symptom that gets reported separately from this crash: "Remote Control disconnected" on sessions that were created locally.

It is caused by deferred MSIX registration, not by anything in the user's Remote Control configuration.

What happened

The app auto-updated 1.30096.5.0 → 1.32352.0.0. From Microsoft-Windows-AppXDeploymentServer/Operational:

16:20:23  607   Deployment Add operation on package Claude_1.32352.0.0_x64__… de-queued
16:20:23  574   Preferred package version for package family is changing
16:20:36  638   Packages were not updated because affected apps are still running.
                Running apps: {Claude_…}
16:20:36  658   Marking package {Claude_1.32352.0.0_x64__…} for deferred registration

Windows could not register the new package because the app was running, so it deferred it. The deferred registration then applied on the next app start, replacing the binary underneath sessions already bound to the previous local host. Every running session detached with:

Remote Control disconnected Claude Code on the computer that runs this session is no longer connected. Turn Remote Control back on there and this session will reconnect.

The message is misleading in a way that sends users down the wrong path. It reads as a Remote Control fault, so people go looking at Remote Control settings — but the sessions were created locally on that same machine, and nothing about Remote Control is misconfigured.

Why it is not a configuration problem

Verified on the affected machine while the symptom was present:

| Check | Result |
|---|---|
| ANTHROPIC_BASE_URL, DISABLE_REMOTE_CONTROL, API keys, Bedrock/Vertex | all unset (user + machine) |
| settings.json / settings.local.json | no remote keys; no local override file |
| disableRemoteControl | not present anywhere |
| get_session on the affected session | isRemote: false — correctly local |
| Session record on disk | no remote-control state stored at all |
| ~/.claude.json | only UI-history flags (hasUsedRemoteControl, remoteDialogSeen, remoteControlSurfacesSeen) |

A user chasing this through configuration will find nothing, because there is nothing there. The only reliable recovery is to archive the detached session and create a new one, which binds to the new host.

Relationship to the crash in this issue

Same root family. The 0x80073D02 — Unable to install because the following apps need to be closed failures reported here and in #84992 are the same collision between the updater and the running app; deferred registration is what Windows does instead when it declines to fail outright. So one update event can produce either a Repair cycle or a fleet of detached sessions, depending on timing.

Suggested fixes, roughly in order of value

1. Correct the message. When a session detaches because the local host was replaced by an update, say so — "Claude Desktop updated and this session's host was replaced; start a new session." The current wording sends people to Remote Control settings for a problem that has nothing to do with Remote Control.
2. Detect a pending deferred registration and warn before applying it, ideally offering "restart now" at a moment the user chooses rather than silently on next launch.
3. Re-bind or cleanly migrate surviving sessions across an in-place update, or fail them with a specific, actionable error.

Workaround for anyone hitting this

There is no supported way to disable the update (SignatureKind: Developer, so Store update policy does not apply). What does work is removing the surprise — check whether an update is staged before starting long work, and if so close the app fully and reopen so registration applies cleanly:

Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' -MaxEvents 400 |
  Where-Object { $_.Message -match 'Claude_\d' -and
                 $_.Message -match 'deferred registration|affected apps are still running' } |
  Select-Object -First 3 TimeCreated, Id

If that returns a recent entry, or if a staged version is higher than (Get-AppxPackage -Name Claude).Version, an update is waiting and will detach sessions on the next start.