[BUG] Claude in Chrome MCP `navigate` prepends `https://` to `file://` URLs → chrome-error (same class as #19911)

Summary

The Claude-in-Chrome MCP navigate tool (and the navigate action inside browser_batch) unconditionally prepends https:// to any URL that doesn't already start with http. For file:// URLs this corrupts the scheme: file:///path becomes https://file:///path, which Chrome normalizes to https://file///path and loads as chrome-error://chromewebdata/. As a result it is impossible to open a local file through the MCP.

This is the same root cause as the (closed/stale) #19911 — "Navigate tool corrupts chrome:// and about: URLs by prepending https://" — still present for the file:// scheme.

Repro

1. Connect the Claude-in-Chrome MCP.
2. Call navigate with { "url": "file:///Users/me/example.html" }.
3. The tool reports: Navigated to https://file:///Users/me/example.html.
4. The tab's actual URL is https://file///Users/me/example.html, and evaluating location.href in that tab returns chrome-error://chromewebdata/.

Expected

Navigate to the file:// URL as given (subject to the extension's "Allow access to file URLs" permission). Or, if file:// is intentionally unsupported, return an explicit error — not silently rewrite the scheme into a broken https:// URL.

Actual

| input url | tool reports | tab actually loads | location.href |
|---|---|---|---|
| file:///Users/me/example.html | https://file:///Users/me/example.html | https://file///Users/me/example.html | chrome-error://chromewebdata/ |
| file://localhost/Users/me/example.html | https://file://localhost/Users/me/example.html | https://file//localhost/Users/me/example.html | chrome-error://chromewebdata/ |

browser_batch with a navigate action behaves identically (same prepend).

Workarounds attempted — all fail

• Typing into the address bar via the computer tool: keystrokes are dispatched to the page, not browser chrome. cmd+L then typing about:blank + Enter does not navigate (the page stays on its prior URL).
• window.location.assign('file://…') from a loaded https:// page: silently blocked by Chrome's web→file:// navigation restriction (expected browser security — .assign() doesn't throw, but no navigation occurs).
• Reusing a user-opened file:// tab: tabs_context_mcp only lists tabs in the MCP's own tab group; tabs the user opened themselves are not visible or controllable.
• Enabling "Allow access to file URLs" on the extension (chrome://extensions): no effect, because navigation never reaches a real file:// document in the first place.

Likely cause / suggested fix

Normalization logic resembling url.startsWith('http') ? url : 'https://' + url. Suggested fix: only default bare host/path strings to https://; leave any input that already has an explicit scheme (file:, chrome:, about:, view-source:, …) untouched. If file:// is intentionally unsupported, return a clear "unsupported scheme" error instead of producing a broken https://file///… URL that lands on chrome-error.

Impact

Blocks opening or automating any local HTML file through the MCP (e.g. reading state from a locally-generated page). The silent scheme rewrite also makes the failure mode confusing: you land on chrome-error://chromewebdata/ with a malformed https://file///… URL rather than getting a clear "unsupported scheme" message.

Environment

• Claude Code 2.1.159
• Claude for Chrome MCP — Chrome 149.0.7827.103
• macOS 26.5.1 (build 25F80)