[BUG] Windows: in-app browser hangs on Cloudflare interstitial and loses the preview pane ("No preview is open")
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet (nearest matches noted under Related issues below — both are distinct)
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code (Claude Desktop
1.32885.1.0, auto-updating MSIX install)
What's Wrong?
Navigating the in-app Browser pane (mcp__Claude_Browser__*) to a site that serves a
Cloudflare bot-check interstitial loads the "Just a moment… / Performing security
verification" page and never resolves. Worse, the preview pane itself is then gone:
the next tool call against it fails with
No preview is open. Use preview_start with {"url": "https://…"} to open a browser tab,
or with {"name": "…"} to start a dev server from .claude/launch.json.
This is not a tab-level error — the whole pane has to be re-created with preview_start.
In one of the two occurrences the session stalled entirely and had to be interrupted.
The trigger appears specific to the bot-check interstitial. In the same session, both
before and after the failures:
- An authenticated institutional OnBase / ASP.NET WebForms application worked perfectly,
including reading form state inside deeply nested same-origin iframes via javascript_tool.
github.com(including a React-based issue form) loaded and read normally.
So ordinary and even fairly hostile pages are fine; it is the Cloudflare challenge page
that kills the pane.
Relevant context: WebFetch returns HTTP 403 on both hosts below, so the Browser pane
is the natural fallback for these lookups — and the fallback is what dies.
What Should Happen?
Either:
(a) the interstitial resolves or renders like any other page, leaving the pane usable; or
(b) the navigation times out with a clear, catchable error — e.g. navOk: false plus a
message such as "navigation blocked by bot-check interstitial" — while leaving the preview
pane alive so the agent can navigate elsewhere and continue.
The current behaviour is the worst of both: navOk: true is reported, the page never loads,
and the pane silently disappears mid-task.
Error Messages/Logs
# Occurrence 1
preview_start { url: "https://www.tandfonline.com/toc/hsem20/29/5" }
-> { serverId: "preview-local_…", tabId: "seed", reused: false,
type: "browser", navOk: true }
get_page_text { max_chars: 6000 }
-> Title: Just a moment...
URL: https://tandfonline.com
---
www.tandfonline.com
Performing security verification
This website uses a security service to protect against malicious bots.
This page is displayed while the website verifies you are not a bot.
get_page_text { max_chars: 4000 } # immediately after
-> Error: No preview is open. Use preview_start with {"url": "https://…"} …
# Occurrence 2
tabs_create { foreground: false } -> { tabId: "tab-6" }
navigate { tabId: "tab-6", url: "https://journals.sagepub.com/editorial-board/EPM" }
-> navigated to https://journals.sagepub.com
Available tabs: tab-6: "Just a moment..." (https://journals.sagepub.com)
# session stalled here
Steps to Reproduce
preview_startwith{ url: "https://www.tandfonline.com/toc/hsem20/29/5" }
(any Cloudflare-challenged host reproduces; https://journals.sagepub.com/editorial-board/EPM
also does).
- Observe
navOk: truein the return value. - Call
get_page_text— it returns the "Just a moment… / Performing security verification"
interstitial rather than page content.
- Call
get_page_textagain — it now fails withNo preview is open.
Reproduced twice in one session, on two different Cloudflare-protected publisher domains.
Claude Model
Opus 5
Is this a regression?
Not sure / haven't tested an earlier version.
Claude Code Version
Claude Desktop 1.32885.1.0 (MSIX, x64). claude --version is not applicable — this is the
desktop app, not the npm CLI; version taken from Get-AppxPackage *Claude*.
Platform
Claude Desktop app (Windows)
Operating System
Windows 11 Home, build 10.0.26200
Terminal/Shell
PowerShell 5.1 and Git Bash (both available in-session; not implicated — the failure is
entirely within the Browser pane)
Additional Information
Related issues — checked, and I believe this is distinct:
- #76806 — "Windows:
preview_startwith{url}returnsnavOk:truebut tab is empty".
That report is the inverse case: it concerns localhost URLs and explicitly states
"Public URLs (Vercel previews, external sites) render fine in this pane". It also produces a
different error, No site is open in this tab (tab empty, pane alive), whereas here the
pane itself is gone (No preview is open).
- #85244 — "passkey/2FA step in the built-in browser hangs the entire app". Same family
(a hang triggered by an interstitial-style page) but a different trigger and no pane loss.
Why this matters for agent workflows: Cloudflare-protected hosts include most academic
publishers (Taylor & Francis, SAGE, Wiley, Elsevier) and a large share of commercial sites.
Because WebFetch already 403s on these, an agent doing research naturally falls back to the
Browser pane, and a single such navigation can take out the pane in the middle of an unrelated
long-running task. A recoverable error would be entirely sufficient — the pane surviving matters
much more than the challenge page actually resolving.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