Browser pane can no longer navigate to file:// URLs (worked earlier in the same session, then started failing)

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?

In a single Claude Code session, the Browser pane tool's navigate action successfully opened a local file:// HTML file (a static single-file app, no dev server) repeatedly across many turns — real screenshots, real click/keyboard interaction, all working.

Partway through the same session (no code change on my end, no explicit action by me that I'm aware of), navigate calls to that same file:// URL started failing consistently with:

couldn't open file:///C:/Users/.../app/foo.html — the file may be missing, unreadable, or the user declined access

The file itself was confirmed present, unchanged, and readable via the filesystem the entire time (verified with PowerShell Test-Path/Get-Item). This happened on the pre-existing tab and on freshly created tabs alike.

Separately, I tried the Claude-in-Chrome integration (connected to my real, already-logged-in Chrome) as a workaround. Its navigate action fails differently on non-http(s) URLs: it appears to unconditionally force-prepend https:// onto any URL that doesn't already start with http, producing a malformed URL. I confirmed this isn't file://-specific by also testing chrome://extensions, which became https://chrome://extensions the same way — so this looks like a general URL-scheme handling bug in that tool's navigate, not something specific to local files.

I could not find an existing report of this specific symptom (searched for the exact error text and for file:///browser preview + regression terms — see #86577 for a related-looking but distinct issue in the same general subsystem: that one is about the Browser preview auto-opening and crashing the renderer on HTML edits, MSIX desktop app; mine is the CLI's Browser pane tool cleanly failing to navigate, no crash, rest of the app/session unaffected throughout).

What Should Happen?

navigate should keep opening file:// URLs reliably for the whole session, the same way it did at the start — or, if there's a deliberate reason file:// access can be revoked mid-session, the tool should say so clearly instead of returning "the file may be missing, unreadable, or the user declined access" (a misleading message when none of those three things are true).

Separately: navigate should not mutate a URL's scheme. If https:// really is meant to be the fallback for a bare host/path with no scheme at all, that's fine — but a string that already has an explicit non-http scheme (file://, chrome://, etc.) should never get https:// prepended onto it.

Error Messages/Logs

Browser pane (mcp__Claude_Browser__navigate):
couldn't open file:///C:/Users/USER/Desktop/AI/Claude SnC/app/snc-dashboard.html — the file may be missing, unreadable, or the user declined access

Same error on preview_start with the same URL, and on a freshly created blank tab, not just the tab that had previously loaded it successfully.

Claude-in-Chrome (mcp__claude-in-chrome__navigate), tried as a workaround:
Navigated to https://file:///C:/Users/USER/Desktop/AI/Claude SnC/app/snc-dashboard.html
(note the malformed "https://file://" — the tool prepended https:// onto a URL that already had an explicit file:// scheme)

Confirmed the same scheme-mangling on an unrelated URL, to rule out anything file-specific:
navigate({url: "chrome://extensions"}) -> "Navigated to https://chrome://extensions"

Steps to Reproduce

This is hard to reproduce on demand since the failure appeared mid-session with no obvious trigger. What I can describe reliably:

1. Start a Claude Code session with the Browser pane available (mcp__Claude_Browser__* tools).
2. Have Claude repeatedly navigate the Browser pane to a local file:// URL (a static single-file HTML app on disk, no dev server) across many turns — this worked correctly and repeatedly for a good portion of the session (real screenshots, real page interaction via computer/javascript_tool actions).
3. At some point later in the same session, navigate to that exact same file:// URL (no changes to the file, confirmed via filesystem check) starts failing every time with "the file may be missing, unreadable, or the user declined access."
4. From that point on, every subsequent navigate attempt to any file:// URL fails the same way, including on brand new tabs created with preview_start/tabs_create — it never recovers for the rest of the session.
5. Non-file:// URLs (https://example.com etc.) continue to work fine in the Browser pane the whole time, both before and after the file:// failures start — this is not a general tool outage.

Separately reproducible on demand (not intermittent):

1. Connect Claude-in-Chrome to a real, already-logged-in Chrome instance.
2. Call navigate with a url that has an explicit non-http(s) scheme, e.g. "file:///C:/some/path.html" or "chrome://extensions".
3. Observe the tool's own response text prepends "https://" onto the URL regardless (e.g. "Navigated to https://chrome://extensions"), producing a URL that can't actually resolve to the intended destination.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Earlier in the same session (no version number available — see notes below)

Claude Code Version

Unknown — claude --version was not a recognized command in this environment (PowerShell or Bash), so I could not read it from inside the session. See Additional Information.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related issue, not a duplicate: #86577 describes a different symptom in what looks like the same general subsystem (Browser preview auto-opening and crashing the main renderer on HTML file edits, Windows/MSIX desktop app). What I'm reporting here is the CLI's Browser pane navigate tool cleanly failing to reach file:// URLs — no crash, nothing else in the session affected, the tool just returns an error and stops working for that scheme for the rest of the session. Flagging in case they're related at the code level even though the visible symptoms differ.

Note on the "latest version" checkbox above: I ticked it because the form requires it, but I could not actually confirm this — claude --version and claude were both "not recognized" in both PowerShell and the Bash tool available to me in this environment, so I have no reliable way to read my own version string from inside the session. Not claiming it's out of date, just that I couldn't verify either way.

Also could not fill in "Claude Code Version" above for the same reason — leaving it blank/noting "unknown" rather than guessing.