KI-Coding-Agenten in der Sandbox auf dem Mac mini M4: Tart-VMs, Apple container und der Speicher, den sie brauchen

Warum ein unbeaufsichtigter Coding-Agent überhaupt eine Sandbox braucht

Das Risiko ist nicht, dass das Modell böswillig ist; es ist, dass der Agent Befehle auf einer Codebasis ausführt, die er nicht geschrieben hat und nicht vollständig prüfen kann, manchmal mit abgeschalteten Berechtigungsabfragen, damit er die Nacht über unbeaufsichtigt weiterarbeiten kann. Ein Projekt mit einem per Prompt-Injection präparierten Kommentar, einer kompromittierten Abhängigkeit oder einem Build-Skript, das mehr tut als bauen, kann den gewöhnlichen Datei- und Shell-Zugriff eines Agenten zum Zugriff eines Fremden machen, auf alles, was diese Anmeldesitzung erreicht: SSH-Schlüssel, Browser-Cookies, Cloud-Zugangsdaten, den Rest des Dateisystems.

Den Agenten in eine virtuelle Maschine zu setzen, statt ihn direkt auf dem Gerät laufen zu lassen, das man jeden Tag nutzt, macht ein bösartiges Projekt nicht harmlos, verkleinert aber, was es erreicht. Was die Sitzung des Agenten berühren kann, endet am eigenen Laufwerk der VM und an ihrem eigenen, bewusst schmalen Netzwerkzugang, statt bis zu den Schlüsseln und dem Verlauf des Host-Accounts zu reichen.

Warum eine VM, und warum auf einem ständig laufenden Mac mini

Eine virtuelle Maschine startet unter Apples Virtualization-Framework ihren eigenen Kernel; ein Prozess, der aus dem Account des Agenten im Gast ausbricht, muss noch aus diesem Gast-Kernel ausbrechen, bevor er den Host überhaupt erreicht. Ein Container teilt sich absichtlich den Kernel des Hosts; das ist eine leichtere und schnellere, aber dünnere Grenze. Keines von beiden verspricht perfekte Abschottung, und der Abschnitt zu den Einschränkungen unten zeigt, wo die Isolation jeweils tatsächlich endet.

Ein Notebook, das für einen nächtlichen Agentenlauf offen, wach und verbunden bleiben muss, macht den Sinn eines unbeaufsichtigten Agenten zunichte. Dasselbe Argument, das einen Mac mini M4 zur Basis für KI-Programmierung aus der Ferne macht, gilt hier: Eingesteckt und immer an, kann er einen Agenten in der Sandbox weiterlaufen lassen, lange nachdem das Notebook, von dem aus er gestartet wurde, zugeklappt ist.

Tart: macOS- und Linux-Gäste auf Apples eigenem Virtualisierungs-Framework

Tart betreibt virtuelle Maschinen mit macOS und Linux auf Apples Virtualization-Framework, statt Hardware zu emulieren; dadurch läuft ein macOS-Gast auf Apple Silicon nahezu mit nativer Geschwindigkeit. Das Laden des Standard-Basis-Images für macOS „will download a 25 GB image“; ein Linux-Basis-Image ist leichter, mit „a minimal disk size of 20 GB“ (github.com/openai/tart, docs/quick-start.md, geprüft im September 2026). Die Dateien einer VM liegen unter ~/.tart/vms/<name>/, und aus einer Registry geladene Images werden unter ~/.tart/cache/OCIs/ zwischengespeichert, beides über die Umgebungsvariable TART_HOME verlegbar (tart.run FAQ, geprüft im September 2026).

Eine VM zu klonen, um einen zweiten Agenten in eine Sandbox zu setzen oder einen auf einen bekannt sauberen Zustand zurückzusetzen, kopiert nicht vorab das ganze Laufwerk: Tarts eigener Klon-Code hält fest, dass „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, geprüft im September 2026), weil der Klon seine Datenblöcke auf APFS mit dem Basis-Image teilt, bis einer von beiden in einen geteilten Block schreibt. Tart räumt seinen Image-Cache zudem bei jedem Klonen oder Laden automatisch auf, standardmäßig sobald der Cache 100 GB überschreitet, einstellbar oder abschaltbar mit TART_NO_AUTO_PRUNE (gleiche Quelle; tart.run FAQ, geprüft im September 2026).

