Choosing an agent environment
Decide whether Claude Managed Agents tools and code run in an Anthropic-managed cloud environment or a self-hosted sandbox, and see what changes if you switch.
An environment sets where your agent's tools and code run. They run in a sandbox. A sandbox is an isolated workspace, such as a container, where the agent runs commands and works on files. You have two options:
- Cloud environment: Anthropic runs the sandbox for you. Each session gets its own fresh Linux container on Anthropic-managed infrastructure, with common languages, databases, and utilities already installed. You choose its network rules and any extra packages to install.
- Self-hosted sandbox: You run the sandbox on your own infrastructure. Claude still runs on Anthropic's side and decides which tool to call next. A program that you run, called a worker, carries out the agent's bash and file tool calls on your machines and sends each result back. It can also serve custom tools.
The agent definition is the same whichever you choose. You set the model, prompt, and tools on the agent, not on the environment.
Start with a cloud environment
If you're not sure which to choose, or you're new to Claude Managed Agents, start with a cloud environment, as the quickstart does. Anthropic runs an isolated container for each session, with common languages and tools already installed, so there is nothing for you to host. Choose a self-hosted sandbox only if tools must run on infrastructure you control.
Compare the options
The table compares the two options.
| Cloud environment (default) | Self-hosted sandbox | |
|---|---|---|
| Where tools and code run | An Anthropic-managed sandbox | Your worker, on your infrastructure |
| What reaches Anthropic | The conversation history, tool results, the sandbox's files and state, skills, and memory stores | The conversation history, tool results, skills, and memory stores. The sandbox's files and processes stay on your worker. |
| What you operate | Nothing | The worker hosts, their hardening, their network limits, and the environment key your worker authenticates with |
| Network reach | Network rules you set on the environment | Your own network policy |
| File and GitHub repository mounting | Managed by Anthropic | Managed by you |
| Memory stores | Mounted by Anthropic at /mnt/memory/ | Downloaded to /mnt/memory/ and synced by the worker |
| Sandbox lifecycle | Managed by Anthropic | Managed by you |
| Choose it when | The default. You don't need tools to run on your own infrastructure. | Tools must run on infrastructure you control. |
When to choose a self-hosted sandbox
A self-hosted sandbox fits when the agent needs to do one of the following:
- Work on data that can't leave your network: The agent's files and processes stay on your worker. What a tool returns to the model still reaches the Managed Agents service.
- Reach internal services that aren't publicly routable: The agent's bash and file tools, and any custom tools your worker serves, run inside your network. Anthropic, not your worker, connects to the agent's MCP servers. A private one might be in front of your internal ticket system or company wiki. To reach it, you can use an MCP tunnel with either option. MCP tunnels are in research preview and need an access request. See Self-hosted sandboxes and MCP tunnels.
- Run under your organization's own compliance and audit controls: Tools run on hosts that you configure, log, and audit.
What a self-hosted sandbox doesn't change
With either option, the conversation history and tool results go to the Managed Agents service, which Anthropic operates. That is how the model receives the result of each tool call. The web search and web fetch tools also run on Anthropic's side, not in the sandbox. See Restrict web search and web fetch domains. Neither option changes the compliance coverage of Managed Agents or how long it keeps conversation history. See API and data retention.
What you take on and give up with a self-hosted sandbox
A self-hosted sandbox makes you the operator of the worker hosts. You harden the sandbox image, control network egress, store and rotate the environment key, and isolate sessions from each other. The Security model page has the detail.
You also give up these cloud environment features:
fileandgithub_repositorysession resources. You stage input files yourself, and you are responsible for mounting your own GitHub repository too.- Repository skill discovery.
- Environment variable credentials in vaults.
- The pre-installed runtimes and packages of a cloud sandbox. A self-hosted sandbox has whatever your worker provides.
Differences on Claude Platform on AWS
If you use Claude Managed Agents through Claude Platform on AWS, Anthropic still operates the service. There, a self-hosted sandbox can't use memory stores, workers don't use an environment key, and MCP tunnels aren't available. See Claude Managed Agents on Claude Platform on AWS and Features not supported.
Switch from a cloud environment to a self-hosted sandbox
To switch to a self-hosted sandbox, you keep the agent, create a self_hosted environment, and reference its ID in new sessions and deployments.
- What carries over: The agent definition, the API key or AWS credentials your application uses, your skills, your MCP servers, and your memory stores.
- What is new: A
self_hostedenvironment, an environment key that you generate in the Claude Console, and a worker that you run. The self-hosted sandboxes quickstart covers all three. - What stops working: The features listed in What you take on and give up with a self-hosted sandbox.
On Claude Platform on AWS, memory stores don't carry over to a self-hosted sandbox, and the worker doesn't use an environment key. See Differences on Claude Platform on AWS.
Was this page helpful?