Docker Sandboxes: Das 1x1 für isolierte AI Coding Agents

Ein AI Coding Agent ist nur dann wirklich nützlich, wenn er auch ausführen darf, was er vorschlägt. Tests laufen lassen, npm install, ein Migrations-Script starten, vielleicht sogar einen Container bauen. Und genau da fängt das Unbehagen an: Wir geben einem Modell, das gerne mal halluziniert, Schreibzugriff auf unser System.

Klassisches Docker hilft da nur teilweise. Auf Linux teilt sich ein Container den Kernel mit dem Host. Auf macOS und Windows läuft Docker selbst zwar schon in einer Linux-VM, also ist da ohnehin eine Trennschicht dazwischen. Im Prinzip dieselbe Technologie wie sbx. Aber unabhängig vom Host: Sobald der Agent im Container selbst Container bauen darf, müsste man entweder den Docker-Socket reinmounten (Root-Zugriff auf den Host) oder Docker-in-Docker spielen. Für reines Container-Bauen gibt es auch rootless Alternativen wie Kaniko oder Podman. dotnet publish baut sogar ganz ohne Engine. Die schieben das Problem aber nur ein Stück weiter: Das eigentliche Sandboxing für Netzwerk, Filesystem und Prozesse muss man immer noch selbst lösen.

Docker hat dafür seit kurzem Docker Sandboxes (sbx) im Early Access. Kurz gesagt: Eine microVM mit eigenem Docker-Daemon, in die man den Coding Agent reinwirft. Im Folgenden erzähle ich mein 1x1, wie ich mir das in der Praxis erschlossen habe.

Was sbx anders macht

Der Agent läuft in einer microVM, nicht in einem Container. Wenn der Agent etwas Dummes anstellt, wie den Home-Folder löschen, bleibt das in der VM. Die Host-Maschine kann nicht korrumpiert werden, weil der Agent sie schlicht nicht erreicht.

Die VM bringt ihren eigenen Docker-Daemon mit. Der Agent kann also docker build und docker run, ohne den Host-Daemon anzufassen. Kein Socket-Mount nötig, kein Privileged-Container-Trick. Wer mit dem Agent gar nicht erst Docker verwendet, profitiert trotzdem von der microVM-Schicht. Globale npm install, apt-Pakete, ~/.config-Schreibereien oder curl | sh-Installer landen in der VM und nicht auf dem Host.

Der Workspace wird per Filesystem-Passthrough gemountet. Pfade bleiben gleich, Änderungen sind sofort auf beiden Seiten sichtbar. Klingt nach Detail, ist aber wichtig: Stacktraces und Tool-Konfigurationen würden sonst auf Pfade zeigen, die es auf dem Host gar nicht gibt.

Netzwerk und Credentials

Ein Aspekt, den ich beim ersten Hinschauen unterschätzt habe: Der Agent darf nicht einfach so ins Netz. Der gesamte HTTP/HTTPS-Verkehr läuft über einen Proxy auf dem Host. Der Proxy macht zwei Dinge.

Erstens setzt er eine Allowlist durch. Default-Policy ist Balanced, also typische Developer-Domains sind erlaubt, der Rest wird blockiert. Wer vorsichtiger unterwegs ist, nimmt den Locked Down Modus und gibt jeden Zugriff einzeln frei.

Zweitens injiziert er Credentials für Drittsysteme erst beim Verlassen der VM: GitHub-Token für git push, Container-Registry-Logins, MCP-Server-Keys, Anthropic-API-Token. Die rohen Secrets landen nie in der Sandbox. Der Agent sieht nur die Antworten, nicht die Authorization-Header.

Raw TCP, UDP und ICMP sind grundsätzlich blockiert. Wer einen MCP-Server nutzt, der direkt mit einer Datenbank reden soll, muss umdenken oder den HTTP-Endpoint nutzen.

Quickstart

Auf macOS:

brew install docker/tap/sbx
sbx login

Dann im Projektverzeichnis:

sbx run claude

Das war’s. Beim ersten Start wählt man die Netzwerk-Policy, die microVM bootet, Claude Code startet und sieht das Projekt unter dem gleichen Pfad wie auf dem Host.

Stoppen mit sbx stop, wegwerfen mit sbx rm. Solange man nichts löscht, bleiben installierte Pakete und der Docker-Image-Cache im Sandbox erhalten.

Wo es bei mir gehakt hat

Drei Dinge, die in der Doku entweder fehlen oder leicht zu übersehen sind.

Das Base-Image-Template (docker/sandbox-templates:claude-code) hinkt den Claude-Code-Releases gerne ein paar Versionen hinterher. Wer immer auf der aktuellsten Version sein will, muss das Image nicht von Grund auf neu bauen. Es reicht, das offizielle als Basis zu nehmen und Claude nachzuziehen:

FROM docker/sandbox-templates:claude-code
RUN npm install -g @anthropic-ai/claude-code@latest

Projekt-MCP-Server brauchen ihre Runtimes (npx, uvx, pipx) in der VM. Im Default-Template ist das drin. Sobald man aber ein eigenes Template baut und die Runtimes vergisst, startet kein einziger MCP-Server mehr. Die Fehlermeldung ist wenig sprechend, zum Beispiel spawn uvx ENOENT aus dem MCP-Logger, ohne Hinweis darauf, dass schlicht das Binary fehlt.

Eigenes Template, eigener Wrapper

Für unseren Alltag bei nxt habe ich einen kleinen Wrapper um sbx gebaut, der das Default-Template um drei Dinge ergänzt: MCP-Runtimes vorinstalliert, eine optionale CLI (glab oder gh) inklusive PAT-Bootstrap für den Zugriff auf den Issue-Tracker und Auto-Detection der Projekt-Sprache. Die Java-Version wird aus pom.xml gezogen, die .NET-Version aus global.json, die Node-Version aus .nvmrc.

Im Alltag sieht das so aus:

cd ~/some/project
sbox                          # baut das Template einmalig, startet dann claude
sbox . -- --continue          # extra Flags für claude nach --
sbox --build --lang java --lang-version 17    # Template mit Temurin 17

Der Nutzen im Team: Wer das Projekt klont und sbox startet, hat die ganze Toolchain reproduzierbar in einer microVM, ohne dass jemand auf dem Host etwas installieren muss. Auch der Issue-Tracker-Login ist bereits erledigt, sofern ein Password-Manager (1Password, Proton Pass, Bitwarden) auf dem Host konfiguriert ist.

Wann lohnt sich der Aufwand?

Sobald man dem Agent erlaubt, Pakete zu installieren oder Befehle auszuführen, lohnt sich die VM-Schicht. Die Alternative auf dem Host wäre, jede einzelne Aktion durchzunicken, oder gleich den Bypass-Permissions-Modus zu fahren, in dem Claude Code überhaupt nicht mehr nachfragt. Die Erstere erfordert ständiges Babysitting, während vom Bypass-Permissions-Modus ohne entsprechendes Sandboxing von Anthropic selber streng abgeraten wird.

Für reine Code-Review-Sessions, bei denen der Agent nur liest und Vorschläge macht, ist sbx overkill. Für alles Andere ist es derzeit die bequemste Antwort auf die Frage, wie ich einem Agenten eine Umgebung gebe, in der er selbstständig arbeiten kann, ohne mein eigenes System zu gefährden.

sbx ist noch early access, und das heisst: Es gibt noch Ecken. Aber das Modell aus microVM, eigenem Docker-Daemon und Host-Proxy ist das, was ich bei der Kombination von Docker plus Coding Agent vorher vermisst habe.