[BUG] Claude Desktop crashes when browser preview renders Cloudflare Turnstile — reproducible across multiple machines/GPUs, app becomes unlaunchable

happened again even after reinstalled via administrator permission, this time took the screenshot
<img width="944" height="266" alt="Image" src="https://github.com/user-attachments/assets/a32ed7b3-c94d-4d82-9143-b284438cfa16" />

Confirmed reproducible trigger: the app crashes specifically and consistently when
Claude Code opens its in-app browser preview to check a live URL. Tested deliberately:
multiple file-only/git-only/database-only tasks completed with zero crashes across an
extended session, then the app crashed immediately upon opening the browser preview
for the first time, on request, to verify a live page. This matches GitHub issue #80444
("in-app Browser pane... GPU process dies → app dies") and #68049 (GPU process crash,
exitCode 101457950) — both already referenced in this report. On this system (integrated
AMD Radeon R7, single GPU, 7GB total RAM), the browser preview appears to be a reliable,
repeatable crash trigger, not an intermittent one.

Confirmed not version-specific: tested rolling back from 1.24012.9 to 1.24012.0
(previous release, 2026-07-21) specifically to see if this resolved the GPU-process
crash. The exact same crash occurred at the exact same trigger point (opening the
in-app browser preview to check a live URL), on the older version too. This appears
to be a persistent issue across recent releases, not a regression introduced in one
specific build.

Ruled out memory pressure as the primary cause: repeated the exact same browser-preview
trigger with ~2GB additional free memory confirmed via Task Manager at the moment of
the crash (closed Firefox and one Chrome instance beforehand). The crash occurred
identically regardless. This points to the GPU rendering pathway itself failing on this
hardware/driver combination (integrated AMD Radeon R7, driver 22.6.1), not a
memory-availability issue.

Update: Root cause isolated to specific animated content, workaround applied

Following up with a full account of the investigation since filing this issue, since I was able to isolate the trigger precisely.

Environment (confirmed)
CPU: AMD A12 (APU with integrated graphics)
GPU: Integrated AMD Radeon R7 Graphics — confirmed single GPU via Device Manager (no dual-GPU/switchable graphics)
Driver: AMD Radeon Software reports up to date at version 22.6.1 (no newer driver available for this chip generation — last released ~2022)
RAM: ~7GB total system memory

**Steps taken to isolate the cause

1. Confirmed the crash signature.** main.log showed:

GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
[warn] [Preview] capturePreviewScreenshotIfChanged failed: { error: [Error: UnknownVizError] }

Occurred consistently during Claude Code sessions when its browser preview was used. After the crash, C:\ProgramData\Claude\ was found almost entirely empty (only Logs\cowork-service remained), and the app became unlaunchable — "There's a problem with Claude. Reinstall the application from its original install location or contact your administrator." — until fully uninstalled and reinstalled.

2. Ruled out memory pressure as the primary cause. Repeated the same trigger with ~2GB additional free RAM confirmed via Task Manager at the moment of the crash (closed an extra browser instance beforehand). Crashed identically.

3. Ruled out app version. Rolled back from 1.24012.9 to the previous release 1.24012.0 (2026-07-21). Crashed identically at the same trigger point on the older version too.

4. Ruled out the app's own hardware-acceleration setting. Found and used Help → Troubleshooting → "Disable Hardware Acceleration," confirmed active after a full restart. Crashed identically anyway — the failure occurs below the level this setting can control.

