Docker Sandboxes: Freilauf für Coding-Agents, ohne Risiko für den eigenen Rechner

Sandboxes sind für uns ein zentraler Baustein, sobald AI-Agenten produktiv und sicher in der Entwicklung mitarbeiten sollen. Warum das so ist, haben wir bereits im Beitrag AI Tooling Sandboxing beschrieben, in dem wir auch unser Open-Source-Tool Asylum vorstellen.

In diesem Tutorial geht es um eine weitere Lösung in diesem Feld: Docker Sandboxes.

Wer Claude Code, Codex oder Gemini CLI produktiv einsetzt, kennt das Dilemma: Entweder bestätigt man jeden einzelnen Befehl des Agenten von Hand, oder man schaltet die Sicherheitsabfragen mit --dangerously-skip-permissions ab und hofft, dass der Agent nicht gerade heute auf die Idee kommt, rm -rf im falschen Verzeichnis auszuführen oder die .env-Datei an einen fremden Server zu schicken. Docker Sandboxes will genau dieses Dilemma auflösen: Der Agent läuft mit voller Autonomie in einer microVM, aus der er nicht ausbrechen kann.

Was ist Docker Sandboxes? #

Docker Sandboxes ist ein Werkzeug von Docker Inc., das KI-Coding-Agents in isolierten, lokalen Umgebungen ausführt. Jede Sandbox ist eine eigene microVM mit eigenem Kernel, eigenem Dateisystem, eigenem Netzwerk-Stack und, das ist die Besonderheit, einer eigenen, privaten Docker Engine. Der Agent kann darin Pakete installieren, Tests ausführen, Container bauen und Compose-Stacks hochfahren, ohne dass davon irgendetwas auf dem Host-System landet.

Das Produkt wurde im November 2025 als experimentelles Feature von Docker Desktop vorgestellt und lief damals noch als Container innerhalb der Docker-Desktop-VM. Ende Januar 2026 folgte die allgemeine Verfügbarkeit mit einer grundlegend neuen Architektur: dedizierte microVMs pro Sandbox und ein eigenständiges CLI namens sbx, das Docker Desktop nicht mehr voraussetzt.

Die Technologie: microVMs statt Container #

Docker hat in einem lesenswerten Blogpost (Why MicroVMs) begründet, warum ausgerechnet der Container-Pionier für dieses Produkt nicht auf Container setzt. Die Argumentation: Volle VMs isolieren gut, starten aber langsam. Container starten schnell, aber sobald der Agent selbst Docker braucht (und das brauchen Coding-Agents ständig, um Tests in Containern laufen zu lassen oder Images zu bauen), muss man den Docker-Socket durchreichen oder privilegierte Container einsetzen, was die Isolation untergräbt. MicroVMs kombinieren das Beste aus beiden Welten: einen eigenen Kernel als hardwaregestützte Isolationsgrenze, und kurze Startzeiten, die sich wie Container anfühlen.

Docker Desktop wird ausdrücklich nicht benötigt. Nur wer eigene Templates bauen will, braucht ein docker build auf dem Host. Ein Docker-Konto ist allerdings Pflicht, da sich das sbx-CLI per sbx login authentifiziert. Das CLI ist kostenlos, auch für die kommerzielle Nutzung. Open Source ist das Produkt hingegen nicht.

Die Architektur beruht auf fünf Isolationsschichten, die in der Security-Dokumentation beschrieben sind:

1. Hypervisor-Isolation: Jede Sandbox hat einen eigenen Kernel. Ein kompromittierter Agent kann weder auf den Host noch auf andere Sandboxes zugreifen.
2. Netzwerk-Isolation: Sämtlicher ausgehender Verkehr läuft über einen HTTP/HTTPS-Proxy auf dem Host, standardmässig mit Deny-by-Default-Policy. Rohes TCP, UDP und ICMP sind auf Netzwerkebene komplett blockiert, ebenso der Zugriff auf das Host-Netzwerk und localhost.
3. Eigene Docker Engine: Jede microVM bringt einen privaten Docker-Daemon mit eigenem Image-Cache mit. Der Agent kann docker build, docker run und docker compose uneingeschränkt nutzen, sieht aber die Container und Images des Hosts nicht.
4. Workspace-Isolation: Das Projektverzeichnis wird per Filesystem-Passthrough unter seinem identischen absoluten Pfad in die Sandbox eingebunden, standardmässig read-write, sodass Änderungen sofort auf dem Host sichtbar sind. Wer das nicht will, nutzt den --clone-Modus, bei dem der Agent auf einem privaten Git-Klon arbeitet (dazu später mehr).
5. Credential-Isolation: Das vielleicht eleganteste Detail. API-Schlüssel werden nicht in die Sandbox kopiert, sondern vom Host-Proxy zur Laufzeit in die HTTP-Header injiziert. In der VM selbst existieren nur Platzhalterwerte: selbst ein bösartiger Agent, der die komplette Sandbox ausliest, findet dort keine echten Secrets.

