Sandboxed AI coding agents on a Mac Mini M4: Tart VMs, Apple container and the storage they take

Why an unattended coding agent needs a sandbox at all

The risk is not that the model is malicious; it is that the agent runs commands against a codebase it did not write and cannot fully vet, sometimes with permission prompts turned off so it can keep working unattended overnight. A project with a prompt-injected comment, a compromised dependency, or a build script that does more than build can turn an agent's ordinary file and shell access into someone else's access, to whatever that login session can reach: SSH keys, browser cookies, cloud credentials, the rest of the filesystem.

Putting the agent in a virtual machine instead of running it directly on the machine you use every day does not make a malicious project harmless, but it shrinks what it can reach. Whatever the agent's session can touch stops at the VM's own disk and its own, deliberately narrow, network access, instead of extending to the host account's keys and history.

Why a VM, and why on an always-on Mac Mini

A virtual machine boots its own kernel under Apple's Virtualization framework; a process that breaks out of the agent's own account inside the guest still has to break out of that guest kernel before it reaches the host at all. A container shares the host's kernel by design, which is a lighter and faster boundary but a thinner one. Neither is a promise of perfect containment, and the caveats section below covers where each one's isolation actually ends.

A laptop that has to stay open, awake and connected for an overnight agent run defeats the point of running the agent unattended in the first place. The same case that makes a Mac Mini M4 a base for remote AI coding applies here: plugged in and always on, it can keep a sandboxed agent running long after the laptop it was started from has closed its lid.

Tart: macOS and Linux guests on Apple's own virtualization framework

Tart runs macOS and Linux virtual machines on Apple's Virtualization framework rather than emulating hardware, which is what lets a macOS guest run on Apple silicon at close to native speed. Pulling the standard macOS base image "will download a 25 GB image"; a Linux base image is lighter, with "a minimal disk size of 20 GB" (github.com/openai/tart, docs/quick-start.md, checked September 2026). A VM's files live under ~/.tart/vms/<name>/, and images pulled from a registry are cached under ~/.tart/cache/OCIs/, both relocatable with the TART_HOME environment variable (tart.run FAQ, checked September 2026).

Cloning a VM to sandbox a second agent, or to reset one back to a known-clean state, does not copy the whole disk up front: Tart's own clone code notes that "a cloned VM won't actually claim all the space right away. Only changes to a cloned disk will be written and claim new space" (github.com/openai/tart, Sources/tart/Commands/Clone.swift, checked September 2026), because the clone shares its backing blocks with the base image on APFS until one of them writes to a shared block. Tart also prunes its own image cache automatically on every clone or pull, by default once the cache passes 100GB, adjustable or disabled with TART_NO_AUTO_PRUNE (same source; tart.run FAQ, checked September 2026).

Running two or more macOS guests, sandboxed or not, runs into Apple's own licence before it runs into disk space: the macOS Tahoe software licence permits "up to two (2) additional copies or instances" of macOS running in virtual machines on top of one licensed Mac, for development, testing, or personal non-commercial use (apple.com/legal/sla, docs/macOSTahoe.pdf §2B(iii), checked September 2026). Apple's own developer forums describe Virtualization.framework as enforcing that same two-guest cap in software, not just in the licence text (developer.apple.com/forums, thread 729580, checked September 2026). The cap is on macOS guests specifically; Tart's Linux guests are not affected by it.

Tart itself changed hands during 2026: the project's GitHub repository now redirects from cirruslabs/tart to openai/tart, under the same repository id, and its licence file is the Functional Source License ("FSL-1.1-ALv2"), copyright OpenAI (github.com/openai/tart, LICENSE, checked September 2026). An FSL licence converts to the permissive Apache 2.0 licence after a fixed number of years and, until then, excludes only "Competing Use" — running the software as a paid alternative to OpenAI's own offering. Ordinary use, sandboxing a coding agent included, is unaffected.

Setting up a sandboxed VM with Tart

Tart installs as a Homebrew formula; cloning the base image once and running the clone leaves the original image untouched for the next clone.

brew install openai/tools/tart
tart clone ghcr.io/cirruslabs/macos-tahoe-base:latest agent-sandbox-1
tart run agent-sandbox-1

