[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

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.

1. 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.

+1, reproduced twice with the same steps.

Setup: Claude Code driving the Browser pane (navigate action) as part of an agentic session — not manual browsing.

Environment: Claude Code desktop v1.28929.0 (Aug 11 changelog build), Windows 11, NVIDIA GeForce RTX 3060 Ti.

Repro:

1. Navigate the Browser pane to a Cloudflare dashboard URL (dash.cloudflare.com/.../workers/services/view/.../builds/...) while not authenticated in that browser profile.
2. Cloudflare redirects to its login page, which renders Turnstile.
3. Within a few seconds of the Turnstile widget rendering, the desktop app crashes.
4. After the crash, the app failed to relaunch normally — matches what's described in this issue as "unlaunchable."

Happened on two separate occasions with the identical repro (same URL, same flow — navigate to an unauthenticated Cloudflare dashboard link).

No workaround found other than avoiding navigating the Browser pane to pages that render Turnstile.

Same issue on Windows 11. Claude Desktop v[sua versão], Claude Code CLI 2.1.231.

App closes by itself after ~5 minutes with the Code panel open, during an active session on a large project. On reopening: "Você precisará acessar as opções avançadas para Claude e selecionar Reparar" (blue screen). Repair does not work — only a full uninstall + reinstall gets it running again, and the crash returns on the first working session.

Happened 3 times in a row today. Sessions were large (700+ MB .jsonl). The desktop sidebar session index was lost each time, though ~/.claude/projects remained intact.

Workaround: running the native CLI / VS Code extension instead — completely stable so far.

Adding a Windows + AMD data point, with app-log evidence that may help narrow this down.

Environment

• Claude Desktop 1.30096.1 (bundled claude-code 2.1.229)
• Windows 11 Pro, build 26200
• GPU: AMD Radeon(TM) Graphics (integrated), driver 32.0.21045.1000
• 3 displays @ 2560x1440, one rotated to portrait, all at 100% scaling
• 12.8 GB RAM

Symptom

Silent termination — no dialog, no Windows Application Error / WER entry, no
Resource-Exhaustion-Detector event, nothing in the System log, and Crashpad
produced no .dmp. The app simply disappears and relaunches.

After the first occurrence the app would not start until I rebooted twice, and
when it finally came up the entire conversation list in the left sidebar was
empty. The session .jsonl files were still on disk under
%USERPROFILE%\.claude\projects\, so nothing was actually lost, but the app no
longer listed any of them.

Trigger — in-app Browser tools on Cloudflare-protected sites

Every crash happened while the in-app Browser was navigating sites behind
Cloudflare bot protection. In my case I was searching ECAD part libraries,
hitting SnapEDA, Octopart, ComponentSearchEngine and Digi-Key in sequence.
All of these return 403 to a plain HTTP client, i.e. they serve a challenge page
rather than content.

Evidence from %APPDATA%\Claude\logs\main.log

Starting app entries — each one is an unclean restart:

00:54:31
00:55:03
01:10:11
01:25:25
01:36:04
10:07:34

Four crashes in 42 minutes while Browser tools were in use. After I stopped
using Browser tools entirely and switched to plain HTTP fetching, the app has run
3.5+ hours with zero crashes (the single Starting app at 10:07:34).

In every case the log ends mid-stream with no error, warning, or shutdown line —
the last few minutes before each restart contain only routine entries.

Memory exhaustion ruled out

The app's own [process-memory] telemetry, last sample before each crash:

before 01:10:11 restart — 01:06:27  tree_rss_sum=2338MB  sys_free=4013MB/13091MB
before 01:25:25 restart — 01:23:07  tree_rss_sum=1646MB  sys_free=3609MB/13091MB
before 01:36:04 restart — 01:34:20  tree_rss_sum=2260MB  sys_free=3073MB/13091MB

3–4 GB of system memory free every time, with the Electron tree at 1.6–2.3 GB.
This is not an OOM condition. A representative full line:

[process-memory] trigger=interval tree_rss_sum=1547MB tree_footprint_sum=613MB
electron(10)=1547MB children(0)=0MB top=[electron_renderer:22060:384MB
electron_main:16116:256MB electron_utility:20096:147MB electron_gpu:7844:139MB
electron_utility:16940:135MB] sys_free=4604MB/13091MB

Note there is a live electron_gpu process in the tree throughout.

Repro (reliable for me)

1. Open the in-app Browser pane.
2. Navigate to a Cloudflare-challenged site (e.g. a SnapEDA part page).
3. Read the page, navigate to another such site, repeat.

Crash occurs within roughly 10–15 minutes of this pattern.

Note

This looks consistent with #82967 (GPU process crash when using Browser tools),
but it reproduces on Windows with an AMD integrated GPU rather than
macOS/Apple Silicon, so the underlying issue does not appear to be platform- or
vendor-specific.

Happy to provide the full main.log if that would be useful.

Follow-up to my previous comment — I dug into main.log further and found the crash signature, plus a possible trigger that may explain why this reproduces for some people and not others.

Confirmed: it is the Electron GPU process, with an identical signature every time

%APPDATA%\Claude\logs\main.log logs a GPU process gone entry immediately before each unclean restart:

2026-08-15 01:07:19 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
2026-08-15 01:10:11 [info] Starting app { appVersion: '1.30096.1', ... }

The same block appears at 01:07:19 → restart 01:10:11, 01:24:05 → restart 01:25:25, and
01:34:34 → restart 01:36:04.

exitCode is byte-identical across all three crashes: 101457950 (0x060C201E).
Not an intermittent or resource-dependent failure — the same fault is being hit every time.

Possible trigger: the app window was on a rotated (portrait) display

This is the part I think is worth checking against other reports.

%APPDATA%\Claude\window-state.json at the time of the crashes:

{"width":1200,"height":800,"x":120,"y":856,"isMaximized":false,"isFullScreen":false,
 "displayBounds":{"x":0,"y":0,"width":1440,"height":2560}}

displayBounds is 1440x2560 — i.e. a 2560x1440 monitor rotated to portrait, and the Claude
window was living on it.

My setup:

| | |
|---|---|
| Machine | GMKtec NucBox M7 |
| GPU | AMD Radeon 680M, integrated RDNA2 (PCI\VEN_1002&DEV_1681) |
| Driver | 32.0.21045.1000, dated 2026-07-23 |
| Displays | 3 x 2560x1440, one rotated to portrait, all at 100% scaling |
| OS | Windows 11 Pro, build 26200 |
| App | Claude Desktop 1.30096.1 (MSIX package) |

A rotated display forces the GPU compositor to apply a rotation transform to everything it
composites. Layering a BrowserView on top of that is a plausible way to hit a driver/compositor
bug, and it would explain why this reproduces reliably for some users and not at all for others
running the same app version.

Contrast data point

The same workload — heavy, sustained in-app browser use for network appliance configuration over
four days — ran with zero crashes on a separate Ubuntu laptop running Claude Code. Different
GPU, different driver stack, no rotated display. So this does not appear to be workload-dependent.

Next test

I am about to move the Claude window to one of the landscape monitors and repeat the same
browser workload. I will report back whether the crashes stop.

If anyone else hitting this issue has a rotated/portrait display in their setup, that would be
useful to know — it may be the common factor.

Also worth noting

exitCode 101457950 does not appear in the Windows Event Log at all, and Crashpad produced no
.dmp, so main.log is currently the only place this signature is visible. It may be worth
surfacing GPU process crashes more loudly, since from the user's point of view the app simply
vanishes with no explanation.

Before anyone spends more time on machine-specific hypotheses: this crash class is root-caused, and Anthropic has consolidated tracking in #81698 (please 👍 that issue rather than filing new reports — a maintainer asked for that when closing duplicates).

Mechanism (full evidence in #81341): on MSIX builds the GPU process runs with the MicrosoftSignedOnly Code Integrity mitigation, the package ships an Anthropic-signed vk_swiftshader.dll and no AppxMetadata\CodeIntegrity.cat — so when Turnstile's bot-check fingerprints the GPU (WebGL/WebGPU probe burst), the process attempts the SwiftShader load and Windows kills it: exitCode 101457950 = 0x060C201E, with CodeIntegrity Events 3033/3010 in the same second (grep the Microsoft-Windows-CodeIntegrity/Operational event log at your crash timestamps — that's also why nothing shows in WER/Crashpad). The same failure flags the package NeedsRemediation, hence "unlaunchable until Repair".

@Cyclops8888 the rotated-display hypothesis is almost certainly coincidence — the identical crash reproduces on single landscape monitors, laptops, NVIDIA/AMD/Intel, and even under WARP software rendering (#81698 has the matrix). Your Ubuntu contrast datapoint fits perfectly though: no MSIX/Code Integrity on Linux. Check the CodeIntegrity event log at 01:07:19 / 01:24:05 / 01:34:34 on 08-15 — you should find the 3033 pair.

Verified user-side fix that keeps the browser pane: "Claude Setup.exe" --exe — the official installer's switch that installs the non-MSIX (Squirrel) build to %LOCALAPPDATA%\AnthropicClaude\, where the same Code Integrity denial is non-fatal. Sessions/auth carry over (%APPDATA%\Claude and ~/.claude are shared; back up first — #83744 lost MSIX-virtualised settings). Confirmations include a same-machine A/B on identical version 1.30096.5: MSIX crashes, Squirrel stable.

Same trigger as this issue: browser pane + human-verification challenge → app permanently unstartable. Twice in one day, Windows 11, version 1.34493.1.

What happened

I use Claude Code daily inside Claude Desktop for a business project. While working in the Code tab, I asked Claude Code to read a page on the UNECE website (an official reference document I needed).

WebSearch and WebFetch were used four times without any problem. UNECE blocked the plain fetch, so Claude Code fell back to the in-app Browser pane — preview_start, then get_page_text. That page presented a "verify you are human" challenge. At that exact moment the app died.

The session transcript ends literally on those two tool calls. Nothing follows.

From then on the app would not start at all, showing:

"You'll need to go to advanced options for Claude and select Repair. If you continue to have problems, reinstall this app or contact your administrator."

This happened twice on the same day, both times tied to the same session and the same browser-pane use. It is not a one-off.

Environment

• Windows 11 Pro, build 10.0.26200, x64
• Claude Desktop 1.34493.1 (MSIX, installed from claude.com/download, with Cowork)
• Paid subscription
• Model: Opus

Recovery attempts — what did and did not work

| Attempt | Result |
|---|---|
| Advanced options → Terminate | no effect |
| Advanced options → Repair (1st occurrence) | "This app couldn't be repaired because it's currently running. Close the app and try again." — no Claude process was visible in Task Manager under Processes, Details or Services. A full reboot did not help. |
| Advanced options → Repair (2nd occurrence) | "This app couldn't be repaired. Try again later." |
| Uninstall + fresh install | the only thing that worked — both times |

So: Repair never worked, and the app reported itself as "currently running" while no process existed. That mismatch alone is worth fixing — it makes the built-in recovery path useless.

Separate issue found during recovery: a reinstall wipes the session list but not the transcripts

This is a second, independent bug and I think it is the more damaging one, because it looks like total data loss to the user.

After reinstalling, the sidebar was empty — every conversation appeared to be gone. It was not. The app keeps two things in two places:

| | location | after reinstall |
|---|---|---|
| Conversation content | C:\Users\<user>\.claude\projects\<workspace>\<id>.jsonl | intact — 36 transcripts, 183 MB, untouched |
| Sidebar index (title, dates, ordering) | %APPDATA%\Claude\claude-code-sessions\<account>\<workspace>\local_*.json | wiped |

The reinstall throws away the table of contents but keeps the book, and the app cannot rebuild its own index from transcripts it still has on disk. I had to reconstruct the local_*.json entries by hand from the transcripts to get my history back.

Request: on startup, reconcile claude-code-sessions against the existing transcripts in .claude\projects\ and regenerate any missing entries. All the data needed is already there.

Note on the installer error (probably unrelated, included for completeness)

The first reinstall initially failed twice with:

MSIX installation failed: AddPackage failed with HRESULT 0x80073CF6
ERROR dialog: Administrator access is required to install Claude with full features.

— even though the installer self-elevated correctly (Is elevated: true, Running in elevated context in the log). A reboot cleared it and the third attempt succeeded. Full ClaudeSetup.log attached; the relevant lines are 60–66, 126–132 and 192–196.

Impact

Several hours lost per occurrence, twice in one day, on a machine used for daily paid work. The failure mode is severe out of all proportion to the cause: an app should not become permanently unstartable because a website showed a captcha.

What I need

1. The crash fixed — a bot-check widget in the browser pane must not be able to kill the app, let alone leave it unlaunchable.
2. A repair path that actually works, so recovery does not require a full uninstall. Right now Repair fails with a wrong "app is running" message while no process exists.
3. Session-list recovery on startup — rebuild claude-code-sessions from the transcripts that are still on disk, so a reinstall never looks like total data loss.
4. Until it is fixed: please make the "disable Browser tools" setting more discoverable, and consider skipping the browser pane automatically when a page returns a bot-check.

Reproduced this again today (2026-08-23) on Windows. Navigating the embedded Browser pane to RogueBasin (roguebasin.com), a MediaWiki site fronted by Cloudflare, to edit a wiki page triggered the same crash-to-desktop described here. The trigger was just RogueBasin's normal "Just a moment..." Turnstile interstitial on an ordinary edit-form page load, not itch.io specifically, so this does not look tied to any one site.

Also flagging #88543 as very likely the same bug (itch.io Cloudflare challenge, same crash-to-desktop, requires reinstall to recover) in case it helps with dedup.

Workaround in the meantime: do any work on a Cloudflare-Turnstile-fronted site through a real external browser (e.g. via a Chrome-extension-based tool) instead of the embedded Browser pane.

Root cause found + fix verified (Windows 11, Claude Desktop 1.40609.0)

This is not a graphics bug. Exit code 101457950 (0x060C201E) is a Windows loader code-integrity kill, diagnosed via procdump full dump + WinDbg + the CodeIntegrity event log:

1. WebGL-probing pages (chatgpt.com, Cloudflare Turnstile, etc.) make Chromium's GPU process lazy-load vk_swiftshader.dll.
2. The GPU process runs with Code Integrity Guard (Microsoft/store-signed DLLs only). In the MSIX install, package DLLs qualify via the package catalog — but the installed package's AppxMetadata directory (including CodeIntegrity.cat) was missing on disk (AppxBlockMap/Signature/Manifest were present).
3. CodeIntegrity event 3033 — "vk_swiftshader.dll did not meet the Microsoft signing level requirements" — plus event 3010 — "unable to load ...AppxMetadata\CodeIntegrity.cat, status 0xC000003A". The loader raises non-continuable 0x060C201E (ntdll!LdrAppxHandleIntegrityFailure), killing the whole app and marking the package NeedsRemediation (hence "unlaunchable until Repair").

This explains why GPU pinning, disabling hardware acceleration, WARP, and driver updates all failed — the crash isn't in rendering. Light pages never load swiftshader, so they never crash. Crashpad/WER don't fire on loader kills, so no dumps appear.

Diagnosis tips: check Event Viewer → Applications and Services → Microsoft → Windows → CodeIntegrity → Operational for 3033/3010 pairs timestamped at each crash, and check whether C:\Program Files\WindowsApps\Claude_*\AppxMetadata\ exists.

Fix (verified): clean reinstall — winget uninstall Anthropic.Claude then winget install Anthropic.Claude. In my case the reinstall delivered the non-MSIX per-user build (%LOCALAPPDATA%\AnthropicClaude\), which has no Appx catalog dependency, so the failure path is structurally gone. Re-tested chatgpt.com/Turnstile in the browser pane: no crash (previously died within 1–35 s, 8 crashes over a week).

Open question for Anthropic: how the package's AppxMetadata dir went missing (bad staging during an MSIX update?) — if anyone else sees a fresh MSIX install without it, that's a packaging bug.

Another reproduction, plus one data point I haven't seen in this thread yet: the current MSIX build still ships the vulnerable configuration (checked 2026-08-31).

Incident (2026-08-05, two crashes ~7 minutes apart)

• Environment: Windows 11 Pro build 26100, desktop app MSIX Claude_1.25927.0.0 (CLI 2.1.144), NVIDIA GeForce RTX 3090 (driver 32.0.15.9636, 2026-04), Threadripper workstation — so neither low-spec nor integrated-GPU, consistent with the cross-hardware reports above.
• A Claude Code session opened an Espacenet patent-search URL in the in-app Browser pane (preview_start). The page returned a Cloudflare "Just a moment… Performing security verification" Turnstile interstitial (navOk: true, challenge title visible).
• get_page_text still read the challenge text cleanly. The next tool call seconds later found the preview gone (No preview is open), and the app then terminated silently — no error dialog, window just gone.
• Retrying the same URL crashed the app a second time, identically.
• Afterward the app was unlaunchable; Settings → Apps → Repair failed; a full reboot restored it (consistent with the cowork-svc.exe file-lock observation earlier in this thread).

Forensics match the code-integrity-kill diagnosis

No WER 1000/1001/1002 event and no crash dump for claude.exe around either crash — consistent with an OS loader kill rather than an unhandled exception. C:\ProgramData\Claude\Logs\cowork-service.log shows only clean service stop/start cycles; the persistent-RPC EOF marks the exact moments the host app died, while the Cowork VM side stayed healthy throughout:

(timestamps normalized to UTC; user path and SID redacted)
2026/08/05 12:18:56 [Server] Client signature verified: ...\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc\app\claude.exe (subject: Anthropic, PBC)
2026/08/05 12:18:56 [Server] Created new VM session for <redacted>
2026/08/05 12:31:02 [Server] Persistent RPC: connection ended: failed to read length: EOF   <-- app death #1
2026/08/05 12:31:18 Service stop requested / Shutdown signal received / Server stopped      (clean, no fault)
2026/08/05 12:34:48 [Server] Client connected                                               (app relaunched, same URL retried)
2026/08/05 12:38:01 [Server] Persistent RPC: connection ended: failed to read length: EOF   <-- app death #2
2026/08/05 12:38:13 Service stop requested / Shutdown signal received / Server stopped      (clean, no fault)

No error, panic, or stack trace anywhere in that log for the whole month — i.e. the Hyper-V/Cowork VM layer is a healthy bystander; the death is in the host app.

Current build still vulnerable (checked 2026-08-31)

Claude_1.40609.0.0_x64__pzs8sxrjxfjjc:

• Get-AppxPackage status: Ok
• app\vk_swiftshader.dll present (5,550,416 bytes)
• no AppxMetadata directory in the package at all (hence no CodeIntegrity.cat)

That matches the root cause isolated in the comments above (Turnstile's GPU/WebGL probing → lazy-load of vk_swiftshader.dll → Code Integrity kill 0x060C201E → Electron shell dies → package flagged NeedsRemediation). Since 2026-08-05 the machine has run the Browser pane regularly with zero crashes — but only because bot-gated sites are now explicitly avoided in it, which is mitigation, not resolution.

Getting the same error here.

Identified the trigger: it happened when trying to open Cloudflare in Claude's in-app browser. It was working fine before that. Feels like a regression.

Windows 10.0.19045, Claude Desktop MSIX 1.40609.0.

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

Same text reported in this issue.

Confirming this on a separate machine/setup — same crash pattern, reproducible.

Setup:

• Windows 11 Pro, Claude Desktop 1.40609.0
• Project: Astro site deployed on Cloudflare Pages, with a Cloudflare Turnstile widget embedded in a booking form
• Crash reproduces specifically when the internal Preview pane navigates to the route containing the Turnstile widget. Other routes without Turnstile preview fine.

Log signature from main.log:

[Preview] Starting server / Spawning process
[PreviewContext] Load failed, retry   (repeats ~4x)
[Preview] Server ready (HTTP responding)
[error] [Preview] navigatePreview failed
[warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }

Shortly after (within ~1 min), conhost.exe gets an Application Hang (event 1002) and the whole app restarts — matching the "app becomes unlaunchable" behavior described in the issue.

Workaround that's working for us: avoid letting the internal preview navigate to any route containing Turnstile — open the local dev URL in an external browser instead, and instruct Claude via CLAUDE.md to verify dev-server readiness with a plain curl status check rather than using the internal preview tool on that route.

Happy to share full logs if it helps with triage.