Besonders die letzte Schicht ist elegant gelöst: Der echte Schlüssel bleibt auf dem Host, in die Sandbox gelangt nur ein Platzhalter.

Die Philosophie dahinter zeigt sich an einer auf den ersten Blick provokanten Design-Entscheidung: Startet man Claude Code in einer Sandbox, läuft es standardmässig mit --dangerously-skip-permissions. Sicherheit soll nicht vom Wohlverhalten des Modells abhängen, sondern von diesen Infrastrukturgrenzen, die der Agent weder einsehen noch verhandeln noch aufweichen kann. Docker nennt das «no path back to host». Dazu passt, dass Sandboxes bewusst «disposable by design» sind: Wenn sich ein Agent verrannt hat, löscht man die Sandbox und startet in Sekunden eine frische.

Vorinstallierte Sprachen und Tools #

Die Sandboxes basieren auf öffentlichen Images unter docker/sandbox-templates, von denen es mehrere Varianten gibt. Das claude-code-docker-Image enthält unter anderem eine Docker Engine samt buildx und compose, ein JDK 25, Node.js mit npm, Python 3 mit pip, Go, git, die GitHub CLI gh, make, gcc sowie Alltagswerkzeuge wie curl, jq, ripgrep und rsync. Maven, Gradle und pnpm fehlen allerdings.

Falls Werkzeuge fehlen sollten, kann Claude Code diese typischerweise selber in der richtigen Version nachinstallieren. In bestehenden Go- und Gradle-basierten Java-Projekten konnte Claude nach dem Start der Sandbox sofort loslegen. Dank .gradlew wurde Gradle automatisch installiert. Ein fehlendes JDK 21 und pnpm 11 hat Claude selbstständig, ohne Zutun des Benutzers, in der Sandbox installiert.

Falls eine neue Sandbox dennoch gewisse Werkzeuge bereits vorinstalliert haben muss, kann dies über eigene Templates (ein Dockerfile, das ein Image von docker/sandbox-templates erweitert und per sbx run --template referenziert wird) oder über ein bzw. mehrere Kits erreicht werden.

Das Kit-System #

Kits sind Dockers Antwort auf die Frage, wie man Sandboxes wiederholbar anpasst, ohne für jede Kleinigkeit ein eigenes Image zu bauen. Ein Kit ist ein deklaratives Artefakt, ein Verzeichnis mit einem spec.yaml File und optional einem files-Ordner, das beim Start der Sandbox angewendet wird. Die Dokumentation unterscheidet zwei Arten:

Ein Mixin-Kit erweitert einen bestehenden Agent. Es kann Installationsbefehle ausführen, Umgebungsvariablen setzen, Netzwerkregeln ergänzen, Dateien in die Sandbox legen, Hintergrunddienste starten und sogar Kontext in das Memory des Agenten einspeisen. Mixins sind stapelbar, so dass man mehrere gleichzeitig anwenden kann.

Ein Sandbox-Kit definiert dagegen einen kompletten, eigenen Agent inklusive Basis-Image und Entrypoint. So sind auch die eingebauten Agents intern umgesetzt; wer einen Agenten integrieren will, den Docker nicht mitliefert, baut ein solches Kit.

Referenziert werden Kits flexibel: als lokales Verzeichnis, als Git-Repository mit Tag, oder als OCI-Artefakt aus einer Registry. Wichtig zu wissen: Während das Kernprodukt GA-Status hat, sind Kits noch als experimentell markiert. Dateiformat und CLI-Befehle können sich noch ändern.