The default login for a fresh macOS guest is the account admin with password admin (github.com/openai/tart, docs/quick-start.md, checked September 2026) — change it before installing anything an unattended agent will run under. From the host, tart ip agent-sandbox-1 prints the guest's own address on Apple's private virtual network, and a plain ssh reaches it from there:

Getting into the guest and installing the agent

ssh admin@$(tart ip agent-sandbox-1)

Install the coding agent's CLI, and only its own API key or OAuth token, inside the guest, not the host's. A second clone (tart clone ghcr.io/cirruslabs/macos-tahoe-base:latest agent-sandbox-2) gives a second, independent sandbox for a second project, up to the two-guest macOS cap above; a Linux base image instead of the macOS one has no such cap and is the lighter choice when the agent's toolchain does not need macOS itself.

Lighter options: Apple's container and Claude Code's own devcontainers

A full macOS or Linux VM is not the only way to give an agent a narrower box than the host account. Apple's own container tool, "supported on macOS 26" on a "Mac with Apple silicon" (github.com/apple/container, README, checked September 2026), runs "Linux containers as lightweight virtual machines on your Mac" (same source) — each container gets its own lightweight VM rather than sharing one host kernel the way Docker's containers do, which is a middle ground between a full Tart guest and a shared-kernel container.

Claude Code's devcontainer support runs the agent inside a standard Docker-based development container instead, which isolates the filesystem and can restrict network egress, but Claude Code's own documentation is explicit about where that isolation ends: "when executed with --dangerously-skip-permissions, dev containers do not prevent a malicious project from exfiltrating anything accessible inside the container, including the Claude Code credentials stored in ~/.claude" (code.claude.com, docs/en/devcontainer, checked September 2026). A devcontainer keeps an agent off the host filesystem; it does not, by itself, keep a compromised project from reading and sending out whatever the container itself holds, credentials included.

Which of the three fits depends on what is being sandboxed against: a devcontainer for day-to-day work on a trusted repository with unattended permissions, Apple's container for a lighter Linux sandbox already available on a Mac running macOS 26, and a full Tart VM for the strongest isolation, or for a project that needs to be treated as untrusted rather than merely unattended.

Reaching the agent from wherever you are

None of this needs the sandbox to sit at a desk in front of someone: the same Tailscale, mosh and herdr setup that reaches an agent running directly on a Mac Mini M4 reaches one running inside a Tart guest just as well, because the guest gets its own address on the host's network. Point mosh or herdr's remote-attach flag at the guest's Tart IP, or, once Tailscale is installed inside the guest itself, at its Tailscale machine name, and the agent inside the sandbox stays reachable across sleep, roaming, and a laptop's lid closing exactly as it would running unsandboxed.

Why this fills a disk faster than running one agent directly would

None of this is free: every sandboxed guest is a second copy of an operating system, and a base image shared by several clones only stays cheap for as long as those clones agree with each other. Every row below is our own planning estimate for a Mac Mini M4 used this way, built from the sourced download sizes above plus a divergence allowance for clones and caches that has no published figure to draw on; it is not a measurement of one specific machine.

That is 150GB by our estimate before the sandboxed projects themselves take any space: 106GB left on 256GB, 362GB on 512GB, 1850GB on 2TB. Running every option side by side is the ceiling, not the plan; picking one or two of them for a real setup leaves considerably more of that headroom in place.

The honest caveats

• A sandbox narrows what a compromised project can reach; it does not make an untrusted project safe to run with every guardrail off. Claude Code's own devcontainer documentation says as much directly: no system here is "completely immune to all attacks" (code.claude.com, docs/en/devcontainer, checked September 2026).
• The macOS licence's two-guest cap is real and applies per licensed Mac, not per sandbox: a third macOS guest, sandboxed agent or not, is outside the licence terms even if the disk has room for it (apple.com/legal/sla, docs/macOSTahoe.pdf §2B(iii), checked September 2026). Linux guests, in Tart or in Apple's container, are not covered by that cap.
• Tart's FSL-1.1-ALv2 licence is not an open-source licence today, only a source-available one that converts to Apache 2.0 after its change date; the "Competing Use" exclusion is worth reading in full before building a paid service around it (github.com/openai/tart, LICENSE, checked September 2026).
• No vendor publishes the decompressed, on-disk size of a diverged macOS clone or Apple container's own image storage path; both rows in the table above are our planning estimate, not a measured figure, and either can run higher on a machine that keeps many diverged clones around instead of deleting and re-cloning them.