Claude Managed Agents on Sandbox0
Anthropic's new self-hosted sandbox support for Claude Managed Agents makes the runtime boundary explicit:
Claude keeps the agent loop. Your infrastructure runs the tools.
That is the part Sandbox0 is built for.
Claude Managed Agents already provides the agent harness: sessions, event streams, model calls, tool routing, context management, and recovery behavior. A self-hosted sandbox changes where filesystem and shell work happens. Instead of executing inside Anthropic-managed cloud containers, tool calls run in an environment controlled by the customer or by a managed sandbox provider.
Sandbox0 is a natural fit for that environment layer because it already provides isolated execution, persistent workspaces, sandbox lifecycle management, network policy, credential injection, and self-hosted deployment.
What Self-Hosted Sandboxes Change#
By default, a Claude Managed Agents session executes built-in filesystem and shell tools inside Anthropic-managed containers. With a self-hosted sandbox, Anthropic keeps orchestration on its side while moving tool execution into your infrastructure.
That means the execution boundary shifts:
| Responsibility | Claude Managed Agents | Sandbox0 |
|---|---|---|
| Agent loop | Yes | No |
| Model calls | Yes | No |
| Session event stream | Yes | No |
| Bash and filesystem tools | Dispatches | Executes |
| Workspace state | Coordinates | Stores |
| Network egress | Dispatches through environment | Enforces policy |
| API credentials | Should not live in agent code | Injected at egress |
| Sandbox lifecycle | Assigns work | Claims, pauses, resumes, deletes |
The important point is that self-hosting does not mean running Claude locally. Claude still handles the reasoning loop. The sandbox provider handles the hands: files, commands, packages, build steps, tests, private network access, and output files.
The Sandbox0 Architecture#
For Claude Managed Agents on Sandbox0, the architecture has three layers.
The environment worker is the bridge. It claims work from the Claude Managed Agents environment queue, creates or resumes a Sandbox0 sandbox for the session, materializes the workspace, executes tool calls, and posts results back to Claude.
Each Claude session maps to a Sandbox0 execution context:
/workspaceis backed by a Sandbox0 volume/mnt/session/outputsis reserved for final output files- shell commands execute through the sandbox process interface
- file reads and writes operate against the sandbox workspace
- network access is controlled by policy
- API credentials are injected outside the agent process
- finished or idle sessions can be paused while the workspace persists
This keeps the Claude harness and the execution substrate decoupled. Claude does not need to know how Sandbox0 schedules sandboxes. Sandbox0 does not need to reimplement the Claude agent loop.
Why Persistent Workspaces Matter#
Agent work is rarely a single command.
A coding or data agent may install dependencies, inspect a repository, run a failing test suite, edit files, retry, start a local service, produce artifacts, and wait for a human to continue the session later.
If the sandbox filesystem disappears every time the session idles, the agent has to recreate context. That is slow and unreliable.
Sandbox0 treats the workspace as durable state. Compute can be claimed, paused, resumed, or replaced while the session's useful filesystem state remains in volumes. That makes self-hosted Claude Managed Agents a better fit for long-running work:
- repository edits
- build and test loops
- data analysis notebooks
- generated reports
- package caches
- local tool state
- output archives
The sandbox is an attachment to a durable workspace, not the source of truth itself.
Keeping API Keys Out of the Sandbox#
Self-hosted execution is only useful if the agent can reach the systems it needs: GitHub, internal APIs, databases, package registries, observability backends, customer-specific SaaS APIs, and private MCP servers.
The unsafe way is to place those credentials in environment variables inside the sandbox.
That gives every agent-generated command and every compromised dependency a path to read the token directly.
Sandbox0 uses egress credential injection instead. The agent makes a normal request to the destination service. netd intercepts the outbound connection, matches it against the sandbox network policy, resolves the credential outside the sandbox, injects the required header or protocol credential, and forwards the request.
The result is the property self-hosted agents need:
The sandbox can use credentials without holding credentials.
For Claude Managed Agents, there are two separate credential boundaries:
- the Anthropic environment key belongs to the environment worker, not the sandbox
- user and service API keys belong to Sandbox0 credential sources and are injected at egress
That split matters. The environment key controls the worker flow for Claude Managed Agents. Service credentials authorize the agent's tool traffic. They should not be collapsed into one sandbox environment variable.
Network Policy Is Part of the Agent Runtime#
Once an agent can run shell commands, network access becomes part of the security model.
An agent may need to install packages or call a private API. It should not automatically get unrestricted outbound access to the internet.
Sandbox0 network policy lets the environment start from a narrow boundary:
- allow package registries when dependency installation is required
- allow source control endpoints for repository operations
- allow specific internal services for the task
- inject credentials only for approved destinations
- block unknown destinations by default
- audit tool traffic through the sandbox network layer
This is especially important for Claude Managed Agents because the model loop and the execution environment are intentionally separated. Anthropic decides when a tool should run. Sandbox0 decides where that tool can connect.
How a Session Runs#
A self-hosted Claude Managed Agents session on Sandbox0 looks like this:
- A session is created on Claude Platform with a self-hosted environment.
- Anthropic enqueues work for that environment.
- The Sandbox0 environment worker claims the work item.
- The worker creates or resumes a Sandbox0 sandbox for the session.
- The workspace volume is mounted at
/workspace. - Skills and session resources are materialized into the workspace.
- Claude dispatches filesystem and shell tool calls.
- Sandbox0 executes those calls inside the sandbox.
- Network traffic is filtered and credentials are injected at egress.
- Tool results and output files are returned to the Claude session.
- The sandbox can be paused or deleted while the workspace remains durable.
That is the clean division:
How This Differs From Sandbox0 Managed Agents#
Sandbox0 also has a Managed Agents product surface with Managed Agents documentation.
That is a related but different integration path.
Sandbox0 Managed Agents is for teams that want Sandbox0 to own the managed session API. Application code uses the official Anthropic SDK, points it at the Sandbox0 Managed Agents endpoint, and lets Sandbox0 route the session to the selected agent harness.
Claude Managed Agents on Sandbox0 is for teams that want to keep Claude Platform as the managed agent control plane, but move filesystem and shell execution into Sandbox0-managed sandboxes.
| Question | Sandbox0 Managed Agents | Claude Managed Agents on Sandbox0 |
|---|---|---|
| API control plane | Sandbox0 Managed Agents API | Anthropic Claude Platform |
| Client SDK endpoint | https://agents.sandbox0.ai | Anthropic Claude API |
| Session and event truth | Sandbox0 | Anthropic |
| Agent loop | Selected Sandbox0 agent harness | Claude Managed Agents |
| Sandbox role | Runtime host or tool target, depending on harness | Self-hosted execution provider |
| Model credentials | Stored in Sandbox0 vaults | Managed through the Claude Platform session path |
| Service credentials for tools | Sandbox0 vaults and egress injection | Sandbox0 vaults and egress injection |
| Best fit | You want Sandbox0 to provide the managed-agents backend | You want Claude Managed Agents with Sandbox0-controlled execution |
Both paths use the same underlying Sandbox0 primitives: sandboxes, volumes, network policy, credential injection, snapshots, and runtime observability. The difference is which control plane owns the session.
Why Sandbox0 Is a Good Provider Boundary#
The self-hosted sandbox contract is about operational control:
- where files live
- how sandboxes start and stop
- how workspace state persists
- what network destinations are allowed
- how credentials are injected
- how execution is observed
- how the data plane can be self-hosted
Those are Sandbox0's core responsibilities.
For teams evaluating Claude Managed Agents, Sandbox0 gives the execution layer a shape that can be deployed close to the systems the agent needs to touch. That can be a cloud region, a private Kubernetes cluster, or an environment with stricter data and network boundaries.
The agent loop stays managed. The execution perimeter becomes yours.