Windows desktop app crashes (RADAR_PRE_LEAK_64) when using built-in browser feature

Reproduced identically on a brand-new machine (32GB RAM), whereas the original machine had only ~11.68GB usable. This rules out memory pressure as a root cause — it's a code-level bug in the browser/instance-launch logic, not something triggered by resource constraints.

New-machine main.log shows the same signature as before:

second-instance: suppressing duplicate argv
Not main instance, returning early from app ready
[warn] event-loop-stall: main process blocked for 2208ms
tree_rss_sum=1634MB

Additional finding: killing claude.exe (and any chrome-native-host.exe) via Task Manager does not resolve the issue — the app remains stuck in the same broken state on next launch. Only a full uninstall + reinstall clears it. This points to a persistent on-disk artifact surviving process termination, not pure in-memory state. One candidate: %APPDATA%\Claude\lockfile (the Electron single-instance lock file) remains on disk after a forced kill — worth checking whether it's left in a state that makes every subsequent launch falsely detect a live "primary" instance.

Root cause isolated: Cloudflare Turnstile

Ran a controlled A/B isolation test on a live site (firearmsalefinder.com) that reliably reproduces this crash, toggling two third-party scripts independently across 4 deploys:

| Impact Publisher Tag | Cloudflare Turnstile | Result |
|---|---|---|
| off | on | crash |
| off | off | survived |
| on | off | survived |
| off | on | crash (repeat, direct confirmation) |

Turnstile presence correlates 100% with the crash; the Impact Publisher Tag does not reproduce it under any configuration.

Hypothesis: Turnstile's behavioral input fingerprinting (used for its bot-detection challenge) hooks into keyboard/mouse timing to distinguish human from automated input. The built-in browser pane's synthetic keystroke injection doesn't match expected human timing patterns, and this appears to trigger the crash rather than a normal bot-challenge response.

Not a memory/hardware issue: reproduced identically on two separate machines — one with 11.68GB RAM, one with a fresh 32GB build.

Reproduction script: load challenges.cloudflare.com/turnstile/v0/api.js on a page, then type quickly into any text input via the built-in browser pane's automated input.

Update: workaround deployed, confirmed non-crashing

Replaced Cloudflare Turnstile with Google reCAPTCHA v3 on firearmsalefinder.com (invisible/score-based, no widget, no behavioral keystroke fingerprinting the way Turnstile does it).

Re-ran the same reproduction steps that reliably crashed the browser pane 4/4 times with Turnstile present: loaded the live site, clicked into a text input, and typed two rapid bursts (44 and 72 characters, including symbols) via the built-in browser pane's automated input.

Result: no crash. Page stayed fully responsive, input value persisted correctly, JS execution and the accessibility tree both confirmed a healthy page state throughout.

This confirms the fix is specifically avoiding Turnstile's behavioral bot-detection script — not a change to typing speed/pattern, dataset size, or anything else on the page. Leaving this issue open since the underlying incompatibility between Turnstile's input fingerprinting and the browser pane's synthetic keystroke injection is still a real bug worth the Claude Code team investigating, even though we've worked around it on our end.

New data point: crash reproduced on a completely unrelated third-party site

While manually verifying some false-positive results from an automated link-checker (unrelated to firearmsalefinder.com itself), I loaded palmettostatearmory.com — a large firearms/ammo retailer, no relation to our own site or its Turnstile/reCAPTCHA setup — in the built-in browser pane to check a single product page. The app crashed and required a full uninstall/reinstall, same signature as the original report.

Why this matters: this is the first crash we've seen on a domain that has nothing to do with firearmsalefinder.com. It suggests the underlying issue may not be specific to our site's (now-removed) Cloudflare Turnstile integration, but could be a more general browser-pane vulnerability triggered by bot-detection/behavioral-fingerprinting scripts on arbitrary third-party sites. Circumstantially consistent with this: palmettostatearmory.com was independently observed returning HTTP 403 to our own server-side scanner's fetch requests, consistent with it running some form of aggressive WAF/bot-protection (Cloudflare or similar) — the same category of technology implicated in the original Turnstile finding.

We have not attempted to reproduce this further given the cost of each crash (full reinstall), so this is a single data point, not a confirmed isolation. Flagging in case it's useful for narrowing the actual trigger condition (e.g., testing whether it's Cloudflare specifically, vs. bot-detection scripts more broadly, vs. something else these sites have in common).