Warum die Host-Konfiguration draussen bleibt, und was das für Claude Skills bedeutet #

Wer Claude Code auf dem Host intensiv nutzt, hat sich vermutlich eine persönliche Umgebung aufgebaut: globale Skills, Plugins, Hooks und ein benutzerweites CLAUDE.md, alles unter ~/.claude beziehungsweise ~/.config. In der Sandbox ist davon nichts vorhanden. Das ist kein Versehen, sondern Konsequenz des Sicherheitsmodells.

Gerade Konfigurationsverzeichnisse wie ~/.claude oder ~/.config stecken voller sensibler Daten (Session-Tokens, API-Schlüssel, Zugangsdaten anderer Tools). Genau solche Dateien soll ein autonom agierender Agent per Definition nie zu Gesicht bekommen. Der naheliegende Trick, einen Symlink aus dem Projekt auf ~/.claude zu legen, funktioniert nicht: Symlinks lösen über die Sandbox-Grenze hinweg ins Leere auf.

Praktisch bedeutet das: Globale Claude Skills, Plugins und benutzerweite Einstellungen sind in der Sandbox nicht verfügbar. Es gibt drei saubere Auswege: Erstens kann man Konfiguration auf Projektebene verschieben, ein .claude/-Verzeichnis im Projekt wandert mit dem Workspace in die Sandbox. Zweitens lassen sich Dateien mit sbx cp gezielt in eine laufende Sandbox kopieren, etwa nach /home/agent/.claude/. Und drittens, der wiederholbare Weg, verpackt man seine persönliche Ausstattung in ein Kit, so dass sie bei jedem Sandbox-Start automatisch bereitgestellt wird. Wie das aussieht, zeigen wir weiter unten konkret.

Hands-on: Claude Code in der Sandbox #

Genug Theorie, so sieht der Einstieg in der Praxis aus:

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

Nach der Installation meldet man sich mit seinem Docker-Konto an:

sbx login

Beim ersten Login fragt sbx nach der Standard-Netzwerk-Policy. Zur Wahl stehen Open (alles erlaubt), Balanced (Deny-by-Default, aber gängige Entwickler-Endpunkte wie GitHub, die npm-Registry oder PyPI sind freigeschaltet) und Locked Down (alles blockiert, was nicht explizit erlaubt ist). Für den Einstieg ist Balanced die richtige Wahl. Mit sbx policy reset kann die gewählte Policy jederzeit angepasst werden.

Für die Authentifizierung von Claude Code gibt es zwei Wege. Wer ein Claude-Abo (Pro/Max/Teams) hat, braucht gar nichts vorzubereiten: Beim ersten Start führt man in der Sandbox einfach /login aus, und der OAuth-Flow übernimmt den Rest, das Session-Token bleibt dabei auf dem Host und wird vom Proxy injiziert. Wer stattdessen einen API-Schlüssel nutzt, hinterlegt ihn einmalig in der Keychain des Betriebssystems:

sbx secret set -g anthropic

Mit dem sbx secret Befehl kann z.B. auch ein GitHub-Token registriert werden, damit der Agent das gh CLI innerhalb der Sandbox aufrufen kann:

sbx secret set -g github "$(gh auth token)"

Jetzt kann es losgehen. Im Projektverzeichnis genügt:

cd ~/my-project
sbx run --name my-project claude

Beim ersten Aufruf lädt sbx das Basis-Image, bootet die microVM und startet Claude Code im YOLO-Modus. Das Projektverzeichnis liegt in der Sandbox unter demselben absoluten Pfad wie auf dem Host. Änderungen des Agenten erscheinen sofort im lokalen Dateisystem. Die Sandbox überlebt das Beenden des Agenten. Installierte Pakete bleiben erhalten, bis die Sandbox (samt intern angelegter Images und Container) explizit mittels sbx rm my-project entfernt wird.

Ein paar Befehle, die im Alltag hilfreich sind: sbx ls listet alle Sandboxes mit Status auf, sbx stop my-project pausiert eine Sandbox unter Beibehaltung ihres Zustands. Mit sbx exec -it my-project bash öffnet man eine Shell in der Sandbox, praktisch, um nachzusehen, was der Agent gerade angerichtet hat, oder um ein Tool manuell zu installieren. sbx cp kopiert Dateien in die Sandbox hinein oder heraus, wie z.B. die gradle.properties im Home-Verzeichnis:

