Remote sessions and limits

For: application developers.

Understand execution, cost and data leaving the network.

What happens in a job

• The node starts a session at Anthropic, with an agent object of its own for the definition (updated, as a new version, when the definition changes), and the job's input as the first message. The live stream shows remote session sesn_....
• Every built-in call waits at Anthropic until the job says yes: the job's pre_tool_call hooks, default-deny over harness: tools and approvals decide, exactly as for a harness. An allowed bash, read, write, edit, glob or grep call runs on the node, in the session's working directory inside the job's sandbox. A refusal reaches the agent with its reason.
• A call of one of the node's tools goes through the job's own tool path: the tenant's tool policy, the routine's list, hooks, approvals and the tool's own activity, shown in job trace like any tool call. The calls the agent makes in one turn run together and wait as a whole: while one of them waits for a person, the others that do not only read wait with it, and none of them runs when the person says no.
• The answer is the agent's last message when its turn ends.

When a node is lost

The session lives at Anthropic, and the job keeps its ID. When the node that drives it stops or disappears, another node with the agent resumes the same session, up to three times, and answers what was still open. Files only that node had are gone.

A built-in call that was allowed and has no result when the session resumes may have run, or not. A call that only reads (read, glob, grep) runs again by itself. Any other (bash, write, edit) asks first: the job waits for an approval of kind restart that names the call. Yes runs it again, after the job's hooks and approvals as usual; no, or no answer by the deadline, fails the job. A call of the node's tools never runs twice: the job made it, and the resumed session gets its answer.

This needs remote-claude-managed from this release on the node; an older one runs such a call again without asking.

Stopping

Cancelling the job, a kill switch on the agent or the tenant, or one on claude-managed as a tool, interrupts the session at Anthropic and archives it within seconds, also while the job is between segments (making a call of the node's tools). A session that fails is archived too, and its work item in the environment's queue is given back. A node that only restarts leaves the session for the next node.

Where the keys are

The plugin's harness runs in two processes. The one that talks to Anthropic (the session, its events, the tool results, the usage, and the environment's work queue) runs on the node outside the job's sandbox, with the tenant's keys in its memory. On a node with sandbox tier 1 it runs in a sandbox of its own, which reaches only Anthropic's API (or the URL the node's operator set with OZ0_REMOTE_API_URLS) and writes only its own state.

The built-in calls run in a second process, the harness's executor, inside the sandbox, with no key: the session's bash, file tools and every command they start see neither the keys nor the process that holds them (the sandbox has a process namespace of its own). The runtime hands the executor only the calls the job allowed, with the input it allowed: an executor that is asked to run anything else refuses it.

Its bash is one shell that lives through the session, so what a call leaves in it stays there, as in a terminal, and what a shell reports is the output of the session's tools (threat model). On Linux that shell's streams are sockets, so a command that opens /dev/stdout or /dev/stderr by name fails: use >&1 and >&2.

Input from outside

A job that a webhook, an event or a routine started runs outside input (see security). Since its keys stay outside the sandbox, a remote agent with bash, write or edit takes such jobs, on nodes with sandbox tier 1, like a harness agent does: the job waits for a tier-1 node and fails with NoSandboxNode when none takes it. A harness without an executor (an older version of the plugin) still keeps its keys in the sandbox's process, so such a job fails at once with RemoteOutsideShell; an agent with only read, glob and grep takes it either way.

Cost

Anthropic bills a Managed Agents session for its tokens at the model's prices and for its running time, $0.08 per session-hour, counted only while the session runs (pricing). The node reads the session's usage and list_cost and reports it on the job, as reported by the plugin remote-claude-managed, in two lines: the tokens (service claude-managed-agents, unit the model) and the running time (unit session-seconds). They count in the job's cost, its tree's, the Cost page, budgets and quotas. No call goes through the gateway, so calls stays 0.

Reports arrive every ten seconds while the session runs, and at the end of every segment. Each charges only what is new since the last one, so a session's cost is counted once however many segments, nodes or end steps it takes.

When the job's or the tenant's budget is spent, the session ends and the job fails; when a quota of the job's owner or team is spent, the session pauses and the job waits for a budget decision, then goes on: with the answers of the node's tools it was waiting for, or with a message to go on if its turn was stopped. Set max_budget_usd for a hard stop at Anthropic too.

What leaves your network

The API key and the environment key are on every node that runs the plugin, in its memory, and reach the harness's process in its request rather than its environment, as values: a remote harness sends them to its provider itself, so a binding to hosts does not apply to them. That process runs outside the job's sandbox and makes itself non-dumpable before it reads them, so other processes of the node's user cannot read its memory or its pipes either; root on the node and processes with CAP_SYS_PTRACE still can.

The session's commands run in the sandbox, where that process does not exist. Give the keys a Console workspace of their own: the API key can read every session in it.

Before a session starts or resumes, the node asks the edge whether the job may reach the provider's hosts (its harness plugin's egress:, and the API URL the node's operator set): the tenant's data rules, its rules by level and its egress list for the job's level hold here as they do for a model call through the gateway.

Every entry of the harness's egress: is checked, patterns such as *.example.com and addresses too: a pattern counts as every provider record it matches and as a provider nobody knows besides, so data rules that need a known region refuse it, and a level's egress list allows it only when the list names the same pattern. A session they refuse does not start, and the job fails with the edge's reason (RemoteProviderRefused); a node whose supervisor or edge cannot ask refuses the session too, and says to update it.

On a node with sandbox tier 1, the harness's own process reaches only the hosts of its plugin's egress: and the operator's API URL, under the same egress list for the job's level. On a node without tier 1 it runs as a plain process, which nothing holds to those hosts: a job whose level has an egress list does not start a remote session there (the edge refuses it and says to run the job on a tier-1 node), and for other jobs the check above covers the hosts the plugin names, not what the process could reach besides.

On a node without sandbox tier 1 the executor runs as a plain process of the node's user, beside the harness's: it still holds no key, but the session's commands could see the harness's process (not its memory). Jobs from outside never run there.

Limits today

• Two kinds: Claude Managed Agents, and outside A2A agents. The remote harness protocol is open, so another provider is another plugin.
• Remote agents do not delegate, and do not use Managed Agents' memory stores, skills, outcomes or MCP servers: the node's tools take MCP's place.
• Sessions of one environment share its queue: a node may pick up another session's work item and leave it, a delay of up to two seconds for that session.