Sandboxing Claude CLI with Tart on Apple Silicon

What happened

Muhammad Rafay Aleem published a walkthrough on June 19, 2026, showing how to run Claude CLI and similar LLM harnesses inside a lightweight virtual machine on Apple Silicon using Tart, a thin CLI wrapper around Apple's native Virtualization framework. The technique sidesteps the uncomfortable choice between refusing to use the powerful but risky "--dangerously-skip-permissions" flag or running it directly on a host MacBook where a misbehaving agent could delete files, install unwanted software, or make network calls outside any guardrails.

This piece walks through the mechanism behind the Tart-based sandbox, explains why it is meaningfully lighter than VMware Fusion, and covers what any developer running Claude CLI, Codex, or a similar autonomous harness on Apple Silicon should verify before trusting the setup for daily work.

Aleem described his earlier attempt at solving the same problem using VMware Fusion with Ubuntu virtual machines, synchronized to his host machine via Syncthing or Shared Folders. That approach worked but he found it unnecessarily complex and too resource-heavy for what amounts to a containment layer for a CLI tool. He subsequently discovered Tart, built by Cirrus Labs as a CLI wrapper on top of the Apple Virtualization framework, and wrote up the four-step process for cloning an Ubuntu image from the Cirrus Labs container registry at ghcr.io, starting the VM with a directory share, SSHing in, and mounting the virtiofs share inside the guest.

How it works

The post is unusual in its candor about the threat model: the sandbox protects the host operating system and the parts of the filesystem not explicitly shared, but the shared directories themselves remain writable by the agent unless the caller appends the read-only flag to the share path. That distinction matters because LLM harnesses running with elevated permissions will freely modify whatever they can reach.

Tart clones a Cirrus Labs Ubuntu cloud image with a single command and lets you resize the guest disk before first boot. The image auto-expands its root partition on startup, so there is no manual filesystem resizing step. When you launch the VM you pass one or more "--dir" flags, each mapping a label to a host path. Tart exposes all of those shares inside the guest as a single virtiofs device tagged with the identifier "com.apple.virtio-fs.automount". Because Linux does not auto-mount virtiofs shares the way macOS guests do, you manually mount the device to a path such as "/mnt/shared" inside the VM after SSHing in.

Why it matters

To survive reboots, you add an fstab entry with the "nofail" option, which prevents the VM from hanging at boot if you start it without any "--dir" flags attached. From that point the harness runs inside the isolated guest, installs packages, executes code, and browses the network freely, while the host MacBook is shielded at the hypervisor boundary. Developers can also forward specific ports, such as 8080 or 3000, from the VM back to localhost via SSH local forwarding so that web servers started by the agent are reachable from the host browser.

Running LLM harnesses with flags like "--dangerously-skip-permissions" on a primary laptop has always carried real risk: a hallucinated shell command can delete a home directory, an agent hunting for credentials can read SSH keys, and package installs can leave residue that is difficult to audit or roll back. Docker containers address part of this, but Aleem argues the Tart VM is more ergonomic for iterative development because its disk persists like a normal machine. You install a tool once and it stays installed; there is no image layer to commit or container to rebuild.

Tart runs natively on Apple Silicon by delegating to the Apple Virtualization framework rather than emulating x86, which avoids the performance and battery overhead of heavier hypervisors. VMware Fusion, Aleem's previous solution, introduces more processes and resource consumption than the setup requires. The lightweight footprint matters when the VM is meant to run long agentic sessions in the background while the developer continues other work on the host.

Who is affected

Any developer on Apple Silicon who uses Claude CLI, Codex, or comparable autonomous coding harnesses stands to benefit from this pattern. The setup is particularly relevant for people who have been avoiding the full autonomous mode of these tools because they were unwilling to run unrestricted agent sessions on their primary MacBook. It is equally useful for knowledge workers running file-based workflows with LLMs, such as the Obsidian-based personal knowledge base workflow that Aleem described in his earlier post from the same blog.

Aleem also notes in the article's conclusion that Cirrus Labs, the company behind Tart, is now part of OpenAI, leading him to speculate that the ChatGPT desktop and Codex desktop apps may already use Tart internally for sandboxing. If that assumption is accurate, the same containment mechanism now used by individual developers following this guide may underpin the isolation model in those commercial products, though this is not confirmed by either OpenAI or Cirrus Labs.

What to watch next

Builders adopting this setup should verify two things before using it for sensitive work. First, confirm that the fstab "nofail" entry is present and correct by running the mount validation commands Aleem includes in the post; without it, starting the VM without the directory share will cause the guest to stall at boot. Second, decide explicitly whether each shared directory should be writable or read-only by passing the ":ro" suffix on the host path. The post makes clear that the agent has full write access to any share not explicitly marked read-only, so a careless mount of a source repository gives the harness unlimited power over that code.

The pattern also has an open question around network isolation. The VM inherits normal outbound network access, meaning an agent with "--dangerously-skip-permissions" can still make arbitrary internet requests, exfiltrate data, or install packages from any registry. Developers who want a tighter boundary should look at whether Tart or the Apple Virtualization framework exposes network filtering controls, or combine the VM approach with a DNS-blocking or egress-filtering layer. The Tart project's documentation and the Cirrus Labs GitHub organization are the right places to track any updates to those capabilities.