Sandboxed AI-codeeragents op een Mac Mini M4: Tart-VM's, Apple container en de opslag die ze kosten

Waarom een onbeheerde codeeragent überhaupt een sandbox nodig heeft

Het risico is niet dat het model kwaadaardig is; het is dat de agent commando's uitvoert tegen een codebase die hij niet zelf geschreven heeft en niet volledig kan controleren, soms met permissieprompts uitgeschakeld zodat hij 's nachts onbeheerd kan doorwerken. Een project met een prompt-geïnjecteerd commentaar, een gecompromitteerde dependency, of een buildscript dat meer doet dan bouwen, kan de gewone bestands- en shell-toegang van een agent omzetten in de toegang van iemand anders, tot alles wat die inlogsessie kan bereiken: SSH-sleutels, browsercookies, cloud-credentials, de rest van het bestandssysteem.

De agent in een virtuele machine zetten in plaats van hem direct te draaien op de machine die je elke dag gebruikt, maakt een kwaadaardig project niet onschadelijk, maar het verkleint wat het kan bereiken. Wat de sessie van de agent kan aanraken, stopt bij de eigen schijf van de VM en zijn eigen, bewust beperkte, netwerktoegang, in plaats van zich uit te strekken tot de sleutels en geschiedenis van het hostaccount.

Waarom een VM, en waarom op een altijd-aan Mac Mini

Een virtuele machine start zijn eigen kernel op onder Apple's Virtualization-framework; een proces dat uit het eigen account van de agent binnen de guest breekt, moet nog steeds uit die guest-kernel breken voordat het de host überhaupt bereikt. Een container deelt de kernel van de host per ontwerp, wat een lichtere en snellere grens is, maar een dunnere. Geen van beide is een garantie voor perfecte insluiting, en de kanttekeningen hieronder gaan in op waar de isolatie van elk daadwerkelijk ophoudt.

Een laptop die open, wakker en verbonden moet blijven voor een agent die 's nachts doorwerkt, ondermijnt het hele idee van een onbeheerde agent. Dezelfde reden waarom een Mac Mini M4 een basis is voor extern AI-coderen geldt hier ook: aangesloten en altijd aan kan hij een sandboxed agent nog lang laten doorwerken nadat de laptop waarmee hij gestart is, het deksel heeft dichtgeklapt.

Tart: macOS- en Linux-guests op Apple's eigen virtualisatieframework

Tart draait macOS- en Linux-virtuele machines op Apple's Virtualization-framework in plaats van hardware te emuleren, en dat is wat een macOS-guest op Apple silicon met bijna-native snelheid laat draaien. Het ophalen van het standaard macOS-basisimage "will download a 25 GB image"; een Linux-basisimage is lichter, met "a minimal disk size of 20 GB" (github.com/openai/tart, docs/quick-start.md, gecontroleerd september 2026). De bestanden van een VM staan onder ~/.tart/vms/<name>/, en images die uit een registry zijn opgehaald, worden gecachet onder ~/.tart/cache/OCIs/, beide te verplaatsen met de omgevingsvariabele TART_HOME (tart.run FAQ, gecontroleerd september 2026).

Een VM klonen om een tweede agent te sandboxen, of om er een terug te zetten naar een bekend schone staat, kopieert niet meteen de hele schijf: de eigen kloon-code van Tart merkt op dat "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, gecontroleerd september 2026), omdat de kloon zijn onderliggende blokken deelt met het basisimage op APFS totdat een van beide naar een gedeeld blok schrijft. Tart ruimt zijn eigen image-cache ook automatisch op bij elke kloon of pull, standaard zodra de cache boven de 100GB komt, aan te passen of uit te zetten met TART_NO_AUTO_PRUNE (dezelfde bron; tart.run FAQ, gecontroleerd september 2026).

