[BUG] Windows: preview_start with {url} returns navOk:true but tab is empty; downstream tools error "No site is open in this tab"

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?

preview_start reports success (returns navOk:true) but the tab is
actually empty. Every downstream tool call against the returned tabId
fails with the same error:

No site is open in this tab. Use navigate first.

Affected tools:

• resize_window({ preset: "desktop" })
• read_page({ filter: "interactive" })
• computer({ action: "screenshot" })

The tool's own navOk:true flag is inconsistent with the downstream tools'
observation that the tab has no site loaded. Either preview_start should
have failed loudly instead of returning navOk:true, or the URL should
have actually loaded in the tab.

Verified the server is fine: curl to the same localhost URL returns 200
with valid HTML, and the same URL renders instantly in real Chrome via
the claude-in-chrome extension. Only the built-in Browser pane fails to
render localhost.

Public URLs (Vercel previews, external sites) render fine in this pane —
the issue is specific to localhost:* URLs on Windows.

What Should Happen?

Either:

(a) preview_start with { url: "http://localhost:*" } actually loads the
URL in the created tab, so downstream tools (resize_window, read_page,
computer/screenshot) can interact with the running page — same as
they can for public URLs (Vercel previews, external sites), which
work fine.

OR, if there's a real reason localhost URLs cannot be loaded on Windows:

(b) preview_start should return navOk:false (or throw) with a clear
error message indicating navigation failed, rather than reporting
navOk:true and leaving downstream tool calls to discover the empty
tab via cryptic "No site is open in this tab. Use navigate first"
errors.

Error Messages/Logs

preview_start return value:
  {
    "serverId": "preview-local_f3b4a705-...",
    "tabId": "seed",
    "reused": false,
    "type": "browser",
    "navOk": true
  }

resize_window({ tabId: "seed", preset: "desktop" }):
  No site is open in this tab. Use navigate first.

read_page({ tabId: "seed", filter: "interactive" }):
  No site is open in this tab. Use navigate first.

computer({ tabId: "seed", action: "screenshot" }):
  No site is open in this tab. Use navigate first.

Steps to Reproduce

1. Have any local dev server that serves a normal HTML page on localhost.

For example, in a Next.js project directory:
npm run dev
(Start it in a background shell so it stays running.)

1. Confirm the server is actually up and serving. From the same terminal:

curl -o /dev/null -w "%{http_code}\n" http://localhost:3000
Expect: 200 (or 307/308 for redirects — anything except a connection error).

1. In the Claude Code session, call the preview_start tool with a URL:

preview_start({ url: "http://localhost:3000" })
The tool returns:
{ serverId: "preview-local_...", tabId: "seed", reused: false,
type: "browser", navOk: true }
Note navOk:true — the tool is asserting the navigation succeeded.

1. Try to interact with the tab that preview_start just created:

resize_window({ tabId: "seed", preset: "desktop" })
read_page({ tabId: "seed", filter: "interactive" })
computer({ tabId: "seed", action: "screenshot" })

1. Observe: each of the three tools errors with

"No site is open in this tab. Use navigate first."
despite preview_start having reported navOk:true in step 3.

Environment:

• Windows 11 Home Single Language 10.0.26200
• Claude Code 2.1.207
• Server-side confirmed healthy (curl 200; same URL loads in real

Chrome via the claude-in-chrome extension).

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.207 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Companion bug: preview_start with { name } instead of { url } fails
even earlier with "spawn C:\WINDOWS\System32\cmd.exe ENOENT" on the
same platform — that one is already tracked at
https://github.com/anthropics/claude-code/issues/68341 (I added a
comment there earlier confirming it's still present on 2.1.207).

The two bugs together make the built-in Browser pane unusable for
local UI verification on Windows: {name} can't spawn the dev server,
and {url} can't render localhost even when the server is already
running. Only workaround is driving the user's real Chrome via the
claude-in-chrome extension.

Environment note: server-side is healthy (curl to the same URL returns
200 with valid HTML; the same URL loads instantly in real Chrome via
the claude-in-chrome extension). Public URLs (Vercel previews, external
sites) render fine in the Browser pane — the issue is specific to
localhost:* URLs on Windows.