Apple's container makes no sense as a Docker replacement — until you see it as a box for AI agents

日本語版 (Japanese version): Apple containerの不可解な設計、実は"AIエージェント用の箱"を作ってるだけ説

A design that keeps losing benchmarks

When I measured Apple's container runtime, the honest numbers were rough: every container gets its own VM at roughly 270–400 MB, throwaway containers start 4–10× slower than Docker's, and a named volume can only attach to one running container at a time. Judged as a docker compose replacement, it looks like Apple deliberately picked a losing design.

And that's the puzzle. Apple obviously knows how Docker Desktop's shared-VM model wins on density — that design has had a decade of tuning. They looked at it and walked away anyway. Why?

Here's the hypothesis this post explores: Apple isn't building a box for your dev stack. It's building a box for code you don't trust. And in 2026, the most important untrusted code around is the AI coding agent. Read the design through that lens and every "flaw" starts looking like a decision.

This is an interpretation piece, but every claim below is anchored to something measured on my machine or shipped in public. At the end I'll list predictions that would falsify the whole reading.

Exhibit 1: the parts list is suspicious

Line up what Apple has shipped over the past year — as parts, not features.

Per-VM isolation. Each container gets its own lightweight VM with its own kernel. Worst possible choice for "many containers, cheaply"; best possible choice for "one untrusted thing, strongly isolated."

For contrast: Microsoft went the opposite way the very same month. WSL containers (public preview, June 2026) run in one shared utility VM with namespace isolation — the same "many, cheaply" side Docker sits on. Two OS vendors shipped first-party containers at the same time and made opposite isolation choices. That tells you what each was optimizing for.

But here's the interesting part: Docker itself picked per-VM when the workload is an agent. Docker Sandboxes (January 2026) isolates Claude Code, Codex, and friends in a dedicated microVM per agent. The company whose whole model is "share one kernel, run many" chose a VM boundary the moment the tenant became untrusted code. Two players, different starting points, same answer. I take that as evidence about what these boxes are for.

mcpbridge. Apple officially announced agentic coding in Xcode 26.3, exposing Xcode's capabilities over MCP. The implementation is a bundled binary, xcrun mcpbridge, that translates MCP into XPC — Apple's entitlement-gated IPC. A portability protocol, deliberately re-rooted into Apple's permission model: MCP tools treated as capabilities, the same shape as iOS app permissions. In the Xcode 27 beta there's a second layer: ACP (Agent Client Protocol) — an open protocol from Zed, not Apple — governs which agents may connect at all. MCP says what an agent can do; ACP says who gets in. Two gates, both built from other companies' open standards folded into Apple's own permission model.

Models on the host, tools in the box. Apple container has no GPU/ANE passthrough. Inference was never meant to live in the container: Foundation Models run host-side on the Neural Engine, and the containers hold the tools.

Container machines. WWDC26 also brought persistent Linux VMs — the long-lived counterpart to container run's disposable ones.

Boundaries and gates everywhere. That's a lot of parts for a "Docker alternative."

Exhibit 2: this is how Apple has always done safety

There's a lineage here. Private Cloud Compute's design principle was "don't trust the operator — prove it structurally." The iOS sandbox is the same shape: apps run free inside the sandbox, and hit a checkpoint only when crossing a boundary — contacts, camera, location. The checkpoint is an entitlement check or that permission dialog you've tapped a thousand times. Call it the gate.

free inside the boundary → one gate at the crossing

Now compare that to how today's coding agents are kept safe: an approval prompt for every action, a human in the loop for each step. Apple's pattern is the inverse — total freedom inside, one gate at the edge. Per-VM containers are the boundary; mcpbridge + ACP are the gate. The parts line up with the philosophy.

For agents this difference is fundamental. Per-action approval burns human attention continuously. A boundary model justifies --dangerously-skip-permissions structurally: whatever happens, it happens inside the box. Since an agent's whole value is autonomous, continuous operation, I'd bet agent platforms converge on the boundary model. That bet is the core of this post.

Exhibit 3: you can already build the box — with a compose file

Here's the observation I most want to share. To run the boundary model on a Mac today you need some way to declare what the agent gets. iOS has entitlements for this. The container world, it turns out, already has a vocabulary for it — the compose file:

• volumes: (bind mount) = the files the agent may see
• environment: + .env = the secrets it holds
• ports: / host gateway = its reach back to the host
• networks: / network_mode: = how far it reaches out

