Windows: embedded browser preview GPU crash (exit 0x60C201E) on Cloudflare Turnstile login page deadlocks main process; app killed as AppHangB1, presents as "passkey prompt crashes app"

Environment

• Claude Desktop 1.28929.0.0, MSIX package Claude_1.28929.0.0_x64__pzs8sxrjxfjjc

(upgraded same day from Squirrel install 1.24012.9)

• Windows 11 Pro, build 10.0.26200, x64, 16 GB RAM
• A third-party passkey provider (Proton Pass) is registered with Windows
• Reproduced twice in one afternoon with an identical fingerprint

Summary

Opening a third-party login page (wise.com) in the embedded Browser preview kills the Chromium
GPU process with exit code 101457950 (0x60C201E) within seconds of the page loading its
Cloudflare Turnstile frames and calling WebGPU requestAdapter. The Electron main process
never recovers from the GPU death: it writes nothing further to main.log and stops pumping
messages until Windows terminates the package (Application log Event 1002, AppHangB1,
HangType Quiesce).

To the user this presents as: "the app asks about passkeys, then crashes to desktop whether I
click Yes or No". The passkey sheet belongs to the same login page load; by the time the user
answers it, the app behind it is already hung, so the answer never matters. The user reinstalled
the app twice believing it corrupted; a plain relaunch was always sufficient.

Reproduction as observed (twice)

1. In a Claude session, the embedded Browser preview is opened and navigated to the wise.com

login page (browser:open_site, approved).

1. Page loads: Next.js runtime, Cloudflare Turnstile frames (challenges.cloudflare.com

postMessage warnings), a main-process stall of 3 to 5 seconds around
launch-preview:before-request, then two WebGPU requestAdapter calls.

1. Within 1 second the GPU process crashes with exit code 101457950.
2. main.log goes silent (7m13s and 4m06s in the two incidents) until manual relaunch.

Windows records AppHangB1/Quiesce and terminates the app.

Log evidence (main.log, sanitized)

Incident 1, 15:53:

2026-08-12 15:53:09 [info] Emitted tool permission request ... for browser:open_site in session local_2387359c-...
2026-08-12 15:53:18 [warn] [event-loop-stall] main process blocked for 3297ms (task launch-preview:before-request=4ms, total 6, cumulative 8923ms, rss 312MB)
2026-08-12 15:53:23 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-08-12 15:53:23 [warn] [Preview] capturePreviewScreenshotIfChanged failed: ... UnknownVizError
(no further lines until relaunch at 16:00:36)

Incident 2, 16:16, same exit code, plus the blocklist service timing out and failing open in the
same window:

2026-08-12 16:16:24 [warn] [event-loop-stall] main process blocked for 4814ms (task launch-preview:before-request=4ms, total 3, cumulative 6770ms, rss 294MB)
2026-08-12 16:16:24 [warn] [PreviewBlocklist] challenges.cloudflare.com lookup deadline exceeded; failing open
2026-08-12 16:16:24 [warn] [PreviewBlocklist] domain_info fetch failed; failing open: DOMException [TimeoutError]
2026-08-12 16:16:28 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
(no further lines until relaunch at 16:20:34)

The window log records WebGL: CONTEXT_LOST_WEBGL at the same second as incident 2.

Windows event log evidence

• Event 1002, Application Hang, 15:54:12: claude.exe 1.28929.0.0,

PackageFullName Claude_1.28929.0.0_x64__pzs8sxrjxfjjc, HangType Quiesce. This is 49
seconds after the incident 1 GPU crash line.

• Zero Event 1000 (Application Error) for claude.exe in the last 7 days: this failure is never

an access violation, always a hang after GPU-process death.

• No WER report folder or minidump was produced for the hang, so no wait chain was captured.

Passkey-adjacent observations (secondary, may be a separate defect)

• 15:34:13, a facebook.com-origin window logs "The user agent does not support public key

credentials"; within one second main.log records
[event-loop-stall] main process blocked for 14145ms [likely sleep: duration_heuristic].
The app survived this one. A 14 second synchronous main-process block coinciding with a page
WebAuthn call suggests the passkey path can block the browser-process UI thread even without
the GPU crash. The likely sleep heuristic label appears to be a mislabel in this instance,
though a power-transition report the same afternoon means sleep cannot be fully excluded.

• The Windows WebAuthN operational log shows IsUserVerifyingPlatformAuthenticatorAvailable

returning false for every caller all day, with repeated CTAP service stop/start cycles and
ClientDisconnect warnings. A third-party passkey provider is registered on the machine.
Possibly environmental; listed for completeness.

After each relaunch

Both post-hang relaunches log:

[Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile '...\WindowsApps\Claude_...\app\resources\chrome-native-host.exe' -> '%USERPROFILE%\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'

so something from the killed instance still holds the native host binary open.

Expected behavior

1. A GPU process crash should not deadlock the main process; Electron normally relaunches the

GPU process and the app degrades gracefully.

1. A login page inside the embedded preview should not be able to take down the app.
2. A page-initiated passkey enumeration should never block the main thread for 14 seconds.
3. Ideally, sign-in and third-party login flows would open in the system default browser on

Windows, as the 1.28929.0 changelog describes for macOS.

Notes

• 1.28929.0.0 is current at the time of writing, so there is no newer version to test.
• The macOS-side changelog entries for passkey prompt crashes (v1.25927.0) and the browser

sign-in fallback (v1.28929.0) look like the same code paths; this report is the Windows
counterpart evidence.

• Happy to provide further sanitized log excerpts on request.