Claude Desktop crashes when the Browser pane is opened at an external https URL (3/3)
Summary
Claude Desktop (Windows) terminates immediately when the built-in Browser pane is opened at an external https URL. Three occurrences, three crashes, no successes. The same pane opened against a local dev server from .claude/launch.json has been used many dozens of times in the same sessions with no crash.
Reproduction
Any of these, when the Browser pane is not already open:
mcp__Claude_Browser__preview_start { url: "https://<external-site>/login" }
mcp__Claude_Browser__navigate { url: "https://<external-site>/login" }The tool call returns successfully — navOk: true, a serverId and a tabId — and the pane reportedly opens. The app then dies before any follow-up call (read_page, javascript_tool, computer) can execute.
Occurrences
| Date | Tool | Result |
|---|---|---|
| 2026-08-28 | preview_start { url } | crash |
| 2026-08-28 | preview_start { url } | crash |
| 2026-08-31 | navigate { url } | crash |
All three targeted a real, public, Cloudflare-fronted https site. The 2026-08-31 case is what establishes the variable: it used a different tool, so the common factor is opening the pane at an external site, not one tool's parameter.
What does not crash
preview_start { name: "<entry from .claude/launch.json>" } against http://localhost:<port>. Used repeatedly across the same sessions, including in the session that crashed minutes earlier, with no incident.
Environment
- Claude Desktop on Windows 11 Pro 10.0.26200
- Claude Code within the Claude Agent SDK
- Model: Opus 5
Impact
The crash loses the session's place mid-task. It is also unusually hard to learn from, because the tool call reports success — the failure looks like it happened after a completed navigation rather than being caused by it.
Workaround
Use the Claude-in-Chrome MCP for external sites, which drives a real Chrome instance and does not touch the pane. For checks that only need the served bytes, curl avoids a browser entirely.