I didn't want to leave that as theory, so I built it. (Apple container doesn't read compose files itself; I used opossum, a compose-compatible orchestrator I work on, as the translator — but the star here is the compose vocabulary, not the tool.)

name: agent-sandbox

services:
  agent:
    build: .            # node:22 + git + Claude Code
    user: node          # non-root: Claude Code refuses full-auto mode as root
    working_dir: /work
    volumes:
      - ./work:/work    # the ONLY host files the agent sees; results land here
    mem_limit: 4g       # the default ~1 GiB guest is tight for node + build + test
    cpus: 4
    environment:
      CLAUDE_CODE_OAUTH_TOKEN: ${CLAUDE_CODE_OAUTH_TOKEN:-}   # value lives in .env

Read differently, this file is a capability manifest: this agent sees ./work and nothing else, holds this one token, gets 4 GB. No new machinery — ten-year-old compose vocabulary, reread.

Does it actually work? On my machine (macOS 26, container 1.1.0): I gave the in-VM Claude Code one line — "fix the failing test in /work/demo and commit" — in full-auto mode. It found the bug (an addition function doing a - b), fixed it, ran the tests, and committed, with zero human input. The results appeared on the host via the bind mount. Whatever the agent had done in there, the only thing that could reach my Mac was the contents of ./work.

And the benchmark numbers that looked so bad in my first post? For this workload they stop mattering. Agent tasks run for minutes, so a ~1 s VM boot is noise; 270–400 MB per VM is nothing when you're granting the agent 4 GB anyway. The puzzle from the intro resolves.

The weak side: egress

Files, secrets, and host reach are all declarable. Outbound network is the rough edge. What I measured (macOS 26 / container 1.1.0):

