---
title: "Remote access"
description: "Reach the MCP server from a chat service that runs in someone else's cloud: which services actually work, how to set a connection up, and the six rules that keep the relay from being a way into your machine."
canonical: "https://scalebrowser.net/docs/agents/remote"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://scalebrowser.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Remote access

> Reach the MCP server from a chat service that runs in someone else's cloud: which services actually work, how to set a connection up, and the six rules that keep the relay from being a way into your machine.

`/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.

| Service                                     | Works                          | Verified                                                        |
| ------------------------------------------- | ------------------------------ | ----------------------------------------------------------------- |
| Claude on the web, desktop, mobile          | yes                            | Driven end to end, tool call answered                            |
| Claude Code                                 | yes                            | Vendor documentation                                             |
| Grok                                        | yes                            | Driven end to end, tool call answered with an unguessable value  |
| ChatGPT                                     | Business, Enterprise and Edu only | Driven on a Plus account: the developer-mode switch does not exist there |
| Gemini Enterprise, Gemini CLI               | yes                            | Vendor documentation                                             |
| Gemini Spark                                | inside Spark tasks only        | Vendor documentation                                             |
| Gemini consumer app                         | no                             | Takes only connectors Google has a partnership for               |
| Mistral, now "Vibe"                         | no                             | Driven: the connect button has no effect, nothing reaches our server |

<Note>

**The ChatGPT and Mistral rows are about them, not about us.** On ChatGPT Plus all seventeen settings tabs were checked in two languages and the developer mode is simply absent. On Mistral, our metadata is found and their own dialog switches itself to OAuth 2.1, and then the button does nothing; nothing arrives on our side at all.

</Note>

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

<Steps>

<Step title="Create a connection in the portal">

Go to [Settings, Connectors](/settings/connectors) and create one. You get an address of the form `https://mcp.scalebrowser.net/c/<id>`, and it belongs to **one machine**.

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.

</Step>

<Step title="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.

</Step>

<Step title="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.

</Step>

</Steps>

## 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](/docs/agents/mcp-server): the tools that reach through this tunnel.
- [Which clients work](/docs/agents/mcp-clients): the local clients, which need none of this.
- [Machines & sign-in](/docs/account/machines): why a connection belongs to one machine.