Docker Sandboxes für die Ausführung von Coding-Agents

Docker Sandboxes führt einen Coding-Agent wie Claude Code, Codex, Copilot oder Cursor in einer lokalen MicroVM aus. Die MicroVM verfügt über einen eigenen Kernel und eine eigene Docker Engine, teilt mit dem Host ausschließlich Ihr Projektverzeichnis, und die lokale Nutzung ist kostenlos.

Wer an einem einzigen Nachmittag hundertmal ls- und npm test-Abfragen bestätigt hat, kennt die Versuchung des „Skip Permissions“-Flags. Und wahrscheinlich auch die Sorge, was der Agent mit dem eigenen Laptop anstellen könnte, sobald dieses Flag aktiv ist.

Dieser Artikel zeigt, was die Sandbox isoliert, wie Sie sie von der Installation bis zur ersten Session einrichten, wie Sie die Änderungen des Agents wieder herausbekommen, wie sie im Vergleich zu anderen Optionen abschneidet und was sie kostet. Das Tool hat noch keine Version 1.0 erreicht und entwickelt sich weiterhin schnell.

Warum volle Autonomie auf dem eigenen Laptop riskant ist

Ein Coding-Agent im Vollautonomie-Modus führt Shell-Befehle aus, installiert Pakete und bearbeitet Dateien, ohne nachzufragen – und zwar unter Ihrem Benutzerkonto. Ihr Home-Verzeichnis, Ihre SSH-Keys, Cloud-Credentials und lokalen Dienste liegen damit allesamt in Reichweite. Ein einziges falsches rm -rf oder git reset --hard kann nicht committete Arbeit vernichten.

Bestätigungsabfragen sind die übliche Schutzmaßnahme, widersprechen aber dem eigentlichen Zweck eines Agents. Lange Aufgaben halten bei jedem Befehl an, und nach der zwanzigsten Abfrage bestätigen die meisten, ohne noch zu lesen. Besser ist es, den Agent an einen Ort zu verlagern, an dem er wenig Schaden anrichten kann, statt ihm mehr zu vertrauen. Die grundsätzlichen Argumente für die Isolation von Agents behandelt der Artikel running coding agents in YOLO mode safely. Dieser Artikel konzentriert sich auf ein konkretes Tool.

Warum Docker Sandboxes auf eine MicroVM statt auf einen Container setzen

Ein regulärer Docker-Container teilt sich den Kernel mit dem Host. Jeder Prozess, der den Docker-Socket erreicht, kann einen privilegierten Container starten, der Ihr Dateisystem mountet. Die Docker-eigene Dokumentation zur Angriffsfläche des Daemons warnt, dass der Daemon als root läuft und nur vertrauenswürdige Benutzer ihn steuern sollten. Agents benötigen häufig Docker, und die naheliegende Abkürzung, /var/run/docker.sock zu mounten, übergibt ihnen die gesamte Maschine.

Laut Dockers Dokumentation zu den Isolationsebenen ist jede Sandbox eine MicroVM mit eigenem Linux-Kernel und eigener Docker Engine. Der Agent kann innerhalb der Sandbox docker build und docker run ausführen, ohne das privilegierte Setup, das Docker-in-Docker erfordert – und der Daemon Ihres Hosts ist zu keinem Zeitpunkt beteiligt.

Eine Docker Sandbox von Anfang bis Ende einrichten

Installieren Sie die sbx-CLI, melden Sie sich bei Docker an, stellen Sie dem Agent Credentials für das Modell bereit und führen Sie dann sbx run in Ihrem Projektverzeichnis aus. Das offizielle Tutorial weist darauf hin, dass auf Ihrem Host weder Docker Desktop noch Docker Engine benötigt werden.

Installieren Sie mit dem Befehl für Ihr Betriebssystem:

# macOS
brew trust docker/tap && brew install docker/tap/sbx

# Windows
winget install Docker.sbx

# Ubuntu: add Docker's apt repo, install, then grant KVM access
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm

Unter Linux wird KVM benötigt, und Ihr Benutzer muss Mitglied der Gruppe kvm sein. Docker testet und unterstützt sbx unter Ubuntu. Für andere Distributionen stellt das sbx-releases-Repository Release-Dateien bereit, Docker garantiert jedoch nicht, dass diese Distributionen funktionieren. Die Plattformvoraussetzungen finden Sie auf der Installationsseite.

Starten Sie anschließend eine Claude-Code-Session:

sbx login
sbx secret set anthropic        # skip if you use a Claude subscription
cd ~/my-project
sbx run --name my-project claude

