[BUG] GPU process crash (exitCode 101457950) kills Claude Desktop and corrupts MSIX package when Opus 5 performs an in-page browser action (Windows 11)

Same here.
Though my claude code doesn't restore, only reinstall fixes..

Same here. Told Claude to not use the browser until the next update then we can test again.

Confirming this on my end too — same exact signature, different hardware (Intel integrated graphics, no discrete GPU), so this isn't limited to hybrid Intel Arc/NVIDIA setups.

Environment: Windows 11 Pro, build 10.0.22631. Claude Desktop 1.24012.9 (MSIX). Intel integrated graphics.

Log evidence — crash directly follows Browser pane creation (not just correlated, same few seconds):

2026-07-27 09:43:15 [Preview] Created browser preview { serverId: 'browser-preview-...' }
2026-07-27 09:43:20 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Regression detail that might help narrow it down: I updated my Intel Graphics driver after first hitting this (from 32.0.101.8132 to 32.0.101.8860), which appeared to fully fix it — verified the Browser pane working with no crash on 2026-07-24, on app version 1.24012.1. The exact same crash (same exitCode) then recurred on 2026-07-27 after Claude Desktop auto-updated to 1.24012.9, same driver, same OS, no other changes. So in my case it tracks the app version, not the driver — which lines up with the root-cause analysis in #81275 ruling out drivers entirely (reproduced across Intel Arc/NVIDIA/software rendering). Worth cross-referencing that thread.

Workaround in the meantime: avoiding the embedded Browser pane entirely and using curl/WebFetch for anything that needs real web content.

Confirming this on different hardware, with what may be the missing piece: every crash is preceded by a WebGL capability-probe burst about 1 second earlier, and those warnings land in unknown-window.log, not main.log. Anyone looking only at main.log will see the crash with no apparent cause.

Environment

• Claude Desktop 1.24012.9.0 (MSIX)
• Claude Code 2.1.219
• Windows 11 Home, build 26200
• Opus 5
• GPU: NVIDIA RTX 4070 SUPER (driver 32.0.16.1047), plus an AMD Ryzen iGPU that drives no display
• Exit code 101457950 / 0x060C201E

3/3 reproductions, identical signature

| WebGL probe burst | GPU process gone | WebGL warnings in that second |
|---|---|---|
| 04:21:07 | 04:21:08 | 22 |
| 14:00:35 | 14:00:36 | 23 |
| 15:21:04 | 15:21:05 | 21 |

The sequence in unknown-window.log is always:

[warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat
[warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_float is not enabled
[warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_[half_]float is not enabled
[warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127

immediately followed in main.log by:

GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

unknown-window.log accumulated 6,476 of these WebGL warnings over roughly 23 hours. This matches the log sequence reported in #80444.

Trigger

Automated research runs that load external pages in the in-app browser. It appears content-dependent rather than action-dependent — one of the three crashes had no new preview tab opened at all, only in-page activity on an already-open tab, which is why "opening a browser tab" alone does not reliably reproduce it. Pages that are themselves WebGL-heavy reproduce it fastest.

Ruled out with evidence

• Not an OS/driver fault. No TDR events, no LiveKernelReports, no WER entry for the app. The graphics driver never faults at the OS level.
• Not GPU-adapter selection. Pinning the app to the discrete NVIDIA GPU via HKCU\Software\Microsoft\DirectX\UserGpuPreferences (GpuPreference=2, keyed to the MSIX package identity) did not help — it crashed again after a full reboot with the pin active.
• Not memory pressure. 14.6 GB physical RAM free at crash time.
• MSIX corruption is downstream, not causal — consistent with the cowork-svc.exe file-lock finding in #80444.
• Reported here on an RTX 4070 SUPER; #80444 reports an RTX 2080 and #61372 a GTX 1650, so this does not look vendor- or tier-specific.

Workaround that resolves it

This issue currently lists hardware acceleration as untested. Setting:

"isHardwareAccelerationDisabled": true

in %APPDATA%\Claude\claude_desktop_config.json stops the crashes entirely — no recurrence since applying it. The trade-off is software rendering, so 3D/animation-heavy previews get noticeably slower.

This is equivalent in effect to the --disable-gpu launch workaround in #80444, but persists across launches instead of needing a special invocation. Worth noting for anyone hitting this who does not want to re-launch via Invoke-CommandInDesktopPackage each time.

isHardwareAccelerationDisabled: true does not prevent this crash (2/2 reproductions, AMD)

Adding the workaround from this comment did not help here. Reporting it because the comment states it "stops the crashes entirely", and because this is — as far as I can tell — the first AMD data point in this thread.

Environment

• Claude Desktop 1.24012.9.0 (MSIX, Claude_1.24012.9.0_x64__pzs8sxrjxfjjc)
• Claude Code 2.1.200, model Opus 5
• Windows 11 Enterprise, build 26200
• GPU: AMD Radeon RX 7700S + AMD Radeon 780M iGPU (driver 32.0.31021.5001), plus two DisplayLink USB display adapters
• Prior reports here are NVIDIA (#80444 RTX 2080, #61372 GTX 1650, the comment above RTX 4070 SUPER)

What was tried

claude_desktop_config.json, restarting the app between each attempt and verifying the key was still present afterwards:

| Placement | Result |
|---|---|
| top level | crash |
| top level and under preferences | crash |

Trigger both times: a single preview_start on https://anidb.net/anime/9227. The call returns "navOk": true; the crash follows during render.

Evidence

2026-07-28 15:33:39 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,

101457950 = 0x060C201E, identical to #80444. Two entries, matching the two attempts.

Why it probably doesn't cover this path

With the key set and the app restarted, the process tree still looked like this:

| Process | disable-gpu in command line | --use-gl |
|---|---|---|
| main | no | — |
| --type=gpu-process | no | angle |
| renderer (2×) | yes | — |

So the setting is being honoured — but only for renderer processes. The GPU process still starts with hardware GL, and that is where the crash occurs. app.disableHardwareAcceleration() appears not to reach it.

Two side findings

1. The app rewrites claude_desktop_config.json on startup and dropped the unknown key on the first attempt (file written 15:05:55, app processes started 15:05:50–15:05:58). Anyone applying this workaround should re-check the file after the next launch. Under MSIX the file lives at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json and is mirrored at %APPDATA%\Claude\.

1. The --disable-gpu relaunch from #80444 is not reachable without admin rights. The command is correct — verified against the manifest (PackageFamilyName Claude_pzs8sxrjxfjjc, Id 'Claude', Executable 'app\Claude.exe') — but fails with 0x800704C7 (ERROR_CANCELLED) while the app is running, and the app cannot be fully stopped: cowork-svc is the Windows service CoworkVMService (start type Automatic), which a non-elevated user cannot stop and which brings the app back.

So on this machine there is currently no working prevention other than not opening the Browser pane.

---
🤖 Diagnosed with Claude Code (app logs, process command lines, MSIX manifest) with Opus 5 Ultracode

Fourth independent reproduction, and I think the three open reports are the same bug seen from different angles. This one has the trigger and the MSIX corruption; #80689 has the trigger isolated to Cloudflare Turnstile; #81698 has the renderer-side signature. I can confirm all three halves on one machine, plus one detail none of them mention.

Environment

| | |
|---|---|
| Claude Desktop | 1.24012.9.0 (MSIX, sideloaded) |
| Claude Code | 2.1.219 bundled (per [CCD] Initialized with version); 2.1.220 as npm-global CLI |
| Windows | 11 Pro, build 10.0.26200 |
| GPU | NVIDIA RTX 2070 SUPER + AMD Radeon iGPU (hybrid) |
| RAM | 63 GB (~45 GB free at crash time) |

Differential diagnosis — the trigger is Turnstile, confirming #80689

Three loads in the app's built-in Browser pane:

| Page | Result |
|---|---|
| example.com — static, pane visible, compositing | OK, no crash |
| get.webgl.org — WebGL, animated cube rendering | OK, no crash |
| Our own app on localhost:3000 — embeds Cloudflare Turnstile | crash 3/3 |

So the Browser pane itself is fine, and generic WebGL is fine. The page that embeds challenges.cloudflare.com/turnstile/v0/api.js kills the GPU process every time, which is exactly the hypothesis in #80689. Worth noting this is not a third-party site: it is our own Next.js app on localhost. Any developer whose project uses Turnstile on a public form will hit this while previewing their own work.

Every crash, same exit code:

[Preview] Created browser preview { serverId: 'browser-preview-...' }
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

101457950 = 0x060C201E, identical across all three, and identical to #81159, #81698 and #80689.

Renderer-side signature (links this to #81698)

main.log only records the death. The cause is in logs\unknown-window.log, in the same second:

WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat
WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_[half_]float is not enabled
WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_float is not enabled
The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
A valid external Instance reference no longer exists.
WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

Byte-identical to the lines in #81698. That log is easy to miss — worth pointing people at it in triage.

Not the GPU, the driver, or hybrid graphics

Reproduced under three different graphics configurations, all crashing identically:

1. Default (Windows picks between the two adapters) — crash.
2. Pinned to the discrete NVIDIA via HKCU\Software\Microsoft\DirectX\UserGpuPreferences → GpuPreference=2 — crash.
3. Hardware acceleration disabled (isHardwareAccelerationDisabled: true) — crash.

For case 3, confirmed from the GPU process command line that it really was software rendering:

before:  --type=gpu-process --gpu-preferences=...
after:   --type=gpu-process --use-angle=d3d11-warp-webgl --use-gl=angle

d3d11-warp is Microsoft's software rasterizer, so no physical adapter is involved and it still dies. This independently reproduces the same conclusion reached in #80689, on unrelated hardware (RTX 2070 SUPER + Radeon iGPU vs the RTX 4060 there and the RTX 5080 in #81698). "Update your GPU driver" is not the answer — worth ruling out early.

Secondary chain: the crash alone leaves the MSIX package unusable

This issue's title mentions the corruption. Here is what I can state from the logs, using the third crash as the cleanest case — the package had just been freshly installed and was Status: Ok:

1. GPU process dies at 03:42:40; the app is gone by 03:42:42, taking every in-flight Claude Code session with it. No Application Error / WER record is produced, so nothing appears in Event Viewer and the failure looks like a broken install rather than a crash.
2. Two minutes later, with no user action of any kind: Get-AppxPackage -Name Claude → Status: Modified, NeedsRemediation, and the app will not launch.
3. AppXDeploymentServer/Operational shows zero deployment operations for the package in that window (no Add, no Register, no Repair). So the crash by itself is enough to flip the package into that state — nothing re-staged or rewrote it.
4. Windows re-registers the package on the next activation attempt (event 400, success, 344 ms) without clearing the flag. An explicit Add-AppxPackage -Register <InstallLocation>\AppxManifest.xml also reports success and does not clear it either.
5. Repair from Windows Settings fails every time for me — "This app couldn't be repaired". The log shows it running RepairPackageOperation → Add from a cached MSIX → RegisterByPackageFullName, all reported successful, with the status unchanged. This differs from the original report here, where Repair restores the app at least temporarily.
6. The only recovery that works is a full remove + install:

``powershell
Get-AppxPackage -Name Claude | Remove-AppxPackage
Add-AppxPackage -Path "$env:LOCALAPPDATA\Temp\Claude-<id>.msix"
``

This wipes the app data store, so the Microsoft sign-in is lost on every occurrence. It also deletes the ~9.8 GB Cowork VM bundle, which the next pre-warm re-downloads.

Since the crash is deterministic, this makes for a genuine loop: crash → broken package → reinstall → sign in → crash. That is what turns a renderer crash into hours of work, and it is the part I would prioritise: a GPU process crash should never be able to damage the installation.

isHardwareAccelerationAutoDisabled never fires

The bundle contains an auto-recovery path that looks designed for exactly this:

async function Itt(e, { auto: t = false } = {}) {
  ...
  n.isHardwareAccelerationDisabled = e;
  n.isHardwareAccelerationAutoDisabled = r;
  n.isHardwareAccelerationAutoDisableNoticePending = r;
}

Across three identical GPU crashes with the same exit code it never triggered, and no notice was ever shown. Even though disabling acceleration does not fix this crash, the safety net not arming meant there was no signal at all pointing at the GPU process — the failure just looked like a corrupted install.

Artifacts

Happy to send any of these:

• 3 Crashpad minidumps (~35 MB each) from the three crashes, captured out of the container before reinstalling.
• The AppXDeploymentServer sequence after the first crash, which is different and which I deliberately am not drawing conclusions from: a Remove of the package followed ~70 s later by an Add of a freshly staged Claude-<id>.msix from %LOCALAPPDATA%\Temp (since deleted), which rewrote all 2182 files in the install directory. I cannot tell from the logs what initiated that, so I am not claiming the app did — but if there is an updater or self-heal path that fires after a crash, its interaction with this state may be worth checking.
• main.log and unknown-window.log from the moment of each crash. Note that the app truncates main.log on restart, so the GPU process gone line is gone by the time a user looks — these were only preserved by copying the logs out from an external process every few seconds. That may be why the signature is under-reported.
• AppXDeploymentServer/Operational and Service Control Manager exports covering the re-stage and the failed registration.
• Full per-file LastWriteTime listing of the package showing the 2182-file rewrite.

Workaround for anyone hitting this

Do not open pages that embed Turnstile or a CAPTCHA in the built-in Browser pane; use an external browser. If your own project embeds Turnstile, gate it off in development — we now skip both the widget render and the server-side token check when NODE_ENV === 'development', which makes local previewing safe again.

Also watch out for the crash-loop noted in #80689: the Browser-pane tab persists in session state and can re-crash on session restore.

Possibly related: #80999 — a Code Integrity block on the packaged vk_swiftshader.dll during a hidden Browser-pane preview, ending in the same Repair dialog. That would tie the software-rendering path (case 3 above) and the package-integrity flag together in one mechanism.

Having this same bug it seems - Fable drafted some info to share:

Environment

• Claude Desktop 1.24012.9.0 x64 MSIX (build de160fb, 2026-07-13 per WER TargetAppVer); previously reproduced on 1.22209.0.0
• Windows 10 Education 19045, x64
• NVIDIA RTX 3050 laptop GPU, driver 32.0.16.1074 (2026-07-01) — driver ruled out, see below
• Package: Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, SignatureKind=Developer

Summary

The shipped MSIX contains no AppxMetadata\CodeIntegrity.cat (verified absent from a
clean install; AppxSignature.p7x and AppxBlockMap.xml are present). Chromium applies
the CIG / "Microsoft-signed only" process mitigation to the GPU child as a delayed
mitigation, so startup loads succeed — but when the GPU process later lazily loads the
bundled vk_swiftshader.dll (which has no embedded Authenticode signature and therefore
can only be validated through the package catalog), Windows Code Integrity blocks the load.
The GPU process dies and cannot respawn; the whole app freezes (Windows logs
MoAppHang/Event 1002, not a crash — no Crashpad minidumps, because nothing faults
in-process).

Downstream UX failure: when the user clicks the app while it is hung, Windows attempts an
automatic package repair (RegisterByPackageFullName … RepairAppRegistrationOption),
which fails with 0x80073D02 "apps need to be closed" because the hung claude.exe still
counts as running — and the user is shown "This app can't open. There's a problem with
Claude. Reinstall the application from its original location or contact an
administrator." Users then uninstall/reinstall (this user: 5 reinstalls in 9 days,
latest 07-30 10:02 installing the byte-identical 1.24012.9 package), which "fixes"
nothing — the next lazy Vulkan load kills the app again.

Evidence (Windows event logs, one machine, all local time)

Five freezes, each with this exact signature at the same second:

| Freeze | main.log | CodeIntegrity/Operational |
|---|---|---|
| 07-25 21:15:53 | GPU process gone: { reason: 'crashed', exitCode: 101457950 } | 3010 ×2: unable to load …\Claude_1.24012.9.0_…\AppxMetadata\CodeIntegrity.cat catalog. Status 0xC000003A + 3033: claude.exe attempted to load …\app\vk_swiftshader.dll that did not meet the Microsoft signing level requirements |
| 07-26 13:23:16 | same, identical exitCode | same 3010 ×2 + 3033 |
| 07-27 17:28:10 | same, identical exitCode | same 3010 ×2 + 3033 |
| 07-29 14:08:14 | same, identical exitCode | same 3010 ×2 + 3033 |
| 07-30 09:57:44 | same, identical exitCode | same 3010 ×2 + 3033 |

Also reproduced on v1.22209.0.0 on 07-17 (08:59:51 and 10:24:28) — that day the trigger
was heavy WebGL content in the embedded Browser pane; the four above immediately followed
claude.ai oauth/Turnstile activity in main.log (Turnstile probes WebGL/GPU, which is what
makes Chromium reach for software Vulkan). The 07-29 freeze second additionally shows
in-app browser-preview creation + oauth token lookup in main.log directly before
GPU process gone; the 07-30 freeze shows only repeated oauth token activity in the
final seconds — that session never used the embedded browser at all — so the app's own
claude.ai auth surface is sufficient to trigger the fatal load.

The in-app "Disable hardware acceleration" toggle does not prevent this. The 07-29
and 07-30 freezes both occurred with isHardwareAccelerationDisabled: true already
active: the setting has been in claude_desktop_config.json since at least 07-28 19:40
(file untouched since, mtime-verified) and both crashed instances were cold starts under
it (07-29 09:11, 07-30 08:50). Under this exact config the GPU child runs
--use-gl=angle --use-angle=d3d11-warp-webgl (verified on the live post-crash instance,
which also shows no vk_swiftshader.dll module loaded) — yet both instances' GPU
processes still lazily reached for vk_swiftshader.dll (14:08:14, 09:57:44) and were
killed identically. WebGL-on-WARP removes routine SwiftShader use but not the lazy
Vulkan path, so fix #2 (preload) or #1 (catalog) is required.

Repair-loop evidence (AppXDeploymentServer/Operational): 0x80073D02 "Unable to install
because the following apps need to be closed Claude_…" on 07-10, 07-17 (×4), 07-25
21:15:59 (six seconds after the freeze), 07-26 20:57, 07-27 18:28, 07-30 10:01:07 —
each followed by the user uninstalling (Remove operation) and re-running Claude Setup.exe
(Add from %LOCALAPPDATA%\Temp\Claude-*.msix).

Package state on the CURRENT clean install (performed 07-27 18:30 via Claude Setup.exe):

Test-Path "$pkg\AppxMetadata"          -> False   (directory does not exist)
Test-Path "$pkg\AppxSignature.p7x"     -> True
Test-Path "$pkg\AppxBlockMap.xml"      -> True
Test-Path "$pkg\app\vk_swiftshader.dll"-> True

Note this is not machine-specific security policy: Brave on the same machine logs the same
3033 for its own vk_swiftshader.dll/vulkan-1.dll and shrugs it off (non-fatal probe,
non-MSIX app). For Claude it is fatal because the GPU process dies and cannot come back.

Ruled out

• GPU driver: updated 2024-08 → 2026-07-01 driver on 07-26; froze again the same day with

a byte-identical exit code. No Event 4101 TDRs.

• OOM: [process-memory] lines flat (~1.6 GB app, 1.6–3.4 GB sys free) at each freeze.
• Disk/NTFS errors, dirty shutdowns, malware: none in the relevant windows.

Suggested fixes

1. Ship AppxMetadata\CodeIntegrity.cat in the MSIX (or Authenticode-sign

vk_swiftshader.dll / vulkan-1.dll) so lazy loads pass CIG.

1. And/or take the Chromium fix that preloads SwiftShader during GPU sandbox init before

the delayed CIG mitigation applies (963206a961a7992b048d07f756f87f11fa2e5420) — same
mechanism and remedy discussed in openai/codex#34133 for their MSIX Electron app.

1. UX: the activation-time auto-repair should terminate the package's hung processes (the

Remove path already does) instead of failing 0x80073D02 and telling the user to
reinstall.

Workaround being used meanwhile

Kill the hung claude.exe, relaunch (no reinstall needed). "Disable hardware acceleration"
is enabled but proved insufficient on 07-29 and 07-30 (see above) — it switches WebGL to
D3D11/WARP rather than front-loading SwiftShader, and the lazy vk_swiftshader.dll load
still occurs. No user-side prevention exists on MSIX (GPU flags can't be passed — see
#61372).

Hitting the same crash, and I have some data points that suggest it is broader than in-page browser actions.

Setup: Windows 11 Home 10.0.26200, Claude Desktop 1.24012.9 (MSIX), dual GPU desktop (NVIDIA RTX 3060 + AMD Radeon iGPU on a Ryzen), 64 GB RAM. Heavy Claude Code sessions with background agents, no in-app browser use at all in most of the crashes.

7 crashes across 2 days (Jul 30-31), all with the identical signature:

GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

Every crash kills the whole app and Windows then offers the MSIX "Repair" flow, same as OP.

Extra data points:

• Regression window: zero crashes on 1.22209.3 and earlier (weeks of similar heavy use). First crash came on 1.24012.1, and they continued after updating to 1.24012.9.
• One crash happened at 5am with the machine idle, so it does not require a browser action or active user input.
• Not memory pressure: a sampler was logging RAM every 20s during two of the crashes, 41 GB free at the moment of death.
• Forcing the app onto either GPU via Windows Graphics settings (UserGpuPreferences, GpuPreference=2) does not help. It crashed on the AMD iGPU and then again while pinned to the NVIDIA card, same exit code.
• Clearing GPUCache, DawnGraphiteCache and DawnWebGPUCache plus a full reboot did not help.
• Reinstalling from the official ClaudeSetup exe (same 1.24012.9) did not help.
• Because it is MSIX, none of the usual Electron escape hatches work: ELECTRON_EXTRA_LAUNCH_ARGS is ignored and launch args like --disable-gpu get dropped on activation, so there is currently no user-side workaround at all. An in-app "disable hardware acceleration" toggle would at least give us a way out while this gets fixed.

Happy to pull anything else useful from logs on this machine if it helps.

Environment: Claude Desktop 1.24012.9.0 (MSIX sideload), Windows 11 26200, Surface-class device, Intel Iris Xe (Tiger Lake, DEV_9A49), driver 32.0.101.7088 (June 2026), 16 GB RAM, Max plan.

Summary: Since mid-July 2026 the app crashes silently under sustained multi-chat load (deep research sessions). Worked flawlessly before. Every crash shows the same signature in main.log:

GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Preceded by repeated WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat in unknown-window.log. Memory is stable at crash time (~2.1 GB tree RSS, ~1 GB system free) — not OOM.

Critical secondary effect: after most crashes the package flips to Modified, NeedsRemediation (Get-AppxPackage). Windows Settings Repair and Reset both fail; the app will not reopen. Only full package removal + reboot + reinstall recovers. AppXDeployment-Server log shows event 5224 failures deleting SystemAppData\Helium\User.dat* (error 0x20) during removal.

Ruled out by testing (clean reinstall between each):

GPU driver age: updated 32.0.101.6737 (Apr 2025) → 32.0.101.7088 (Jun 2026) — crash persists
Virtual display drivers: Meta Virtual Monitor and Virtual Desktop Monitor disabled — crash persists
Chrome extension native host (chrome-native-host.exe): removed — crash persists
CoworkVMService: disabled — no effect

Repro: open 4–6 chats including at least one deep research; sustained session with parallel chats crashes reliably. Exit code is identical across all crashes (deterministic).

Timeline: no issues before ~July 15–18, 2026. Regression window coincides with app auto-updates. Logs available on request (main.log, unknown-window.log, AppXDeployment-Server export).

Root-cause evidence and a confirmed workaround for this crash class are posted in #80444: Windows Code Integrity Event 3033 blocks the bundled vk_swiftshader.dll inside the sideloaded MSIX (which ships no AppxMetadata\CodeIntegrity.cat); any WebGPU probe (ad-tech requestAdapter() fingerprinting) triggers it. The Win32/Squirrel build (winget install Anthropic.Claude) is unaffected — signing-level enforcement doesn't apply to unpackaged processes.