#2706·BrowserOS

The MCP port (9010) listens on 0.0.0.0 while cdp (9110) and server (9210) are bound to 127.0.0.1

Author: happy9zhangCreated Sep 18, 2026Updated Sep 18, 2026

Environment: BrowserOS neo 0.50.5.0 · Chromium 151.0.8162.137 · Windows 10 x64.

Observation

Of the three ports in .browseros/config.json, the two internal ones are bound to loopback and the MCP one is not:

"ports": { "cdp": 9110, "proxy": 9010, "server": 9210 }

Get-NetTCPConnection -State Listen:

port role LocalAddress
9110 cdp 127.0.0.1
9210 server 127.0.0.1
9010 proxy / the MCP endpoint 0.0.0.0

Windows Firewall also has an inbound Allow rule for the BrowserClaw chrome.exe, so the host firewall is not narrowing it either.

This reads as backwards: 9010 is the one endpoint that can drive the browser — open tabs, navigate, run scripts in page context, read page content from a profile that is signed into the user's accounts — and it is the only one of the three reachable from outside the machine.

What I did not verify

I want to be precise about the limits of this report, because the name of an existing flag suggests there may already be a guard:

  • config.json contains "flags": {"allow_remote_in_mcp": false}. From the name it plausibly rejects non-loopback callers at the application layer, which would make this a defence-in-depth nit rather than a live exposure. I did not read the code and did not test it.
  • I did not test reachability from another host. I only observed the listening socket and the firewall rule. Whether a LAN peer can actually complete an MCP session against 9010 is unknown to me.

So this is "the socket is open to the network and the two sibling ports are not", not "I drove the browser from another machine".

Questions for a maintainer

  1. Is the 0.0.0.0 bind on 9010 deliberate (e.g. to support a remote/containerised client), or an oversight given 9110 and 9210 are loopback?
  2. If allow_remote_in_mcp: false is the intended guard, would binding to 127.0.0.1 when that flag is false be a reasonable belt-and-braces change? A closed socket fails safe in a way an application-layer check cannot — it also survives a future refactor that forgets the check.

Happy to run a reachability test from a second host on this network if that would be useful, or to check anything else on this install.