sbx cp ~/.gradle/gradle.properties my-project:/home/agent/.gradle/

Wenn der Agent einen Entwicklungsserver gestartet hat, macht sbx ports my-project --publish 3000:3000 ihn auf dem Host erreichbar. Schlägt ein Netzwerkzugriff fehl, zeigt sbx policy log, welche Hosts blockiert wurden, und sbx policy allow network example.com schaltet gezielt frei. Und schliesslich öffnet sbx ohne jegliche Parameter ein interaktives TUI Dashboard, in dem man seine Sandboxes verwalten kann.

Interessant für autonomes Arbeiten ist der Clone-Modus:

sbx run --clone --name feature-x claude

Hier arbeitet der Agent nicht auf dem Original, sondern auf einem privaten Git-Klon innerhalb der microVM. Das Host-Verzeichnis ist nur noch read-only eingebunden. Die Sandbox stellt ihren Klon als Git-Remote sandbox-feature-x bereit, sodass man die Arbeit des Agenten wie den Branch eines Kollegen begutachtet:

git fetch sandbox-feature-x
git diff main..sandbox-feature-x/main
git checkout -b feature-x sandbox-feature-x/main

Nur eines sollte man nicht vergessen: sbx rm feature-x löscht auch alle Commits, die noch nicht gefetcht wurden.

Ein eigenes Kit #

Nun lösen wir das Versprechen von vorhin ein und bringen persönliche Werkzeuge per Kit in die Sandbox. Ein Kit ist schnell gebaut: ein Verzeichnis, eine spec.yaml Datei, fertig.

rtk («Rust Token Killer») ist ein CLI-Proxy, der die Ausgaben gängiger Entwickler-Befehle filtert und komprimiert, bevor sie im Kontext des Agenten landen, um so Tokens zu sparen. Auf dem Host richtet man rtk mit rtk init -g ein: Das registriert einen PreToolUse-Hook in ~/.claude/settings.json, der Bash-Befehle transparent auf ihre rtk-Pendants umschreibt (aus git status wird rtk git status). Da das lokale settings.json jedoch nicht in die Sandbox gelangt, schafft ein Mixin-Kit Abhilfe:

rtk-kit/
└── spec.yaml

schemaVersion: "1"
kind: mixin
name: rtk
displayName: rtk
description: Token-sparender CLI-Proxy für Claude Code

network:
  allowedDomains:
    - github.com
    - api.github.com
    - "*.githubusercontent.com"

commands:
  install:
    - description: rtk-Binary installieren
      command: "curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh"
      user: 1000
    - description: Hook in ~/.claude/settings.json registrieren
      command: "rtk init -g --auto-patch"
      user: 1000
    - command: "rtk telemetry disable"
      user: 1000

Die install-Befehle laufen einmalig beim Erstellen der Sandbox. Standardmässig werden die Befehle als root ausgeführt. Mittels user: 1000 werden sie als Agent-Benutzer ausgeführt, damit rtk in dessen ~/.local/bin installiert und der Hook im entsprechenden ~/.claude/settings.json eingetragen wird. Für Befehle, die bei jedem Start der Sandbox laufen sollen, gäbe es analog einen startup-Block.

Die network.allowedDomains geben für ein Kit explizite Hosts frei, welche durch die aktive Network-Policy allenfalls geblockt würden (z.B. im Locked Down Modus). Mit dem Gegenstück deniedDomains können Hosts hingegen explizit geblockt werden (z.B. Telemetrie-Endpoints im Open Modus).

Angewendet wird das Kit beim Erstellen einer Sandbox:

sbx run claude --kit ./rtk-kit/

Mit sbx kit add kann das Kit für eine bestehende Sandbox nachgerüstet werden:

sbx kit add my-project ./rtk-kit/

Agent Sandboxes im Vergleich #

Anthropic Sandbox Runtime: Der Gegenentwurf ohne VM #

