Claude Managed Agents worker

Anthropic's Claude Managed Agents can run with a self-hosted environment. The agent loop stays on Anthropic's side, and the tools run on a machine you control: bash, the file tools (read, write, edit, glob, grep) and code. A worker on that machine long-polls Anthropic's work queue. The connection is outbound only, so nothing dials into the machine.

The managed-agents template is that machine. It is the base Linux desktop with Anthropic's Python SDK worker (EnvironmentWorker) installed as a service, waiting for your environment's key.

What is on the image

• The worker. mandala-managed-agents-worker.service runs as the desktop user, in /home/user/workspace. It starts once the computer's secrets have been delivered, and reads them through a login shell.
• Memory stores. /mnt/memory is owned by the worker. For a session that attaches memory stores, the worker downloads each one to /mnt/memory/<store>/ and syncs it back while the session runs.
• A terminal at login. It shows the worker's status and the commands to follow its log:

sh systemctl status mandala-managed-agents-worker journalctl -u mandala-managed-agents-worker -f

Without its two values the worker exits at once with "not connected". The service does not restart it in a loop.

Connect it

1. Create a self-hosted environment with your Anthropic API key:

python import anthropic

client = anthropic.Anthropic() environment = client.beta.environments.create( name="mandala", config={"type": "self_hosted"} ) print(environment.id) # env_...

1. In Console, open that environment and generate an environment key (sk-ant-oat01-…).

1. Store both as Mandala secrets and bind them to the computer as ANTHROPIC_ENVIRONMENT_KEY and ANTHROPIC_ENVIRONMENT_ID. A bound value is delivered before the desktop and the worker start, and Mandala keeps it on a memory-backed file system in the guest, not on the disk. The image holds no key.

1. Create sessions against environment_id exactly as you would for a cloud environment:

python session = client.beta.sessions.create( agent={"type": "agent", "id": agent.id, "version": agent.version}, environment_id=environment.id, )

Launch the worker computer

This program needs pip install mandala-computer and a MANDALA_API_KEY. It stores the two values as secrets, launches a worker computer with them bound, and checks that the worker is polling. The computer is persistent: it keeps serving your environment until you stop or delete it.

The stored secrets are named after the environment, and bound under the two names the worker reads. A stored secret is shared by every computer bound to it, so one fixed name for every environment would repoint an earlier worker at the newest environment on its next start.

import os

from mandala_computer import Client

client = Client()  # reads MANDALA_API_KEY
environment_id = os.environ["ANTHROPIC_ENVIRONMENT_ID"]  # env_...
key = client.secrets.set(f"ANTHROPIC_ENVIRONMENT_KEY_{environment_id}", os.environ["ANTHROPIC_ENVIRONMENT_KEY"])
env_id = client.secrets.set(f"ANTHROPIC_ENVIRONMENT_ID_{environment_id}", environment_id)

computer = client.computers.launch(
    template="managed-agents",
    name="managed-agents-worker",
    secrets=[
        {"secret_id": key.id, "env": "ANTHROPIC_ENVIRONMENT_KEY"},
        {"secret_id": env_id.id, "env": "ANTHROPIC_ENVIRONMENT_ID"},
    ],
)  # waits until the secrets have reached the computer
res = computer.exec(
    "systemctl is-active mandala-managed-agents-worker; "
    "journalctl -u mandala-managed-agents-worker -n 3 --no-pager -o cat",
    desktop=True,
)
print(computer.id, res.stdout_text)  # "active" and "polling environment env_..."

To bind the values to an existing computer, stop it first, bind them, and start it again. The worker reads them when it starts.

What to know before you rely on it

• One store, one session at a time. The worker refuses a work item when the store's directory under /mnt/memory already exists. Two sessions that attach the same memory store cannot run on one computer at once. For parallel sessions, run more than one worker computer.
• Vault credentials do not reach a self-hosted sandbox. Anthropic substitutes vault environment_variable credentials at its own egress, and here the egress is this computer's. - A key that a tool needs can be bound as one more Mandala secret instead. It is then in the worker's environment, where bash can read it. - Or keep it on your side with an MCP server or a custom tool.
• No file or github_repository resources. Self-hosted environments accept only memory_store resources. Clone a repository or fetch a file from inside the session with bash.
• The agent's tools can read the environment key. bash runs as the same user as the worker, as it does with Anthropic's own in-process worker. Give each worker computer to one environment, and rotate the key in Console if it is exposed.
• Stopping gives the worker 15 seconds. On a stop, the worker cancels its work item and uploads changed memory files. That usually takes a few seconds. Anthropic recommends allowing 30, so before you stop a computer in the middle of a session, interrupt the session from Anthropic's side. - A restart resets the machine without a shutdown, so the worker runs no teardown. Memory edits it had not uploaded are lost. - If a worker did not get its teardown, or ran out of time, it leaves its store directories behind. Before its next session, and when it starts, the worker moves them to /var/lib/mandala-managed-agents/orphaned/, so the next session can run. You can look there for edits that never uploaded.
• Egress is yours. The worker computer reaches the internet like any Mandala computer. To restrict it, set an egress proxy on the computer. web_search and web_fetch run on Anthropic's servers either way.