[BUG] Claude Desktop (Windows) terminates entirely when the built-in browser loads a page serving a JavaScript bot-protection challenge

Preflight Checklist

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

What's Wrong?

When the built-in browser pane navigates to a page that serves an interstitial JavaScript bot-protection challenge (the "Checking your browser…" type — a CDN/WAF challenge), the entire Claude Desktop application terminates. Not just the browser pane: the whole app disappears.

There is no error dialog and no crash-reporter prompt. The application simply closes.

Recovery is not automatic: relaunching does nothing until the app is repaired from Windows Settings → Apps → Installed apps → Claude → Repair. All in-progress work in the conversation is lost.

This happened 3 times over two days, always at the exact same step — the moment the browser tool is asked to open such a page.

Important nuance — a CDN alone is not the trigger. Sites served through the same CDN in standard proxy mode (no challenge) were opened dozens of times in the same session with zero problems. The crash only occurs on pages that actually execute an interstitial challenge script. The trigger therefore appears to be the execution of that script inside the embedded renderer, not CDN-fronted sites in general.

What Should Happen?

The browser pane should fail gracefully — an error state, a blank page, or a "cannot load this page" message — and never terminate the host application.

A failure inside the embedded renderer should stay isolated from the main process, exactly as a crashed tab does not close a normal browser.

At minimum, the application should survive and remain usable, so the conversation and its in-progress work are not lost.

Error Messages/Logs

No error message is shown and no crash reporter appears — the application closes silently.

Windows Event Viewer may hold an application-error entry at the time of the crash; I can provide it on request.

Steps to Reproduce

1. Open Claude Desktop on Windows.
2. Ask Claude to open, in the built-in browser, any public web page protected by an active JavaScript bot-protection challenge.

• Reliable way to identify such a page without naming one: a plain curl request to it returns HTTP 403, while a real browser is allowed through after executing the challenge script. Many large e-commerce and marketplace sites behave this way.

1. Claude calls the browser tool (preview_start / navigate) with that URL.
2. The entire application closes — no dialog, no crash report.
3. Relaunching Claude Desktop is not enough: it must be repaired from Windows Settings → Apps → Installed apps → Claude → Repair.

Control test that isolates the cause:

• Opening pages served through the same CDN in standard proxy mode (no challenge) works perfectly, repeatedly, in the same session.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

Unknown — no earlier version was tested against this specific case.

Claude Code Version

2.1.234 (Claude Desktop for Windows, app version 1.32885.1.0)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment details

• Claude Desktop for Windows, app version 1.32885.1.0
• Bundled Claude Code: 2.1.234
• Windows 11 Pro, build 10.0.26200.9168

Impact

• Complete loss of in-progress work in the conversation, every single time.
• Requires a manual OS-level "Repair" of the application to recover — relaunching alone does not work.
• JavaScript bot-protection challenges are extremely common on the public web, so this is easy to hit by accident during ordinary browsing tasks. It is not an exotic edge case.

Current workaround
Restricting the assistant to a strict allowlist of domains it may open in the built-in browser, and using server-side curl for everything else. Effective, but it is a behavioural rule rather than a technical guarantee, and it silently removes a useful capability.

Suggested fix
Isolate the browser pane's renderer process so that a failure inside it cannot terminate the main application process.