Windows: Browser pane GPU-process crash on Cloudflare Turnstile page kills entire app; session resume re-triggers it (crash loop)

Environment

• App: Claude desktop for Windows, MSIX/Store install (Claude_pzs8sxrjxfjjc). First crash on 1.37937.1; four further crashes on 1.37937.3 after the in-between auto-update.
• Claude Code (CCD): 2.1.246, Node 24.18.1 (from the app's own Starting app log lines)
• OS: Windows 11 Home 10.0.26220
• GPU: AMD Radeon 890M (integrated). Reproduced on two driver generations: 32.0.13046.1001 (2025-04-10) and 32.0.31041.1004 (2026-08-16) — a deliberate retest after updating the driver produced a byte-identical crash, so this is not a driver-specific fault.

Summary

Navigating the in-app Browser pane (preview browser) to a site fronted by a Cloudflare Turnstile challenge deterministically crashes the app's GPU process within ~1–3 seconds of page load, and the entire app exits with it. Reproduced 5/5 over two days, identical exit code every time, while ~30+ other page loads in the same sessions (including other Cloudflare-CDN sites without an active challenge) were fine.

Example trigger URL: https://www.partingtonps.com — a public site that fronts every request with a Turnstile challenge (Cf-Mitigated: challenge, HTTP 403, CSP allowing challenges.cloudflare.com, worker-src blob:).

A detail that may matter: in all reproductions the Browser pane was not displayed (an agent session driving the pane while hidden; computer{action:"screenshot"} reported "the Browser pane is not displayed, so the page is not compositing frames"). Not yet tested with the pane visible.

Log evidence

%LOCALAPPDATA%\Claude\Logs\main.log — five occurrences, identical signature:

2026-08-26 22:53:27 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-08-26 22:53:30 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
<log goes silent — app process is gone; next line is the next launch's "Starting app">

All five occurrences (each immediately preceded, 1–3 s, by the same [PreviewContext] Blocked subresource to private-resolving host warning, and each the last line before the app died):

| # | Timestamp | App version | GPU driver | exitCode |
|---|---|---|---|---|
| 1 | 2026-08-26 22:53:30 | 1.37937.1 | 32.0.13046.1001 | 101457950 |
| 2 | 2026-08-26 23:00:42 | 1.37937.3 | 32.0.13046.1001 | 101457950 |
| 3 | 2026-08-26 23:06:27 | 1.37937.3 | 32.0.13046.1001 | 101457950 |
| 4 | 2026-08-26 23:10:19 | 1.37937.3 | 32.0.13046.1001 | 101457950 |
| 5 | 2026-08-27 08:49:02 | 1.37937.3 | 32.0.31041.1004 | 101457950 |

101457950 = 0x60C201E. No WER crash dump was produced (%LOCALAPPDATA%\CrashDumps has no Claude entries), no Application-log Event ID 1000, and Crashpad\reports under the package data dir is empty — so nothing user-visible captures the native crash.

Reproduction steps

1. Start an agent session in the desktop app on Windows.
2. Have it open the Browser pane (preview_start) and navigate to a URL fronted by a Cloudflare Turnstile challenge, e.g. https://www.partingtonps.com. (Confirm the challenge is active first: curl -sI shows Cf-Mitigated: challenge.)
3. Within ~1–3 seconds of the challenge page loading: GPU process crashes, app exits. 5/5 in our environment.

Three compounding follow-on problems

1. No GPU-process crash containment. One GPU-process crash takes down the whole app (and every running session in it). Chromium/Electron normally survives a GPU process crash and restarts it; here the app dies with it.

1. Session resume walks straight back into the crash. Resuming the interrupted session re-invokes the agent, which re-issues the pending/next navigation to the same URL → instant crash again. The user rolled back and retried repeatedly and hit the identical crash every time ("crashes at the exact same spot"). There is no guard against resuming into a navigation that just killed the app.

1. Post-crash recovery is broken. After the crash loop, the app refused to relaunch (message directing to "advanced options"). The MSIX Repair tool then refused to run with "Claude is running" even though Task Manager's Apps view showed nothing — background claude.exe CLI engine processes (%APPDATA%\Roaming\Claude\claude-code\<ver>\claude.exe) survive the GUI crash and apparently block the check. On one occasion Repair was still blocked after a full reboot (no Claude autostart entry exists in Run keys or the Startup folder; cause unknown). The only recovery that consistently worked was reinstalling from the claude.ai website download, which re-registers the same MSIX package version.

Suggested fixes

• Contain GPU-process crashes: restart the GPU process / degrade the pane, don't exit the app.
• On resume after an abnormal exit, don't automatically re-execute the browser navigation that immediately preceded the crash (or mark it suspect and require confirmation).
• Make the repair/launch "already running" check ignore (or offer to terminate) orphaned background claude.exe engine processes.
• Capture GPU-process crashes in Crashpad/telemetry — currently nothing lands anywhere a user can find.

Workaround (for anyone else hitting this)

Probe unfamiliar domains with curl -sI before loading them in the Browser pane; if the response carries Cf-Mitigated: challenge, don't pane-load the site. If the app wedges with "Claude is running," kill background claude.exe processes (Get-Process claude | Stop-Process -Force) or reinstall from the website download.