Wer zwei oder mehr macOS-Gäste betreibt, ob in der Sandbox oder nicht, stößt an Apples eigene Lizenz, bevor der Speicher knapp wird: Die Softwarelizenz von macOS Tahoe erlaubt „up to two (2) additional copies or instances“ von macOS in virtuellen Maschinen auf einem lizenzierten Mac, für Entwicklung, Tests oder persönliche, nicht kommerzielle Nutzung (apple.com/legal/sla, docs/macOSTahoe.pdf §2B(iii), geprüft im September 2026). Apples eigene Entwicklerforen beschreiben, dass Virtualization.framework dieselbe Grenze von zwei Gästen auch in der Software durchsetzt, nicht nur im Lizenztext (developer.apple.com/forums, Thread 729580, geprüft im September 2026). Die Grenze gilt speziell für macOS-Gäste; die Linux-Gäste von Tart betrifft sie nicht.

Tart selbst hat 2026 den Besitzer gewechselt: Das GitHub-Repository des Projekts leitet jetzt von cirruslabs/tart auf openai/tart weiter, unter derselben Repository-ID, und seine Lizenzdatei ist die Functional Source License („FSL-1.1-ALv2“), Copyright OpenAI (github.com/openai/tart, LICENSE, geprüft im September 2026). Eine FSL-Lizenz geht nach einer festen Zahl von Jahren in die freizügige Apache-2.0-Lizenz über und schließt bis dahin nur „Competing Use“ aus, also die Software als bezahlte Alternative zum eigenen Angebot von OpenAI zu betreiben. Gewöhnliche Nutzung, einschließlich einer Sandbox für einen Coding-Agenten, ist davon nicht betroffen.

Eine VM als Sandbox mit Tart einrichten

Tart wird als Homebrew-Formel installiert; wer das Basis-Image einmal klont und den Klon startet, lässt das ursprüngliche Image für den nächsten Klon unberührt.

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

Die Standardanmeldung eines frischen macOS-Gasts ist der Account admin mit dem Passwort admin (github.com/openai/tart, docs/quick-start.md, geprüft im September 2026). Ändern Sie es, bevor Sie etwas installieren, unter dem ein unbeaufsichtigter Agent laufen soll. Vom Host aus gibt tart ip agent-sandbox-1 die Adresse des Gasts in Apples privatem virtuellem Netzwerk aus, und ein einfaches ssh erreicht ihn von dort:

In den Gast gelangen und den Agenten installieren

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

Installieren Sie die Kommandozeile des Coding-Agenten und nur dessen eigenen API-Schlüssel oder OAuth-Token im Gast, nicht die des Hosts. Ein zweiter Klon (tart clone ghcr.io/cirruslabs/macos-tahoe-base:latest agent-sandbox-2) ergibt eine zweite, unabhängige Sandbox für ein zweites Projekt, bis zur oben genannten Grenze von zwei macOS-Gästen; ein Linux-Basis-Image statt des macOS-Images hat keine solche Grenze und ist die leichtere Wahl, wenn die Werkzeuge des Agenten macOS selbst nicht brauchen.

Leichtere Optionen: Apples container und die Devcontainer von Claude Code

Eine vollständige VM mit macOS oder Linux ist nicht der einzige Weg, einem Agenten einen engeren Rahmen als den Host-Account zu geben. Apples eigenes Werkzeug container, „supported on macOS 26“ auf einem „Mac with Apple silicon“ (github.com/apple/container, README, geprüft im September 2026), führt „Linux containers as lightweight virtual machines on your Mac“ aus (gleiche Quelle). Jeder Container bekommt seine eigene schlanke VM, statt sich wie bei Docker einen Host-Kernel zu teilen; das ist ein Mittelweg zwischen einem vollständigen Tart-Gast und einem Container mit geteiltem Kernel.

Die Devcontainer-Unterstützung von Claude Code führt den Agenten stattdessen in einem normalen, auf Docker basierenden Entwicklungscontainer aus. Der isoliert das Dateisystem und kann ausgehenden Netzwerkverkehr einschränken, aber die Dokumentation von Claude Code sagt ausdrücklich, wo diese Isolation endet: „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, geprüft im September 2026). Ein Devcontainer hält einen Agenten vom Dateisystem des Hosts fern; er verhindert allein nicht, dass ein kompromittiertes Projekt liest und hinausschickt, was der Container selbst enthält, Zugangsdaten eingeschlossen.