• API-Key: sbx secret set anthropic speichert den Key auf Ihrem Host. Der Sandbox-Proxy fügt ihn den API-Requests des Agents hinzu, sodass der Agent den Key nie im Klartext zu sehen bekommt. Für Codex verwenden Sie sbx secret set openai. Wenn Sie den Key bereits in Ihrer Shell exportiert haben, listet sbx secret import --dry-run die Keys auf, die sbx sehen kann, und sbx secret import speichert sie, nachdem Sie jeden einzeln bestätigt haben.
• Abonnement: Sie benötigen kein Secret. Bei Claude geben Sie /login ein, nachdem Claude Code in der Sandbox gestartet ist. Bei Codex führt sbx zunächst die OpenAI-Anmeldung auf Ihrem Host durch und erstellt erst danach die Sandbox.

Beim ersten Start fordert sbx Sie auf, eine Standard-Netzwerk-Policy auszuwählen. Danach startet der Agent in seinem Vollautonomie-Modus – Claude Code fragt also nicht nach Berechtigungen, und Sie müssen kein Flag übergeben. Für einen anderen Agent ersetzen Sie claude durch codex, copilot, cursor oder gemini.

Ihr Projektordner ist der einzige Teil Ihres Rechners, in den der Agent schreiben kann – und dort kann er alles löschen. Committen oder pushen Sie also, bevor Sie loslegen.

Wie bekommen Sie die Arbeit des Agents heraus?

Im Standardmodus erscheinen die Änderungen eines Agents in einer Docker Sandbox sofort im Working Tree auf Ihrem Host. Prüfen Sie sie so, wie Sie es gewohnt sind:

git diff

Ältere Anleitungen, darunter Dockers Quickstart-Beispiel-Repository, zeigen ein --branch-Flag, das den Agent auf einem hostseitigen Worktree unter .sbx/ arbeiten ließ. Dieses Flag wurde in sbx v0.31.0 zugunsten des Clone-Modus entfernt. Wird es dennoch übergeben, erscheint eine Fehlermeldung mit dem Hinweis, stattdessen --clone zu verwenden.

Der Clone-Modus hält den Agent von Ihrem Working Tree fern. Wie die Git-Workflow-Dokumentation erläutert, erstellt sbx innerhalb der Sandbox einen privaten Git-Clone, und der Agent arbeitet auf dieser Kopie. Auf Ihrem Host ändert sich nichts, bis Sie den Branch des Agents fetchen oder der Agent auf ein Remote pusht. Der Clone-Modus lässt sich nur beim Erstellen einer Sandbox wählen, übergeben Sie --clone also gleich beim ersten Aufruf. Eine bestehende Sandbox kann nachträglich nicht umgestellt werden.

Praktische Fragen

Welche Netzwerk-Policy sollte ich wählen?

Docker Sandboxes bietet drei lokale Netzwerk-Policies:

• Open erlaubt sämtlichen Traffic.
• Balanced blockiert Traffic standardmäßig, erlaubt aber gängige Entwicklungsdienste.
• Locked Down blockiert alles, was Sie nicht ausdrücklich freigeben.

Für die meisten Frontend-Aufgaben ist Balanced die richtige Wahl. Diese Policy deckt Paket-Registries, Code-Hosting-Plattformen und die APIs der KI-Anbieter ab. Benötigt Ihr Agent eine Website, die nicht auf der Liste steht – etwa eine Dokumentationsseite –, prüfen Sie mit sbx policy check network <domain>, ob sie blockiert ist, und geben Sie sie anschließend mit sbx policy allow network <domain> frei. Mit sbx policy ls zeigen Sie Ihre Regeln an, mit sbx policy rm entfernen Sie eine Regel. Integrierte Agent-Kits können zudem pro Sandbox eigene Allow-Regeln hinzufügen, selbst unter Locked Down.

Bleibt der Zustand erhalten?

Ja. Die vom Agent installierten Tools und alle Änderungen am Betriebssystem bleiben in der Sandbox erhalten, bis Sie sie entfernen. sbx rm my-project löscht die Umgebung sowie alle Secrets, die auf diese Sandbox beschränkt sind. Ihre globalen Secrets und Ihr Projektordner bleiben unangetastet.

Wie verbinde ich mich erneut?

Um sich erneut mit einer bestehenden Docker Sandbox zu verbinden, führen Sie sbx run --name my-project aus. Den Namen des Agents müssen Sie nicht wiederholen, da er aus der bestehenden Sandbox ausgelesen wird. Wenn Sie sbx ohne Argumente ausführen, öffnet sich ein interaktives Dashboard.

