[BUG] Browser pane: GPU process crash (exit code 101457950) on Cloudflare Turnstile pages, even with software rendering (Windows 11 MSIX)

Summary

In the Windows MSIX build of Claude Desktop, loading a page that embeds Cloudflare Turnstile (challenges.cloudflare.com/turnstile/v0/api.js) in the built-in Browser pane crashes the Chromium GPU process within 2–6 seconds, every time. The exit code is always 101457950 (0x060C201E). When the GPU process dies the app becomes unusable and does not auto-recover — the user has to close and reopen it manually.

Crucially, the crash still reproduces with hardware acceleration disabled, where the GPU process runs ANGLE on D3D11 WARP (software rendering) — so it is not the NVIDIA driver. Plain WebGL pages do not crash; the Turnstile workload specifically does. No end-user setting worked around it (see "Ruled out"), and because this is the MSIX build there is no supported way to pass --disable-gpu.

Environment

| | |
|---|---|
| App | Claude Desktop 1.24012.1 (MSIX, package Claude_pzs8sxrjxfjjc) |
| Electron / Chromium | Electron 42.7.0 / Chromium 148.0.7778.280 (from Browser-pane user-agent) |
| Bundled Claude Code CLI | 2.1.217 (Node 24.18.0) |
| OS | Windows 11 Home 10.0.26200 |
| CPU | Intel Core i7-13700F (no iGPU — single-GPU system) |
| GPU | NVIDIA GeForce RTX 4060, Studio driver 610.62 (32.0.16.1062) |
| Displays | Dual 1920×1080 @ 60 Hz, HDR off |
| RAM | 32 GB (>22 GB free at every crash) |

Steps to reproduce

1. In the MSIX build, open a Browser pane on a page that renders a Cloudflare Turnstile widget (in our case a WordPress page using the simple-cloudflare-turnstile plugin + Contact Form 7; any Turnstile page should qualify — Cloudflare's own Turnstile demo is a public stand-in).
2. Let the Turnstile widget initialize (it runs Canvas/WebGL fingerprinting on load).
3. Within 2–6 s the GPU process exits with code 101457950 and the app UI becomes unusable.

Reproduction caveat (honesty): all 5 of our crashes came through warm-restore of one saved session's Browser-pane tab that held such a page — i.e. reopening/touching that session recreated the preview and reloaded the page. We have not separately run a fresh direct-navigation test to a public Turnstile demo, because doing so crashes the working app mid-session; we're happy to run that on request. The exact private URL that reproduces 5/5 is available to maintainers.

Log signature

%APPDATA%\Claude\logs\main.log:

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

Five crashes over two days, identical exit code, each 2–6 s after a [Preview] Created browser preview event:

| Preview created | GPU crash | Δ | HW accel |
|---|---|---|---|
| 17:20:46 | 17:20:52 | 6 s | on |
| 18:04:47 | 18:04:49 | 2 s | on |
| 04:45:05 | 04:45:07 | 2 s | off (WARP) |
| 05:27:10 | 05:27:12 | 2 s | off (WARP) |

_{A fifth, earlier crash (17:11:12) was delayed: its preview was created at 16:20:18 while the pane stayed hidden (capturePreviewScreenshot kept failing with "the Browser pane is not displayed, so the page is not compositing frames" 16:23–16:41), and the crash landed when the pane became visible. The visibility→compositing→crash link there is a hypothesis, not proven.}

Why this is a Chromium/ANGLE issue, not the GPU driver

Crashes #3 and #4 above occurred with hardware acceleration disabled (isHardwareAccelerationDisabled: true in config.json; renderer processes carried --disable-gpu-compositing). Under that configuration the GPU process runs with --use-angle=d3d11-warp-webgl, and a control test on a benign WebGL page reported the renderer as:

ANGLE (Microsoft, Microsoft Basic Render Driver (0x0000008C) Direct3D11 vs_5_0 ps_5_0, D3D11)

i.e. pure WARP software rendering. The Turnstile page still crashed the GPU process there — so the NVIDIA hardware path is not involved.

Control (same machine, minutes before crash #4, fresh session): open a browser preview on example.com, navigate to get.webgl.org, then via injected JS create a WebGL2 context, upload a 256×256 RGBA texture, and clear() the framebuffer — gl.getError() === NO_ERROR, no crash. So generic WebGL is fine; whatever Turnstile does on init is the trigger.

It would help to know what exit code 101457950 / 0x060C201E decodes to internally, and whether it's a known Chromium/ANGLE GPU-process failure.

Ruled out (crash reproduced after each)

1. NVIDIA driver — clean-updated 536.67 (2023) → Studio 610.62 (2026); crashes #4/#5 are on the new driver.
2. Disable Hardware Acceleration — verified applied; crashes #4/#5 happened under it (WebGL still routes through the GPU process on WARP). See renderer string above.
3. Hardware-accelerated GPU Scheduling (HAGS) off — HwSchMode=1 + reboot; crash #5 is after this.
4. HDR — verified off on both displays (DISPLAYCONFIG_DEVICE_INFO_GET_ADVANCED_COLOR_INFO).
5. Memory — app's own [process-memory] lines show >22 GB free at every crash.
6. Shader/GPU cache — wiped by reinstall during triage; crash returns.

MSIX constraint (why users can't self-serve --disable-gpu)

ELECTRON_EXTRA_LAUNCH_ARGS is ignored by the MSIX build, and inspecting app.asar shows no handler for chromiumFlags, ELECTRON_DISABLE_GPU, or any config-driven switch injection — the only GPU-related config path is isHardwareAccelerationDisabled → app.disableHardwareAcceleration(), which is compositing-only and insufficient here. Not tested on the non-MSIX (Squirrel/NSIS) build.

This does not appear to be a duplicate of #45031 (request for a way to pass Chromium flags to the MSIX build) or #49676 (Win11 Home MSIX crash on Code-mode switch), though both are related context.

Impact

• GPU-process death takes the whole app down (UI unusable, no auto-recovery, manual relaunch).
• The killer page is persisted in the session's Browser-pane tab state, so every warm-restore of that session re-triggers the crash — the app crash-loops on that session until the user discovers which one holds the tab and archives it. Nothing in the UI explains why.
• Cloudflare Turnstile guards a huge number of login walls, contact forms and admin panels, so this is easy to hit unknowingly.

Suggested directions

1. Recover from GPU-process death instead of leaving the app unusable (child-process-gone → relaunch-GPU / software-fallback would mask this whole class).
2. Don't auto-restore a Browser-pane tab that just caused a GPU crash (crash-loop breaker), and/or surface which session/tab caused it.
3. Offer a supported fully-software Browser pane (--disable-gpu) on MSIX for affected machines.
4. If it's upstream, forward the 101457950 / 0x060C201E signature to Chromium/ANGLE.

Workaround for others hitting this

• Don't open Turnstile/CAPTCHA-protected pages in the built-in Browser pane; use an external browser for those.
• If already crash-looping: find the session whose Browser pane last held such a page and archive it (stops the tab restore). Check main.log for [Preview] Created browser preview immediately followed by GPU process gone.

Happy to provide full logs, the private reproducing URL, or run instrumented/public-demo repros on request.