Remote access

/v1/mcp binds to 127.0.0.1, which is exactly right for Claude Code, Cursor and Codex and useless for a chat service running in a browser tab. Remote access closes that, without the browser moving anywhere.

The browser stays on your machine, with its profiles and its stored logins. What travels through the cloud is the control channel, not the browser.

Which services actually work

Every row here carries how it was verified, because this landscape moves faster than the code does. A line from a vendor's own documentation and a run against the real interface with a real account are very different kinds of evidence, and only the second has ever found a defect.

Setting it up

Three places, in this order. Skipping the second is the usual reason a connection fails with a message that explains nothing.

1. 1
   Create a connection in the portal

   Go to Settings, Connectors and create one. You get an address of the form https://mcp.scalebrowser.net/c/<id>, and it belongs to one machine.

   There is also one address for every machine: https://mcp.scalebrowser.net/mcp. Paste it into the chat service instead, and when you sign in, Scalebrowser asks which of your machines the service should use. That choice creates the connection, so you skip this step. It needs the desktop app 0.25.0 or newer on that machine. Your machine learns about a new connection within a minute, so the very first sign-in can end with a temporary error from the chat service. Connect again a minute later and it goes through.

   Choose the scope here. A read-only connection sees no mutating tool in its listing and is refused if it calls one anyway, for the same reason the daemon's own read-only mode does both.

2. 2
   Turn remote access on, on the machine

   In the management app: Settings, General, Remote access. It is off out of the box.

   The switch is local on purpose. If the portal could open a tunnel into your machine, the trust boundary this whole product is built around would be gone. The daemon asks its own switch on every beat rather than at startup, so turning it on takes effect without a restart.

3. 3
   Add the address in the chat service

   Paste the address into the service's custom-connector dialog. Everything else is discovery: the service finds the authorization and token endpoints itself, registers itself, and sends you through a sign-in and a consent screen that names where you will be sent back to.

   No token is typed anywhere.

Two things Claude does that will confuse you

Both are client behaviour rather than ours, and both look like a broken server.

Every tool name is prefixed. profile_list appears as Scalebrowser:profile_list.

A tool search runs before the call. With a large catalog it surfaces only part of it, and Claude answered "there is no such tool" three times for tools it listed in full seconds later. The fully prefixed name works immediately. Serving fewer tool profiles makes this rarer.

The six rules behind it

Worth knowing, because they are what makes a relay in somebody else's cloud acceptable at all.

The relay has no authority. It checks no access token, reads no request body, and decides nothing about whether a tool may run. Your token passes through it unchanged to your daemon. A compromised relay can therefore see bytes and drop them; it cannot invent a command.

Your daemon's static token does not work through the tunnel. Two branches decide which credential counts, and the deciding input is where the request came from: loopback and stdio take the static token, the tunnel takes an OAuth token and nothing else. The static token is not rejected in the tunnel, it is never compared, because a comparison that does not exist cannot be accidentally loosened.

A token is bound to one connection's address. The connection's own URL rides in the token as a resource indicator, and the daemon compares it against the connections that belong to it. A token minted for your office machine is cryptographically useless on your laptop.

One path is allowed through, and the daemon decides that. Not the relay: a defence belongs somewhere the attacker does not own. The tunnel speaks ordinary HTTP inside and could carry any path; exactly one is served.

Off by default, and the switch is on the machine. A local product does not open a remote door because somebody installed it.

No subscription, no tunnel. Asked twice: once when the connection is established, once by the daemon while it is open. A tunnel lasts days and a subscription can end in the middle of one, so checking only at connect time would keep serving after the subscription ended, until something happened to break the connection.

What the relay stores

No body, no headers, no address of any page visited. Two numbers: when a call last came through, and how many there have been.

TLS terminates at the relay, so it can see bytes in transit. That is the honest cost of not requiring you to run your own tunnel, and it is why the relay is built to have no authority over anything. If you would rather it did not exist, point your own tunnel at your daemon; the authentication path is identical.

Revoking

Revoking a connection in the portal does two things: it disables the connection so no new token can be issued, and it tells the relay to cut the tunnel immediately.

An access token already issued keeps working for at most ten minutes. After that, and after any daemon restart, the connection is gone for good.

Next

• MCP server: the tools that reach through this tunnel.
• Which clients work: the local clients, which need none of this.
• Machines & sign-in: why a connection belongs to one machine.