Docker Sandboxes im Vergleich zu Containern, Devcontainern und Remote-VMs

Jede Alternative verzichtet auf mindestens einen von drei Aspekten: Kernel-Isolation, sicheren Docker-Zugriff oder eine integrierte Egress-Policy.

Wenn es Ihnen eigentlich darum geht zu steuern, welche Tools ein Agent aufrufen darf, statt seine Umgebung zu isolieren, lesen Sie Docker MCP for AI agents.

Grenzen und Kosten von Docker Sandboxes

Lokale Sandboxes sind kostenlos. Laut den Release Notes zu v0.45.0 sind Cloud-Sandboxes experimentell und setzen ein aktives Abonnement der Docker Agentic Platform voraus. Die Modell-Inferenz bezahlen Sie über Ihren eigenen Key oder Ihr eigenes Abonnement. Für sbx login benötigen Sie einen Docker-Account. Das Produkt ist noch jung, Preise und Flags können sich also ändern.

• Das Projektverzeichnis ist vollständig beschreibbar, nicht committete Arbeit ist daher nicht geschützt.
• Alles, was der Agent pusht oder an eine erlaubte Domain sendet, verlässt die Sandbox.
• Ressourcen legen Sie mit --memory und --cpus fest. Lokal entspricht der Standardwert für den Arbeitsspeicher der Hälfte des Host-RAMs, maximal 32 GiB. Der dokumentierte Standardwert von 2 CPUs und 4 GiB gilt für Cloud-Sandboxes.
• SSH-Commit-Signing funktioniert über SSH-Agent-Forwarding, das standardmäßig aktiv ist, wenn SSH_AUTH_SOCK auf Ihrem Host gesetzt ist. Git innerhalb der Sandbox müssen Sie jedoch weiterhin so konfigurieren, dass es mit dem weitergeleiteten Key signiert.
• Andrew Lock berichtete im April 2026, dass die Ausführung in einer Sandbox selbst einfache Projekte erheblich verlangsamte.

Fazit

Docker Sandboxes gibt einem Coding-Agent einen eigenen Kernel, eine eigene Docker Engine und ein per Policy gesteuertes Netzwerk – und der einzige Teil Ihres Rechners, auf den er zugreifen kann, ist Ihr Projektordner. Für den Einstieg committen Sie Ihre Arbeit, installieren sbx, wählen Balanced und führen sbx run --name my-project claude in einem Repository aus, dessen Verlust Sie verschmerzen können. Wechseln Sie in den Clone-Modus, wenn die Änderungen des Agents bis zu Ihrem Review von Ihrem Working Tree ferngehalten werden sollen.

FAQs

Wie öffne ich einen Dev-Server, den der Agent innerhalb einer Docker Sandbox startet?

Veröffentlichen Sie seinen Port mit sbx ports. sbx ports my-project --publish 3000:8080 mappt den Host-Port 3000 auf den Sandbox-Port 8080, während --publish 8080 allein einen ephemeren Host-Port wählt. Ihr Browser kann Dienste innerhalb der Sandbox erst erreichen, wenn Sie dies getan haben. Außerdem muss der Dev-Server an 0.0.0.0 statt an 127.0.0.1 binden, weshalb viele Frameworks ein --host 0.0.0.0-Flag benötigen.

Kann der Agent andere Verzeichnisse lesen, ohne sie verändern zu können?

Ja. Fügen Sie nach dem Haupt-Workspace weitere Pfade hinzu und hängen Sie an jeden :ro an, um ihn schreibgeschützt einzubinden, zum Beispiel sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro. Der Agent startet im ersten Pfad. Jeder Workspace erscheint innerhalb der Sandbox unter demselben absoluten Pfad wie auf Ihrem Host. Zusätzliche Workspaces werden direkt vom Host gemountet, auch wenn der Haupt-Workspace den Clone-Modus verwendet.

Wie bekomme ich Commits aus einer Sandbox im Clone-Modus heraus?

Fetchen Sie sie von dem Git-Remote, das sbx Ihrem Host-Repository hinzufügt und das den Namen sandbox- plus den Namen der Sandbox trägt. Anschließend können Sie wie bei jedem anderen Remote diffen oder mergen. Der Git-Server für den Clone läuft innerhalb der Sandbox, daher schlägt git fetch fehl, solange die Sandbox gestoppt ist. sbx rm entfernt auch dieses Remote – fetchen oder pushen Sie also alles, was Sie behalten möchten, bevor Sie die Sandbox entfernen.