Konzeptionell der direkteste Konkurrent ist ausgerechnet die Lösung des Claude-Herstellers selbst. Anthropics Sandbox Runtime (srt) verfolgt dasselbe Ziel aber mit dem entgegengesetzten Ansatz: Statt einer VM nutzt es die nativen Sandboxing-Primitiven des Betriebssystems, also Seatbelt auf macOS und bubblewrap mit Netzwerk-Namespaces auf Linux, ergänzt um einen Proxy mit Domain-Allowlist. Das ist direkt in Claude Code integriert, ohne dass ein Container oder eine VM gebootet werden muss. Die Kehrseite: Prozess-Sandboxing auf einem geteilten Kernel ist eine deutlich weichere Grenze als ein Hypervisor. Und einen eigenen Docker-Daemon für den Agenten gibt es nicht. Man könnte zuspitzen: srt macht den Normalbetrieb bequemer, Docker Sandboxes macht den Extremfall (vollautonomer Agent über Nacht) vertretbar.

Inventage Asylum: Der pragmatische Container-Ansatz #

Unser eigenes Open-Source-Projekt Asylum spielt in derselben Kategorie wie Docker Sandboxes und teilt viele Design-Entscheidungen: Auch Asylum mountet das Projektverzeichnis unter seinem echten Host-Pfad (damit absolute Pfade und Git-Worktrees funktionieren), startet Agents standardmässig im YOLO-Modus und bringt ein eigenes Kit-System mit, das sogar granularer ausgebaut ist als Dockers noch experimentelles Pendant. Auch bei den vorinstallierten Tools ist Asylum breiter aufgestellt: Maven, Gradle und mehrere JDK-Versionen sind im Standard-Image enthalten, genau das, was Docker-Sandbox-Nutzer mit Java-Projekten erst nachrüsten müssen.

Der fundamentale Unterschied liegt in der Isolationsstufe. Asylum setzt auf gewöhnliche Docker-Container und beschreibt sein Sicherheitsmodell selbst ehrlich als «Sicherheitsgurt, nicht Airbag»: Der ausgehende Netzwerkverkehr ist unbeschränkt, der Host ist über host.docker.internal erreichbar, und Docker-in-Docker erfordert den privilegierten Modus. Docker Sandboxes zieht mit Hypervisor-Grenze, Deny-by-Default-Netzwerk und Proxy-basierter Credential-Injektion eine deutlich härtere Linie. Dafür bietet Asylum etwas, das Docker Sandboxes konzeptbedingt verweigert: Im shared-Modus wird das Host-Verzeichnis ~/.claude direkt in den Container gemountet, globale Claude Skills, Plugins und Einstellungen sind damit sofort verfügbar, wahlweise auch als isolierte oder projektbezogene Kopie.

Was man sonst noch wissen sollte #

Die Sandbox schützt den Host, aber nicht das Projekt. Im Standard-Modus ist der Workspace read-write, der Agent kann also weiterhin Dateien löschen oder, subtiler, Makefiles und Git-Hooks manipulieren, die man später auf dem Host ausführt. Dockers eigene Dokumentation mahnt deshalb, Änderungen vor dem Ausführen zu prüfen. Versionskontrolle und der Clone-Modus sind die richtigen Werkzeuge dafür.

Zudem schützt die Sandbox nicht vor dem Missbrauch von Berechtigungen, die man selbst hineinreicht: Credentials, die per Umgebungsvariable oder innerhalb von Dateien der Sandbox übergeben werden, können vom Agent für alles verwendet werden, was diese erlauben.

Und schliesslich sammelt das CLI Telemetrie-Werte (Befehlstyp, Erfolg, Dauer, keine Prompts oder Code), die sich mit SBX_NO_TELEMETRY=1 abschalten lassen.

Fazit #

Docker Sandboxes trifft einen Nerv. Coding-Agents entfalten ihren Wert erst, wenn man sie machen lässt, und genau davor hatten bisher alle Beteiligten zu Recht Respekt. Dockers Antwort ist konsequent: harte Hypervisor-Isolation statt Vertrauen ins Modell, Credential-Injektion statt kopierter Secrets, Deny-by-Default statt offener Netze, und das alles lokal, kostenlos und mit einer Docker Engine in jeder Sandbox. Eine durchdachte und benutzerfreundliche Lösung für alle, die eine maximale Isolation für ihre autonomen Agenten suchen.