Welche der drei passt, hängt davon ab, wogegen die Sandbox schützen soll: ein Devcontainer für die tägliche Arbeit an einem vertrauenswürdigen Repository mit unbeaufsichtigten Berechtigungen, Apples container für eine leichtere Linux-Sandbox, die auf einem Mac mit macOS 26 schon verfügbar ist, und eine vollständige Tart-VM für die stärkste Isolation oder für ein Projekt, das als nicht vertrauenswürdig und nicht nur als unbeaufsichtigt behandelt werden muss.

Den Agenten von überall erreichen

Nichts davon verlangt, dass die Sandbox an einem Schreibtisch vor jemandem steht: Dasselbe Setup mit Tailscale, mosh und herdr, das einen direkt auf einem Mac mini M4 laufenden Agenten erreicht, erreicht auch einen in einem Tart-Gast, weil der Gast im Netzwerk des Hosts eine eigene Adresse bekommt. Richten Sie mosh oder herdrs Remote-Option auf die Tart-IP des Gasts oder, sobald Tailscale im Gast selbst installiert ist, auf seinen Tailscale-Gerätenamen, und der Agent in der Sandbox bleibt über Ruhezustand, Netzwechsel und ein zugeklapptes Notebook hinweg erreichbar, genau wie ohne Sandbox.

Warum das ein Laufwerk schneller füllt als ein einzelner Agent direkt

Umsonst ist das alles nicht: Jeder Gast in einer Sandbox ist eine weitere Kopie eines Betriebssystems, und ein Basis-Image, das sich mehrere Klone teilen, bleibt nur so lange günstig, wie die Klone übereinstimmen. Jede Zeile unten ist unsere eigene Planungsschätzung für einen so genutzten Mac mini M4, aufgebaut aus den oben belegten Download-Größen plus einem Zuschlag für abweichende Klone und Caches, für den es keinen veröffentlichten Wert gibt; es ist keine Messung eines bestimmten Geräts.

Das sind nach unserer Schätzung 150 GB, bevor die Projekte in den Sandboxes selbst Platz belegen: 106 GB Rest bei 256 GB, 362 GB bei 512 GB, 1850 GB bei 2 TB. Alle Optionen nebeneinander zu betreiben, ist die Obergrenze, nicht der Plan; wer für ein echtes Setup eine oder zwei davon wählt, behält deutlich mehr dieser Reserve. Wenn Ihr M4 im Basismodell mehrere Sandboxes und Projekte halten soll, vergleichen Sie das interne 2-TB-Modul mit Ihrer gemessenen Belegung, bevor Sie das Setup aufbauen.

Die ehrlichen Einschränkungen

• Eine Sandbox verkleinert, was ein kompromittiertes Projekt erreichen kann; sie macht ein nicht vertrauenswürdiges Projekt nicht sicher, wenn alle Schutzvorkehrungen abgeschaltet sind. Die Devcontainer-Dokumentation von Claude Code sagt das direkt: Kein System hier ist „completely immune to all attacks“ (code.claude.com, docs/en/devcontainer, geprüft im September 2026).
• Die Grenze von zwei Gästen in der macOS-Lizenz ist real und gilt pro lizenziertem Mac, nicht pro Sandbox: Ein dritter macOS-Gast, ob mit Agent in der Sandbox oder nicht, liegt außerhalb der Lizenzbedingungen, auch wenn auf dem Laufwerk Platz dafür wäre (apple.com/legal/sla, docs/macOSTahoe.pdf §2B(iii), geprüft im September 2026). Linux-Gäste, in Tart oder in Apples container, fallen nicht unter diese Grenze.
• Tarts Lizenz FSL-1.1-ALv2 ist heute keine Open-Source-Lizenz, sondern nur eine Source-Available-Lizenz, die nach ihrem Stichtag in Apache 2.0 übergeht; den Ausschluss „Competing Use“ sollten Sie vollständig lesen, bevor Sie einen bezahlten Dienst darauf aufbauen (github.com/openai/tart, LICENSE, geprüft im September 2026).
• Kein Hersteller veröffentlicht die entpackte Größe eines abgewichenen macOS-Klons auf dem Laufwerk oder den Speicherpfad der Images von Apples container; beide Zeilen in der Tabelle oben sind unsere Planungsschätzung, kein gemessener Wert, und beide können auf einem Gerät höher ausfallen, das viele abgewichene Klone behält, statt sie zu löschen und neu zu klonen.