Twee of meer macOS-guests draaien, sandboxed of niet, loopt eerder tegen Apple's eigen licentie aan dan tegen schijfruimte: de softwarelicentie van macOS Tahoe staat "up to two (2) additional copies or instances" van macOS toe die in virtuele machines draaien bovenop één gelicentieerde Mac, voor ontwikkeling, testen of persoonlijk niet-commercieel gebruik (apple.com/legal/sla, docs/macOSTahoe.pdf §2B(iii), gecontroleerd september 2026). Apple's eigen ontwikkelaarsforums beschrijven dat Virtualization.framework diezelfde grens van twee guests ook in software afdwingt, niet alleen in de licentietekst (developer.apple.com/forums, thread 729580, gecontroleerd september 2026). De grens geldt specifiek voor macOS-guests; Tart's Linux-guests vallen er niet onder.

Tart is in 2026 zelf van eigenaar gewisseld: de GitHub-repository van het project verwijst nu door van cirruslabs/tart naar openai/tart, onder dezelfde repository-id, en het licentiebestand is de Functional Source License ("FSL-1.1-ALv2"), copyright OpenAI (github.com/openai/tart, LICENSE, gecontroleerd september 2026). Een FSL-licentie gaat na een vaste periode over in de permissieve Apache 2.0-licentie en sluit tot die datum alleen "Competing Use" uit: de software gebruiken als betaald alternatief voor OpenAI's eigen aanbod. Gewoon gebruik, een codeeragent sandboxen inbegrepen, ondervindt daar geen hinder van.

Een sandboxed VM opzetten met Tart

Tart installeert als Homebrew-formule; het basisimage één keer klonen en de kloon draaien laat het origineel ongemoeid voor de volgende kloon.

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

De standaardinlog voor een verse macOS-guest is het account admin met wachtwoord admin (github.com/openai/tart, docs/quick-start.md, gecontroleerd september 2026) — verander dat voordat je er iets op installeert waar een onbeheerde agent onder gaat draaien. Vanaf de host toont tart ip agent-sandbox-1 het eigen adres van de guest op Apple's eigen private virtuele netwerk, en een gewone ssh bereikt hem vandaar:

De guest in en de agent installeren

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

Installeer de CLI van de codeeragent, en alleen zijn eigen API-sleutel of OAuth-token, binnen de guest, niet die van de host. Een tweede kloon (tart clone ghcr.io/cirruslabs/macos-tahoe-base:latest agent-sandbox-2) geeft een tweede, onafhankelijke sandbox voor een tweede project, tot aan de grens van twee macOS-guests hierboven; een Linux-basisimage in plaats van het macOS-image kent die grens niet en is de lichtere keuze wanneer de toolchain van de agent macOS zelf niet nodig heeft.

Lichtere opties: Apple's container en de eigen devcontainers van Claude Code

Een volledige macOS- of Linux-VM is niet de enige manier om een agent een kleinere doos te geven dan het hostaccount. Apple's eigen tool container, "supported on macOS 26" op een "Mac with Apple silicon" (github.com/apple/container, README, gecontroleerd september 2026), draait "Linux containers as lightweight virtual machines on your Mac" (dezelfde bron) — elke container krijgt zijn eigen lichte VM in plaats van één hostkernel te delen zoals de containers van Docker doen, wat een middenweg is tussen een volledige Tart-guest en een container met gedeelde kernel.

De devcontainer-ondersteuning van Claude Code draait de agent in plaats daarvan in een standaard Docker-gebaseerde ontwikkelcontainer, wat het bestandssysteem isoleert en uitgaand netwerkverkeer kan beperken, maar de eigen documentatie van Claude Code is expliciet over waar die isolatie ophoudt: "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, gecontroleerd september 2026). Een devcontainer houdt een agent van het bestandssysteem van de host af; hij houdt een gecompromitteerd project op zichzelf niet tegen om te lezen en te versturen wat de container zelf bevat, credentials inbegrepen.