Goal	Possible today?	How
Block everything	✅	network_mode: none (loopback only)
Block internet, keep host	✅	an internal network (--internal)
Destination allowlist	✅ (enforced)	internal network + an allowlist proxy on the host
Native per-container domain allowlist	❌ not yet (Apple; Docker Sandboxes has it — see below)	(prediction #1)

Row three is the one worth knowing. On an internal network the internet route physically disappears, so the only way out is a proxy you run on the host. An agent that ignores http_proxy and connects directly simply gets nothing. The allowlist is enforced, not advisory. (In-guest iptables allowlists, for the record, didn't work in my tests — allowed destinations dropped too. The proxy approach is the right one.)

"Why not just use Docker Sandboxes?"

Fair question — I asked it myself, so I put it through its paces (Docker Desktop 4.78, docker sandbox v0.12):

docker sandbox create shell .        # a box with the current dir as workspace
docker sandbox exec <box> uname -a   # → Linux ... 6.12.67-linuxkit aarch64

What I found:

• It's a real microVM: a linuxkit-kernel Linux, one per agent — same idea as Apple's per-VM
• The workspace mounts at the same path as the host
• It has the native domain allowlist Apple lacks:

docker sandbox network proxy <box> --policy deny --allow-host example.com

With that set, example.com returns 200 from inside the box and anything else gets 403. Better: bypassing the proxy env vars entirely (curl --noproxy '*') fails even for the allowed host — there is no direct route out, the MITM proxy is the only exit. Enforced, same property as the internal-network setup above. The box even ships a docker CLI inside, so containers-in-VM works out of the box.

Honestly, as an agent box today, Docker Sandboxes is the most complete option: native allowlists, multiple agents, save for snapshots, reset in seconds.

What interests me is not which is better but that the two approaches express the box's permissions differently. Docker Sandboxes is imperative: you run commands to configure the box. The compose approach is declarative: mounts, env, and networks sit in one file. A procedure has to be executed to be understood; a declaration can just be read — by a human or by another agent. In a world where agents build and audit each other's boxes, I'd expect the readable form to win. But that's a forecast, not a verdict: what we can observe today is two vocabularies — imperative and declarative — emerging in parallel for the same per-VM box.

Exhibit 4: the same principle, invented three times

"Free inside, gate at the boundary" isn't only Apple's pattern. The players differ in what they build the boundary out of:

• The spatial layer — physical walls. VMs: places the agent simply cannot reach
• The semantic layer — judging the meaning of an action. "Is this force push dangerous?" A checkpoint officer instead of a wall
• The resource layer — shrinking what's handed over in the first place. Mounts and env: can't leak what you don't hold

Layer	Main implementation	Declared in	Enforced by
Spatial (Apple)	VM boundary, entitlements	entitlements / VM config	kernel, hypervisor
Semantic (Anthropic)	the auto-mode classifier	autoMode.environment (prose)	a classifier LLM
Resource (compose)	mounts / env / networks	compose.yaml	VM configuration

"Main" because nobody stays in one layer: Anthropic also ships a process-level spatial layer (Seatbelt on macOS, bubblewrap on Linux, with a proxy-enforced domain allowlist — strikingly similar to the egress setup above). It's an OS-process wall, though; a per-VM kernel wall is a harder material, and that's Apple's turf.

The semantic layer deserves a note. Claude Code's auto-mode routes every tool call through a classifier that blocks only the irreversible, destructive, or out-of-environment. Its boundary is declared in prose ("Source control: github.example.com/acme-corp"), and its precedence ends with explicit user intent: saying "force push this branch" clears a soft block. Conversational context becomes part of authorization — something a VM or an entitlement can't do in principle. Conversely, a probabilistic classifier can't hard-limit the blast radius of arbitrary code execution. Only the spatial layer can.

So the "capability manifest" has been invented three times — as entitlements, as prose, as compose.yaml — and the three don't compete. They stack, like defense in depth. They already interlock in one concrete place: auto-mode's built-in rules (dump them with claude auto-mode defaults) block launching an unsupervised agent loop only when it runs "without sandbox isolation AND without a per-action approval/monitor gate." Declare the spatial layer, and the semantic layer steps aside. The sandbox from Exhibit 3 satisfies exactly that condition — via a compose file.

Verdict

Question	Answer
Are the benchmark downsides real?	✅ Real (my earlier measurements stand)
Are the "agent box" parts all shipped?	✅ per-VM, mcpbridge + ACP, host-side models
Can you build the box today?	✅ compose vocabulary + a real autonomous end-to-end run
Has anyone else made the same choice?	✅ Docker Sandboxes, from the opposite starting point
Has Apple said "this is an agent box"?	❌ Never, anywhere. That part is my reading

The parts exist, the philosophy matches, and the box demonstrably works. What's missing is Apple saying so. Circumstantial evidence everywhere; the suspect remains silent.

So, predictions — ordered by my confidence, so this reading can be scored later. If these miss, the title was just my imagination:

1. apple/container ships per-container egress control. This is the big one. Docker Sandboxes already has native allowlists, and there's an open Discussion asking for network isolation. If two years pass with nothing, discard this whole post
2. mcpbridge escapes Xcode. An MCP→XPC gate is far too general-purpose to stay a single IDE's feature
3. Container machines grow agent-workspace features. A box you let agents experiment in badly needs "undo": Docker Sandboxes' save/reset is exactly that. If snapshots/rollback land on container machines, that's the tell
4. A first-party API connecting Foundation Models to tools running in containers — Apple wiring up its own "models on the host, tools in the box" split
5. Attestation for agent runs: a verifiable proof that this artifact was produced inside that box (a cousin of GitHub's Artifact Attestations). Far off, but it's the natural endpoint of the PCC lineage — proof by structure, not trust

Honest caveats

• Apple has shipped host-side agents with gated tools (mcpbridge/ACP). Running the agent inside the VM is my extrapolation; I verified that it works, not that Apple intends it
• The benchmark downsides have not gone away. I still don't recommend moving your dev stack (see the measurements); this post is about a different objective, not revised numbers
• The VM protects the host. Whatever you bring inside — the mounted ./work, the token — is inside the blast radius. A manifest declares what you hand over; it doesn't protect what you've handed

Summary

• Apple container's "inexplicable" design becomes coherent the moment the box is for untrusted code rather than for your dev stack
• The parts — per-VM boundaries, mcpbridge (MCP→XPC), ACP, host-side models — sit squarely in the PCC lineage of structure over trust
• The vocabulary to build such a box already exists: a compose file works as an agent's capability manifest, and a real agent completed a task fully autonomously inside one
• The same principle now exists at three layers — spatial, semantic, resource — and they stack rather than compete
• The scoreboard: whether apple/container ships per-container egress control

Models will keep getting smarter on their own. The contest is moving to the outside: what you hand an agent, how far you let it reach, how you check what it did. Apple writes that in entitlements, Anthropic writes it in prose, and the container world writes it in ten-year-old compose files. The next fight is over how the box gets declared.

If you can refute any prediction on the list, I genuinely want to hear it — comments here or wherever you found this.