In Claude Managed Agents (beta, available on the first-party Claude API and Claude Platform on AWS only — not on Amazon Bedrock, Google Vertex AI, or Microsoft Foundry), the agent loop itself runs on Anthropic's orchestration layer. But the agent's tools — bash commands, file operations, code — execute inside an isolated container provisioned per session. An environment is the reusable configuration template for those containers. You create it once, and every session that references it gets a container built to that spec. Environment names must be unique; creating a duplicate returns a 409 error.
Cloud or self-hosted
An environment's config.type is either "cloud" — Anthropic runs the container and handles scaling, container lifecycle, and work orchestration — or "self_hosted", where tool execution moves to a container you control. Self-hosted is the answer to compliance and data-residency questions: filesystem contents and network egress never leave your infrastructure, and connectivity is outbound-only — your worker long-polls Anthropic's work queue, and Anthropic never dials into your network. The trade-off is that you own container hardening, egress control, and file mounting yourself, and some features (memory-store resources, vault environment-variable credentials) are not yet supported there. Self-hosted sandboxes are also not available on Claude Platform on AWS.
Network policy: the setting security teams will ask about
Cloud environments have two networking modes. unrestricted allows full internet egress apart from a legal blocklist. limited is deny-by-default, with explicit opt-ins: an allowed_hosts list, allow_package_managers, and allow_mcp_servers. For enterprise use, limited networking is the sensible default — but note one sharp edge: under limited networking you must either set allow_mcp_servers: true or list every MCP server domain in allowed_hosts, or MCP tools fail silently mid-run.
What lives in the container during a session
The agent's working directory defaults to /workspace, and everything it writes there persists for the life of the session — across many messages and hours of work. Three kinds of resources can be attached at session creation:
| Resource | How it appears | Persistence |
|---|---|---|
file (uploaded via the Files API) | Mounted read-only at an absolute mount_path | Session lifetime; agent writes modified copies to new paths |
github_repository | Cloned into the container before the agent starts | Session lifetime; repos are cached so later sessions start faster |
memory_store | Mounted at /mnt/memory/<store-name>/ | Persists across sessions, workspace-scoped |
Session creation blocks until all resources are mounted, with limits of 999 file resources and 8 memory stores per session. Getting results back out has a dedicated bridge: any file the agent writes to /mnt/session/outputs/ is automatically captured by the Files API and can be listed and downloaded after the run. GitHub access is proxied — the repository's authorization token never enters the container; git operations route through an Anthropic-side proxy that injects the token after the request leaves the sandbox.
/mnt/session/outputs/ and memory stores — as the only durable state. Everything else disappears when the session is deleted.Teardown and change management
Environment behavior on change is conservative in a way that helps production stability: updating an environment applies only to new containers, and existing sessions keep their original configuration. Archiving an environment is permanent — it becomes read-only, there is no unarchive, and new sessions can no longer reference it, though running ones continue. Deleting a session permanently removes its container along with event history and checkpoints. Because sessions store sandbox state server-side, Managed Agents is not currently eligible for zero-data-retention coverage; the mitigation is that sessions and uploaded files can be deleted at any time via the API.
Practical setup order
The documented flow is: create the agent, create the environment, then start sessions referencing both. Before the first real run, reconcile dependencies — confirm every expected action maps to a configured tool or MCP server, every MCP server has a credential, and every file or host the task needs is actually mounted or reachable. A session with a missing dependency discovers the gap mid-run and flails, burning time and tokens.
Where to go next
See session lifecycle and turn management for how work flows through a session, vaults for how credentials reach the sandbox safely, and Managed Agents on Claude Platform on AWS for the AWS-resident variant.