[BUG] Windows: in-app browser hangs on Cloudflare interstitial and loses the preview pane ("No preview is open")

Status Closed — duplicate
Maintainer reply None cached
Activity 1 comment · opened Aug 20, 2026 · closed Aug 25, 2026

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

  1. preview_start with { url: "https://www.tandfonline.com/toc/hsem20/29/5" }

(any Cloudflare-challenged host reproduces; https://journals.sagepub.com/editorial-board/EPM
also does).

  1. Observe navOk: true in the return value.
  2. Call get_page_text — it returns the "Just a moment… / Performing security verification"

interstitial rather than page content.

  1. Call get_page_text again — it now fails with No 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_start with {url} returns navOk:true but 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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