Every browser, command, file, and desktop operation an agent performs names its target machine explicitly with a computerId. This is not a UI convention: it is enforced in the tool layer, and a call without a valid, authorized target fails. Tools never fall back to the local machine, the "active" computer, or any other machine.
The three orthogonal dimensions
Choosing where work runs involves three independent decisions. None of them implies another:
| Dimension | Choice | What it does not mean |
|---|---|---|
| Where the agent runtime lives | local or cloud | Does not decide which machine each tool call touches. |
| Tool execution target | a required computerId |
Not an IP address, user ID, session ID, or proxy client ID. |
| Network egress | direct or a selected client proxy | Does not move the runtime or grant control of the client machine. |
A browser can run on machine A and exit through machine B's network — two separate, individually authorized choices. If you don't need a tunnel, the default direct egress still follows the executing machine's own routing. Once a client proxy is selected, the egress choice is fail-closed: if the tunnel is unreachable, the call fails rather than silently falling back to direct, and switching egress is an explicit lifecycle change rather than a UI toggle that leaves the old tunnel in use.
What happens on every call
OS-level tools (shell, file read/write/list/delete, browser navigate/snapshot/tabs, desktop actions) are wrapped by a middleware layer before the model ever sees them. The wrapper enforces target discipline:
computerIdmissing → explicit error naming the operation. The layer refuses to guess a target, and the underlying tool is not called.computerId: "local"→ the call goes straight to the local implementation, with no routing overhead.- Any other
computerId→ the router resolves the computer, checks it exists and is online, verifies ownership, and dispatches to the matching provider (Docker, Windows, or the device daemon for enrolled machines). The tool layer separately verifies that the computer declares the capability the tool needs — a desktop action on a machine without desktop control fails with a capability error.
Router decisions
computerId |
Path | Overhead |
|---|---|---|
"local" |
Direct to the local provider | none |
| UUID (docker/windows/enrolled) | Registry → online check → capability check → provider | ~5 ms (plus network RTT for enrolled) |
| empty / missing | Rejected with an error that names the tool | none |
A call fails explicitly when:
- the
computerIdis missing or empty, - the computer does not exist, is destroyed/revoked, or is offline,
- the computer's type has no registered provider,
- the account making the call does not own the computer,
- or the computer lacks the capability the tool requires.
Every one of these is a typed error with the reason attached — a missing capability error carries both the required and the available capability sets. None of them retries against a different machine.
Two-layer authorization
The target is re-authorized twice: once in the control plane when the call is routed, and again on the target node when the device daemon receives the method. The model's parameters are never trusted on their own — the daemon checks the declared capability for the requested method and rejects out-of-capability operations explicitly.
Handles stay with their computer
Session, tab, terminal, and other resource handles are bound to the computer they were created on. A handle from machine A does not resolve on machine B; tabId values are validated to belong to the session they're used with, and cross-task handle access is rejected. Handles are not bearer tokens that work anywhere.
Audit
Browser tool calls are audited before they execute. Each call emits one structured record naming the tool family, the action, the target computerId, and the session/tab handles involved, with a millisecond timestamp:
{ "tool": "browser", "action": "navigate", "computerId": "…", "sessionId": "…", "tabId": "…", "at": 1760000000000 }The record goes to an audit sink — a structured log line on stderr by default — and the sink is pluggable, so a deployment can route tool audit wherever it collects logs.
Scope
The computerId authorization surface covers OS-level tools only: file operations, browser operations, command execution, and native desktop actions. MCP servers and plugin-market tools are not bound to computerId — they are extensions you installed and trusted yourself, not agent-driven machine operations.
For the computers themselves — provisioning, enrollment, and lifecycle — see Cloud Computers. Browser sessions and tab management build on this routing and are covered in Browser Sessions.