[FEATURE] Browser automation (Claude in Chrome) can't target a browser on the same host as the shell/dev tools

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's shell tools and the claude-in-chrome browser automation can be connected to DIFFERENT machines, with no way to point browser automation at a browser on the host where the shell/dev environment runs. This breaks the build -> run local dev server -> open it in a browser to verify loop.

Concretely: my Bash/PowerShell tools run on a Windows dev box (machine A), while claude-in-chrome drives Chrome on a Mac (machine B). A dev server the agent starts listens on 127.0.0.1:PORT of machine A. The only browser the agent can drive is on machine B, whose 127.0.0.1 is a different host, so navigating it to http://127.0.0.1:PORT fails (ERR_CONNECTION_REFUSED) even though the server is up and reachable from machine A's shell. The agent cannot open or observe the app it just built.

It also invites misdiagnosis: it looks like a sandboxed browser that cannot reach localhost, when it is really a different physical machine.

Proposed Solution

Any one of these would help:

1. Let the agent launch and drive a browser ON THE SAME HOST as the shell tools (headed/headless Chrome via CDP on the dev machine), independent of where the Claude-in-Chrome extension is installed.
2. When multiple browsers/hosts are connected, let the user/agent SELECT which one browser automation targets.
3. Support a loopback/tunnel so the controlled browser can reach the shell host's 127.0.0.1.
4. At minimum, EXPOSE which machine the browser is on in the tool context so agents do not misdiagnose connectivity.

Alternative Solutions

Current workarounds, all clumsy:

• Bind the dev server to 0.0.0.0 and navigate machine B's browser to machine A's LAN IP: a security regression, not always routable.
• Build a serverless harness on a public page (e.g. example.com) injecting CDN assets to mock the UI: does not exercise the real running app.
• Screen-capture machine A via a shell script to at least see (but not control) a browser opened there.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

1. Agent edits a web app on a Windows dev box and starts the dev server on 127.0.0.1:8080.
2. Agent wants to verify the UI in a real browser (screenshot, read console, click through a flow).
3. With same-host browser control, the agent drives a Chrome on the Windows box to http://127.0.0.1:8080 and verifies end-to-end.
4. Today this is impossible: the only controllable browser is on a separate Mac, so the agent is limited to shell-only checks or LAN-exposure workarounds.

Common for cross-platform dev, remote/cloud dev hosts, WSL, Docker, and headless servers.

Additional Context

Repro: shell on a Windows host (192.168.x.x); claude-in-chrome on a Mac. navigate http://127.0.0.1:5173 -> ERR_CONNECTION_REFUSED, while curl http://127.0.0.1:5173 from the Windows shell returns 200.