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

[medipalace]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

During an active, long-running Claude Code session (working through a multi-part coding task), as usage approaches the 5-hour session limit (roughly 90-100%), the Claude Desktop app crashes/closes automatically without warning.

After this happens, reopening the app shows an error with a blue background screen. Neither the "Repair" option (Settings → Apps → Installed apps → Claude → Advanced options → Repair) nor toggling Developer Mode on resolves it. The only fix that works is a full uninstall and reinstall of the app.

This has happened on two separate occasions on consecutive days, both times specifically while approaching the 5-hour usage limit during an active task.

Environment:

OS: Windows
Trigger: appears tied to approaching/hitting the 5-hour rolling usage limit during an active session, not a random crash
Workarounds tried: Repair (via Settings → Apps → Installed apps), enabling Developer Mode — neither resolved it
Only working fix: full uninstall + reinstall (loses nothing critical, since project files and Claude Code session history are stored outside the app package, but is disruptive mid-task)

What Should Happen?

Hitting the usage limit should show a normal "limit reached, resets at X" message and either pause gracefully or let me continue browsing history — not crash the app entirely and require reinstallation to use it again.

One thing worth doing before you submit: the bug tracker template usually asks you to check whether this has already been reported. Given how specific "crashes exactly at usage limit, needs reinstall" is, it's worth a quick search on that GitHub issues page first — if there's already a matching report, adding a comment with your details ("this is also happening to me, on Windows, same symptoms") is often more useful to them than a duplicate report.

Error Messages/Logs

"There's a problem with Claude. Reinstall the application from its original install location or contact your administrator."

Steps to Reproduce

1. Open Claude Desktop and start a Claude Code session on an active project.
2. Work through a long task, continuing to use the app until usage approaches the 5-hour session limit (around 90–100%).
3. The app crashes/closes automatically, without any warning or "limit reached" message.
4. Attempt to reopen Claude Desktop.
5. The app fails to open and shows: "There's a problem with Claude. Reinstall the application from its original install location or contact your administrator."
6. Try Settings → Apps → Installed apps → Claude → Advanced options → Repair — does not fix it.
7. Try enabling Developer Mode (Settings → System → For Developers) — does not fix it.
8. Only a full uninstall and reinstall of the app resolves it, until the same sequence happens again on the next long session.

This full sequence has occurred twice, on two consecutive days, both times specifically while approaching the 5-hour usage limit during active use.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

running latest version

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

No response

[medipalace]

happened again even after reinstalled via administrator permission, this time took the screenshot

[medipalace]

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.

[medipalace]

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.

[medipalace]

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.

[medipalace]

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.

[medipalace]

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.

[medipalace]

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

[hrdd-cmd]

I'm hitting the same issue on a different setup — adding some data points that might not be covered yet in this thread.

Environment:

• Desktop PC, Windows 10
• NVIDIA GPU, latest Studio driver (610.88, released 2026-07-28) — driver is confirmed up to date, so this isn't a stale-driver issue
• Kaspersky (antivirus) installed
• Windows VBS (Virtualization-based Security) / Core Isolation / Memory Integrity — confirmed disabled, so this isn't a VBS/Hyper-V GPU-acceleration conflict either
• No proxy on system level (netsh winhttp show proxy confirms direct connection)
• MSIX package: Claude_pzs8sxrjxfjjc, version 1.26832.0.0

Symptom (matches this thread):
App loads the claude.ai login page → completes Cloudflare Turnstile verification → crashes at the exact moment verification finishes. After the crash, relaunching immediately shows "This app can't open" and the package must be fully reinstalled to open again, only to hit the same crash on the next Turnstile verification. This creates a repeated open → crash → reinstall loop.

Two things I haven't seen mentioned elsewhere in related issues, which might help narrow down the root cause:

1. Package corruption isn't always triggered by a runtime crash. In my testing, I did a clean uninstall (Remove-AppxPackage, confirmed Get-AppxPackage returns empty, confirmed no leftover Get-AppxProvisionedPackage entries), then a fresh install from the direct MSIX link. Checking Get-AppxPackage *Claude* immediately after install — before ever launching the app once — already showed Status: Modified, NeedsRemediation. This suggests the corruption may also occur during install/deployment itself, not only as a consequence of the Turnstile crash.

2. Third-party AV's HTTPS/TLS inspection interacts with this, but doesn't fully explain it. Kaspersky's "Scan encrypted connections" feature (a TLS man-in-the-middle inspection layer) was interfering with both the MSIX download and the Cloudflare verification page itself — the claude.ai site was stuck on "Verifying you are human" in browser too, until I disabled this Kaspersky feature. After disabling it and excluding C:\Program Files\WindowsApps + the installer download folder from Kaspersky scanning (all protection components), a fresh install did register with Status: Ok. However, the Turnstile-verification crash still happened afterward, so Kaspersky's TLS inspection appears to be an aggravating factor (it can independently corrupt the package or block network resources) rather than the root cause of the crash itself.

Things I've ruled out on my end: system file corruption (sfc /scannow — found & fixed unrelated corrupted files, no effect on this issue), NTFS permissions on the install directory (checked via icacls, no denied entries), dependency runtimes (VCLibs / UI.Xaml / .NET Native / WindowsAppRuntime — all Status: Ok), general MSIX/AppX framework health (Windows' built-in Calculator app launches fine via shell:AppsFolder), proxy/network interception, and both VBS and GPU driver version as noted above.

Happy to provide crash dumps or run additional diagnostics if useful.