Agent sandbox comparison: Microsoft Execution Containers vs Docker Agent vs Agent37, and the defaults that bite

{
  "version": "1.0.0",
  "containment": "processcontainer",
  "process": { "commandLine": "python -c \"...\"", "timeout": 30000 },
  "network": {
    "egress": { "default": "deny",
      "allow": [{ "to": [{ "cidr": "140.82.114.6/32" }], "ports": [{ "protocol": "tcp", "port": 443 }] }] },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  }
}

Docker Agent's sandbox is a microVM that stays off until you pass --sandbox

Docker Agent is Docker's own agent harness, bundled with Docker Desktop. With --sandbox, it runs every tool, shell, file access and background job, inside a Docker Sandboxes microVM: only the working directory is mounted read-write, other host files are not visible, and traffic goes through a proxy that allows the model providers and blocks package registries until you add them. The sandbox docs list the flag's default as false.

Docker does not say why it is off. My guess: the sandbox needs sbx installed separately plus hardware virtualization, so a default-on flag would fail on many machines. Without the flag, Docker Agent runs tools on the host, and Docker calls its approval modes "defense in depth against unwanted tool calls, not a security boundary". To turn it on per agent:

runtime:
  sandbox: true
  network_allowlist:
    - registry.npmjs.org

For Claude Code or Codex users, the part to use is Docker Sandboxes on its own: sbx run claude boots the same microVM around Claude Code, Codex, Copilot, Cursor and seven other agents, without Docker Desktop. On first run it asks for a network preset, Open, Balanced or Locked Down, with Balanced highlighted, and Docker's security docs warn that Balanced's defaults "include broad wildcards" such as *.googleapis.com. The same docs list what stays outside: local stdio MCP servers run on the host, and edits to Git hooks or package.json scripts in the mounted folder are live on your machine.

Agent37 moves the agent off your machine, with the public internet left open

Agent37 runs each agent in a hosted gVisor sandbox with its own disk, prebuilt for Claude Code, Codex, OpenCode, OpenClaw, Pi and others. The pricing page charges $0.80 per vCPU, $0.70 per GB of RAM and $0.09 per GB of disk per 730-hour month, billed by the minute while awake. The $0.37 headline assumes 57 hours of use a month; a 2 vCPU, 4 GB sandbox running all month is $4.76.

Nothing in the sandbox can read your home directory. Its egress allows "the public internet and nothing else", per the site, which blocks the host and private networks but lets an agent send what it holds anywhere. On the Launch HN, a commenter called gVisor "less secure than VMs" while the price comparison is against VMs; the founder replied "That's fair". Another put it plainly: the "sandbox protects the host. it does not protect your tokens." Agent37's price table of 31 providers is its own marketing, and gVisor sandboxes cannot run Docker inside.

Codex's background daemon shows what no command sandbox covers

A command sandbox only wraps what the agent spawns, not the agent itself. Codex CLI 0.157.0, released on 25 September 2026, starts a persistent codex app-server daemon by default. According to issue #48195, it survives closing every Codex window, copies a 374 MB package into ~/.codex, checks for updates hourly and keeps the environment, proxy settings included, of whichever session started it.

Codex's sandbox applies to "spawned commands", so the daemon runs with whatever your user account can read and reach. On 13 October the issue had 174 reactions and no OpenAI staff reply, and the setting was still on by default; the opt-out is codex features disable daemon_auto_start. Of the three layers, only a box around the whole process, such as Docker Sandboxes, would contain it.

What switching between them costs

Switching cost follows the layer. Leaving MXC is not your choice to make, because the agent vendor owns that integration, and its JSON policy only works with MXC. Docker Agent's sandbox is a few YAML keys, but leaving it means leaving Docker Agent as a harness; with sbx alone, what you carry is the sbx policy rules. Agent37 moves work off your machine, with its LLM gateway, connectors and cron API, and its gateway is the only open-source part.

On Stackness, as of 13 October 2026, 8 real profiles list Claude Code, 7 list Docker, 7 list Cursor and 2 list Codex, after removing bot accounts (data sources). The numbers are small and say nothing about sandboxes, but they put Docker, one of the DevOps and infrastructure tools developers list, in as many stacks as the AI coding tools it would contain. For several agents at once, the fleet consoles post compares where each one isolates them.

Pick MXC if, pick Docker if, pick Agent37 if

Pick MXC if:

• You build an agent and need one containment API across Windows, Linux and macOS.
• You use GitHub Copilot and can run /sandbox enable today.
• You run Codex on Windows 11 24H2 or later and can opt in with prefer_mxc = true.
• You can run a proxy for hostname rules, and you skip the helper policies until issue #1455 is fixed.

Pick Docker Sandboxes or Docker Agent --sandbox if:

• You want a VM boundary around Claude Code, Codex or Cursor on your own laptop now.
• You need Docker to work inside the box.
• Your machine is Apple silicon, Windows 11 with Hypervisor Platform or Ubuntu 24.04 with KVM.
• You choose Locked Down or review Balanced's wildcards, and turn --sandbox on in every agent file.

Pick Agent37 if:

• The agent should run when your laptop is closed, on a schedule or for other people.
• Your laptop is the thing to protect, and the agent's credentials can live on a hosted box.
• You can accept open internet egress and a gVisor boundary rather than a VM.
• Cost per idle agent matters more than isolation strength.