5. Ruled out Cowork. Did a clean reinstall without Cowork (declined during setup, since Hyper-V/virtualization permissions weren't available without admin rights). Crash still occurred on plain Claude Code browser preview usage — unrelated to Cowork's own separate VM subsystem (which, incidentally, also never successfully initialized on this machine per cowork_vm_node.log — rootfs.vhdx missing on every entry for months — but that's a separate, non-blocking issue).

6. Precisely isolated the actual trigger. google.com and a static page on my own site both loaded successfully in the browser preview with no crash. The crash occurred specifically and reproducibly when the browser preview rendered a page containing Cloudflare Turnstile's animated "verifying" spinner — the crash occurred at the exact moment the widget's animation began, not on page load itself.

7. Additional observation, possibly broader than Turnstile specifically: on a separate test, screenshot/read_page-style compositing calls in the browser preview timed out ("Browser pane is not displayed") even on a page containing zero animated or CAPTCHA content (a static Cloudflare documentation page). This suggests the underlying issue may affect screenshot/compositing operations in the browser pane more broadly on this hardware, not exclusively pages with animated widgets — though animated content (Turnstile specifically) was the only reliably reproducible trigger found.

Workaround applied on my end

Since the crash was reliably and specifically tied to Turnstile's animated widget:

• First tried Turnstile's appearance: "interaction-only" mode (defers rendering until user interaction) — reduced but did not eliminate the crash, since the widget could still animate once a user interacted with the form.
• Ultimately removed Turnstile entirely from all affected pages and replaced it with invisible, non-rendering bot mitigation (honeypot field + submission-timing check + existing rate limiting) — a real security tradeoff, but one that eliminates any GPU-accelerated animated rendering from these pages entirely. Verified working via multiple clean browser-preview passes afterward (6/6 pages, clean screenshots, no timeouts, no console errors — where the same pages had previously crashed or timed out on compositing).

Summary for triage

This appears to be a genuine GPU-process rendering failure specific to older/integrated AMD graphics (Radeon R7, driver last updated 2022) when the browser preview renders actively-animating content, and the app's own hardware-acceleration toggle does not mitigate it. The bigger concern beyond my specific workaround: a GPU crash during preview rendering takes down the entire app and appears to corrupt/clear its local app data folder, requiring a full reinstall rather than a graceful recovery — that failure mode seems like the real underlying defect worth fixing, independent of what specifically triggers the GPU crash on a given machine.

Happy to provide the full log files or Generate Diagnostic Report output if useful.

Major update: reproduced on a second, very different machine

Correction to my earlier hardware-specific diagnosis. I previously concluded this was specific to my primary machine's older integrated AMD graphics. That conclusion needs revising.

Tested the identical trigger — visiting https://www.openstreetmap.org/user/new (confirmed via their own public GitHub PR #4314 to use Cloudflare Turnstile) — on a second, substantially different machine:

GPU: NVIDIA GeForce GTX 1060 3GB (dedicated)
RAM: 16GB
Driver version: 30.0.15.1215, dated 2022-03-17

The app crashed identically on this second machine.

This rules out my original hypothesis that this was specific to low-end/integrated AMD graphics — a dedicated NVIDIA GPU with 16GB system RAM (versus the original 7GB integrated-AMD machine) reproduces the exact same crash. The one variable both machines still share is a graphics driver dated around 2022 — worth noting as a possible remaining factor, though the difference in GPU vendor, architecture, and RAM is significant enough that this looks like it could affect a meaningfully broad range of users on somewhat-older (but not unreasonably ancient) graphics drivers, not just a narrow edge case.

Confirmed reproducible trigger, now on two machines, two GPU vendors:
Visiting any page with an active Cloudflare Turnstile widget in Claude Code's browser preview → GPU process crashes → app becomes unresponsive/unlaunchable → requires full reinstall.

Given this reproduces across NVIDIA and AMD, integrated and dedicated, 7GB and 16GB RAM — I'd suggest this deserves higher-priority triage than an isolated hardware quirk. Happy to test on any specific driver version or configuration if that would help narrow this down further.

Priority request:

Given this reproduces consistently across two machines with meaningfully different hardware (integrated AMD vs. dedicated NVIDIA, 7GB vs. 16GB RAM, two different GPU vendors), on a completely unrelated third-party website with no connection to my own project, I believe this represents a genuine, broad compatibility issue between Claude Desktop's browser preview and Cloudflare Turnstile — not a narrow edge case. Given Turnstile is used on tens of thousands of live websites (confirmed via public technology-tracking data), any user encountering a Turnstile-protected page in the browser preview is likely to hit this. I'd ask that this be reviewed, verified, and prioritized for a fix by the Anthropic team as soon as reasonably possible, given the severity of the failure mode (app becomes fully unlaunchable, requiring a complete reinstall each time).

Cost of this investigation:

Worth noting for context: isolating this took roughly a week of active troubleshooting, consuming a meaningful portion of my Pro subscription's usage across that period — much of it initially spent testing the wrong hypothesis (assuming this was a fault with my own machine) before I isolated the actual cause by deliberately opening a Turnstile-protected page in the browser preview and watching it crash in real time, then confirming it wasn't machine-specific by reproducing it on a second, unrelated machine.

I'm not asking for anything specific in return, but if there's a way for Anthropic to acknowledge this, a hiring, whether that's crediting the report, a note of appreciation, or consideration of some form of goodwill given the subscription time this consumed while helping surface what looks like a genuine, broad-impact bug — I'd genuinely appreciate it.
Thanks,
Muhammad Adil