Environment worker

This guide describes how to build a worker with any generic sandboxing platform. Additional, platform-specific guides are available for AWS Lambda MicroVMs, Blaxel, Cloudflare, Daytona, E2B, Fly.io, GKE Agent Sandbox, Modal, Namespace, Superserve, and Vercel.

An environment worker is a process you run on your own infrastructure. It receives tool execution requests from Anthropic and runs them locally. The self_hosted environment acts as a work queue: when a session is assigned to it, Anthropic enqueues the session as a work item. Your worker claims work items from that queue, spawns an execution context for each one, downloads the agent's skills (reusable, filesystem-based resources that give the agent domain-specific expertise), runs the tool calls, and posts the results back.

Work items are claimed by polling the environment's queue: either by an always-on worker that polls continuously, or a webhook-triggered handler that wakes on session.status_run_started and starts polling.

The CLI and SDK both ship pre-built workers. The ant CLI supports the always-on pattern only; the SDK supports both always-on and webhook-triggered. Both are configurable: see Self-hosted worker in the reference for CLI flags, and SDK helpers on this page for the SDK options. For more control, call the Environments Work endpoints directly and implement your own worker.

Sandbox filesystem

• /workspace: the system default working directory for tool execution and skill download. The CLI's --workdir flag defaults to the current directory; pass --workdir /workspace to match the system default. Skills are downloaded to <workdir>/skills/<name>/. If you use a different working directory, update your agent's system prompt so Claude can locate the skill files.
• Outputs: on self-hosted environments the session's system prompt omits the /mnt/session/outputs instruction used on Anthropic-managed sandboxes, so final deliverables land wherever the agent writes them in your sandbox filesystem, typically under the working directory.
• /mnt/memory/: memory stores attached to the session are materialized here by the SDK worker, one directory per store at the store's mount_path (for example, /mnt/memory/user-preferences/). The worker creates these directories when it claims the session and removes them when the session ends; see Use memory stores.