Welke van de drie past, hangt af van waartegen precies gesandboxt wordt: een devcontainer voor dagelijks werk aan een vertrouwde repository met onbeheerde permissies, Apple's container voor een lichtere Linux-sandbox die al beschikbaar is op een Mac met macOS 26, en een volledige Tart-VM voor de sterkste isolatie, of voor een project dat als onbetrouwbaar behandeld moet worden in plaats van alleen onbeheerd.

De agent bereiken vanaf waar je ook bent

Niets hiervan vereist dat de sandbox aan een bureau voor iemands neus staat: dezelfde opstelling met Tailscale, mosh en herdr die een agent bereikt die direct op een Mac Mini M4 draait, bereikt er net zo goed een die binnen een Tart-guest draait, omdat de guest zijn eigen adres krijgt op het netwerk van de host. Richt mosh, of de remote-attach-vlag van herdr, op het Tart-IP van de guest, of, zodra Tailscale binnen de guest zelf is geïnstalleerd, op diens Tailscale-machinenaam, en de agent binnen de sandbox blijft net zo bereikbaar bij sluimerstand, roaming en een dichtklappend laptopdeksel als wanneer hij ongesandboxt zou draaien.

Waarom dit sneller een schijf vult dan één agent direct draaien

Niets hiervan is gratis: elke sandboxed guest is een tweede kopie van een besturingssysteem, en een basisimage dat door meerdere klonen wordt gedeeld, blijft alleen goedkoop zolang die klonen het met elkaar eens blijven. Elke rij hieronder is onze eigen planningsinschatting voor een Mac Mini M4 die op deze manier wordt gebruikt, opgebouwd uit de hierboven aangehaalde gedownloade formaten plus een afwijkingsmarge voor klonen en caches waarvoor geen gepubliceerd cijfer bestaat; het is geen meting van één specifieke machine.

Dat is 150GB volgens onze inschatting voordat de gesandboxte projecten zelf ook maar iets aan ruimte kosten: 106GB over op 256GB, 362GB op 512GB, 1850GB op 2TB. Elke optie tegelijk draaien is het plafond, niet het plan; één of twee ervan kiezen voor een echte opstelling laat aanzienlijk meer van die ruimte over.

De eerlijke kanttekeningen

• Een sandbox verkleint wat een gecompromitteerd project kan bereiken; het maakt een onbetrouwbaar project niet veilig om met alle waarborgen uit te draaien. De eigen devcontainer-documentatie van Claude Code zegt dat rechtstreeks: geen enkel systeem hier is "completely immune to all attacks" (code.claude.com, docs/en/devcontainer, gecontroleerd september 2026).
• De grens van twee macOS-guests in de licentie is reëel en geldt per gelicentieerde Mac, niet per sandbox: een derde macOS-guest, gesandboxte agent of niet, valt buiten de licentievoorwaarden, ook als er nog schijfruimte voor is (apple.com/legal/sla, docs/macOSTahoe.pdf §2B(iii), gecontroleerd september 2026). Linux-guests, in Tart of in Apple's container, vallen niet onder die grens.
• De FSL-1.1-ALv2-licentie van Tart is vandaag geen opensourcelicentie, alleen een source-available licentie die na de wijzigingsdatum overgaat in Apache 2.0; de uitsluiting van "Competing Use" is de moeite waard om volledig te lezen voordat je er een betaalde dienst omheen bouwt (github.com/openai/tart, LICENSE, gecontroleerd september 2026).
• Geen enkele leverancier publiceert het gedecomprimeerde, daadwerkelijke schijfgebruik van een afgeweken macOS-kloon of de eigen opslaglocatie van Apple's container-images; beide rijen in de tabel hierboven zijn onze planningsinschatting, geen gemeten cijfer, en beide kunnen hoger uitvallen op een machine die veel afgeweken klonen aanhoudt in plaats van ze te verwijderen en opnieuw te klonen.