Sandboxing für Claude Code auf macOS: Was wirklich funktioniert

Wer Claude Code länger als einen Tag benutzt hat, kennt das Spiel. Jeder Bash-Befehl, jedes File-Write außerhalb des Working Directory, jeder Netzwerkaufruf -- "Allow this? Allow once? Allow always?" Man fängt an, sorgfältig Permission Rules zu kuratieren. Dieses npm install ist okay. Das docker build auch. Dieses curl an eine API -- wahrscheinlich okay? Man verbringt mentale Energie für Access Control statt für das eigentliche Problem.

Es funktioniert. Es ist sicher. Und es ist langsam.

Irgendwann merkt man: Man selbst ist der Bottleneck. Claude Code wartet darauf, dass man Commands schneller freigibt als man sie lesen kann. Also lockert man die Regeln, erlaubt breitere Patterns, greift vielleicht sogar zu --dangerously-skip-permissions auf der eigenen Maschine, für die eigenen Projekte. Das ist eine persönliche Risikoabwägung, und für Solo-Arbeit kann das völlig okay sein.

Aber es gibt ein tieferliegendes Problem. Das Permission-Prompt-Modell geht davon aus, dass jemand zuschaut. Es setzt interaktives, iteratives Prompting voraus, bei dem man sich mit dem Agent abwechselt. Das funktioniert für "Fix diesen Bug" oder "Refactor diese Funktion". Es bricht zusammen, sobald man Claude Code wirklich laufen lassen will -- Spec-driven Workflows, bei denen man eine Implementierungsaufgabe übergibt und weggeht. Background Agents, die parallel bauen und testen. Agents, die Docker brauchen um Test-Environments hochzuziehen, einen Browser für Verification, MCP-Server für externe Daten. Die Art von agentic Work, bei der der ganze Sinn darin besteht, dass man eben nicht jeden Schritt absegnet.

Genau da stand ich. Beim Übergang von interaktivem Claude Code zu Agentic Workflows für das Infralovers-Team -- Trainer, Berater, Leute die echte Kunden-Workloads fahren. Und ich habe gemerkt: Die Antwort sind nicht bessere Permission Rules. Es ist Isolation. Echte Isolation, auf Infrastruktur-Ebene, damit der Agent frei innerhalb einer Boundary arbeiten kann, die alles außerhalb schützt.

Also bin ich in den Rabbit Hole gestiegen. Wochen voller Lesen, Testen, Vergleichen. Hier ist die Progression, bei der ich gelandet bin.

Level 1: Die eingebaute Sandbox -- und warum sie tatsächlich gut ist

Fangen wir mit dem an, was Anthropic schon mitliefert. Native Sandboxing in Claude Code -- man tippt /sandbox und aktiviert OS-level Isolation. Unter der Haube basiert das auf Anthropics Open-Source Sandbox Runtime: Auf macOS nutzt sie sandbox-exec (Apples Seatbelt Framework), auf Linux bubblewrap. Beide beschränken Filesystem-Writes auf das aktuelle Working Directory und filtern Netzwerkzugriff über eine Proxy-Allowlist.

Ein Detail, das man wissen sollte: Apple markiert sandbox-exec in der Man Page als deprecated. Es funktioniert heute noch, und Anthropics Runtime hängt davon ab, aber es ist eine langfristige Unsicherheit für jedes Tooling, das darauf aufbaut.

Anthropic berichtet von circa 84% weniger Permission Prompts bei internem Einsatz nach Aktivierung der Sandbox. Die zugrunde liegende Runtime ist Open Source.

Für den klassischen iterativen Workflow -- man promptet, Claude editiert, man reviewt, repeat -- ist die eingebaute Sandbox ein echtes Upgrade. Die meisten nervigen "Darf ich dieses File schreiben?"-Prompts verschwinden. Man bleibt im Flow. Wenn alles, was man braucht, ein schlauer Pair Programmer ist, der Code editiert und Tests laufen lässt, dann reicht /sandbox vielleicht völlig aus. Hier aufhören zu lesen, fertig.

Liest du noch? Dann bist du wahrscheinlich an der gleichen Wand gelandet wie ich.

Level 2: Wo die eingebaute Sandbox aufhört

Sobald man zu Agentic Workflows übergeht, stößt die eingebaute Sandbox an harte Grenzen:

• Docker Workflows zwingen einen, Löcher zu bohren. Docker erfordert oft Host-Interaktionen und privilegierte Operationen, die nicht gut mit den Sandbox-Constraints harmonieren, also schließt man Docker-Commands via excludedCommands aus -- was den Sinn einer Sandbox untergräbt.
• Kein MCP-Server-Zugriff. Agents, die CRM-Daten abfragen, externe APIs aufrufen oder E-Mail-Drafts erstellen, brauchen Netzwerkzugriff zu Services, die sich in meiner Erfahrung nicht granular genug über die Sandbox allowlisten lassen.
• Keine Browser-Automatisierung. Verification Workflows, die einen Browser öffnen, ein Deployment prüfen, einen Screenshot machen -- stark eingeschränkt unter sandbox-exec.
• Background Agents können nicht prompten. Wenn man Agents im Hintergrund laufen lässt (der ganze Sinn von Spec-driven Workflows), ist niemand da zum Klicken auf "Allow." Man braucht entweder --dangerously-skip-permissions oder eine Sandbox, die Prompts überflüssig macht.

Für uns bei Infralovers ist das der Großteil unserer Arbeit. Unsere Agents bauen Docker Images, rufen APIs via MCP auf, lassen Integrationstests in Containern laufen. Die eingebaute Sandbox deckt vielleicht 40% unserer Workflows ab. Die interessanten 60% brauchen etwas anderes.

Die eigentliche Frage wurde: Was ist das richtige Isolation-Level für ein Team-Environment, in dem Claude Code Docker, MCP und Netzwerkzugang braucht -- und ohne Permission Prompts läuft?

Level 3: Echte Isolation -- Agents frei laufen lassen

Drei Ansätze kristallisieren sich heraus: Docker Sandboxes (microVM, beste DX, Docker-Desktop-Lizenz nötig), Lima (Open Source, CNCF, volle Kontrolle, mehr Setup) und Tart (sicherste Defaults, ideal für CI). Jeder hat andere Trade-offs -- hier die Details.

Sobald man akzeptiert, dass der Agent ohne Permission Prompts arbeiten muss, dreht sich das Security-Modell um. Statt "jeden Schritt genehmigen" braucht man "alle Aktionen eindämmen". Die VM-Boundary wird zur Security-Boundary.

Ich habe alles evaluiert, was ich finden konnte. Hier ist, was tatsächlich funktioniert.

Bevor wir in die einzelnen Tools eintauchen: Dieses Diagramm zeigt den zentralen Architektur-Unterschied zwischen den Ansätzen:

Docker Sandboxes erstellt eine microVM pro Sandbox mit eigenem privaten Docker Daemon. Lima gibt dir eine einzelne VM, in der Claude direkt arbeitet. Colima wrappt Lima um dir eine Docker-Desktop-ähnliche Experience auf dem Host zu geben -- ein anderer Use Case.

Docker Sandboxes: Das Nächste an "einfach funktioniert"

Ein verbreitetes Missverständnis: Docker Sandboxes ist nicht "Claude Code läuft in einem Docker Container mit Docker-in-Docker." Das wäre ein Container, der einen weiteren Docker Daemon im selben Kernel laufen lässt -- fragil und unsicher. Docker Sandboxes ist fundamental anders.

Docker hat Sandboxes über mehrere Releases iteriert; die aktuelle microVM-basierte Architektur erfordert Docker Desktop 4.58+ und ist noch als Experimental markiert. Frühere "Legacy"-Sandbox-Ansätze gab es auch, aber die microVM-Architektur ist der echte Security-Boundary-Shift -- und die ausgereifteste Lösung, die ich gefunden habe.

Jede Sandbox läuft in einer dedizierten microVM -- kein Container, eine vollständige virtuelle Maschine mit eigenem Linux-Kernel und eigenem Docker Daemon. Das ist der entscheidende Unterschied. Wenn Claude Code in einer Docker Sandbox läuft, kann es Docker frei nutzen, weil es seine eigene isolierte Docker-Umgebung hat. Es kann Images bauen, docker-compose laufen lassen, Test-Datenbanken hochfahren -- alles, was ein Agentic Workflow braucht. Aber es kann nicht auf den Docker Daemon des Hosts zugreifen, nicht auf andere Sandboxes, nicht auf Host-localhost-Services und nicht auf Files außerhalb des gesyncten Workspace.

Workspace-Verzeichnisse syncen bidirektional zwischen Host und Sandbox. Netzwerk-Traffic wird über einen HTTP/HTTPS-Proxy geroutet, bei dem man Domain-Allow/Deny-Listen setzen kann. Claude Code startet mit --dangerously-skip-permissions per Default -- weil der ganze Sinn darin besteht, dass die Sandbox die Sicherheitsgrenze bildet, nicht die Permission Prompts.

Sandboxes tauchen nicht in docker ps auf -- weil jede Sandbox ihren eigenen Docker Daemon hat, den der Host-Daemon nicht kennt. Man verwaltet sie über docker sandbox ls.

Matt Pocock hat es "the best DX of any local AI coding sandbox" genannt. Das Team bei Arcade.dev hat es getestet und gesagt "we forgot we were working inside a sandbox." Das deckt sich mit meiner Erfahrung -- die Friction ist minimal.

Die scharfen Kanten:

• Braucht Docker Desktop, das Stand heute nur für Organisationen mit weniger als 250 Mitarbeitern UND weniger als 10 Mio. Dollar Jahresumsatz kostenlos ist -- alle anderen brauchen eine kostenpflichtige Subscription
• Nur macOS oder Windows (Linux nutzt einen schwächeren Container-basierten Ansatz)
• Nicht verfügbar auf OrbStack (bestätigtes offenes Issue #2295)
• Tools wie make sind nicht vorinstalliert, also muss man auf Environment Parity achten
• Credential Management braucht Überlegung -- man entscheidet explizit, worauf die Sandbox zugreifen darf
• Disk Footprint: Jede microVM bringt einen eigenen Linux-Kernel und Docker Daemon mit. Bei mehreren Sandboxes parallel summiert sich das schnell

Für uns bei Infralovers ist die Lizenzierung kein Blocker. Wir sind ein kleines Team. Aber ich wollte die Alternativen trotzdem verstehen.

Der Open-Source-Weg: Lima und Colima

Wenn Docker-Desktop-Lizenzierung ein Problem ist, oder wenn man einfach Open-Source-Tooling bevorzugt, ist Lima (~20k Stars, Stand Februar 2026, CNCF-Projekt) die Antwort.

Aber zuerst eine Unterscheidung, die fast jeden verwirrt:

• Lima ist das Basis-Tool. Es startet und verwaltet Linux-VMs auf macOS. Punkt.
• Colima ("Containers on Lima") ist ein Wrapper, der dir eine Docker-Desktop-ähnliche Experience gibt -- es erstellt eine Lima VM, installiert Docker darin, und exposed den Docker Socket an deinen Host, damit du docker build von deinem Mac-Terminal laufen lassen kannst.

Um Claude Code in einer VM laufen zu lassen, braucht man Colima nicht. Das Pattern ist einfacher: Lima VM starten, Claude Code darin installieren, und direkt in der VM arbeiten lassen. Lima hat ein AI Agents Beispiel, das genau das demonstriert. Colima wird erst relevant, wenn man zusätzlich ein bequemes Docker-on-Mac-Setup neben der Lima VM braucht -- ein anderer Use Case.

Lima startet Linux-VMs über Apples Virtualization.framework (vmType: vz, seit Lima v1.0 der Default auf macOS 13.5+). CPU Performance ist nahe am nativen Niveau (Apples Virtualization.framework vermeidet die Overhead-Schicht klassischer Emulatoren). Booten dauert circa 30 Sekunden.

Ein Feature, das man kennen sollte: limactl shell --sync (ab Lima 2.1). Statt Änderungen live auf das Host-Filesystem zu syncen, werden sie gestaged. Wenn der Agent fertig ist, bekommt man einen "Accept changes?"-Prompt mit Diff -- reviewen, akzeptieren oder verwerfen. Quasi ein Filesystem-Level Code Review für Agent-Output. Das ist ein genuines anderes Safety-Modell als Docker Sandboxes' bidirektionaler Sync.

Trail of Bits pflegt eine security-gehärtete DevContainer-Konfiguration mit explizitem Colima-Support, die vz + virtiofs + rosetta empfiehlt. Ein solider Startpunkt.

Aber hier ist, was ich auf die harte Tour gelernt habe über Limas Defaults: Limas Default-Instance-Template mountet Host-Pfade -- häufig aus $HOME -- als read-only. Welche Pfade genau gemountet werden, hängt vom gewählten Template ab, aber die Out-of-the-Box-Experience bedeutet oft: SSH Keys, .env Files, Cloud Credentials, Git Configs -- potenziell lesbar für Code, der in der VM läuft. Für normale Entwicklungsarbeit ist das ein Convenience Feature. Für Claude Code mit --dangerously-skip-permissions ist es eine Sicherheitslücke.

Eine gehärtete Konfiguration für Claude Code sollte:

• Alle Home-Directory-Mounts komplett entfernen
• Docker innerhalb der VM installieren
• Repos direkt in der VM klonen (nicht via Bind Mounts)
• iptables-Regeln für Outbound-Netzwerk-Filterung hinzufügen

Die Filesystem-Performance-Story ist der Haupt-Trade-off hier. Virtiofs Bind Mounts laufen typischerweise deutlich langsamer als native bei metadaten-intensiven Operationen (siehe Benchmark-Abschnitt unten). Der Workaround ist genau das, was die gehärtete Konfiguration macht: Repos in der VM klonen, wo man native ext4-Geschwindigkeit bekommt. Wenn man Host-seitigen Dateizugriff braucht (Editieren in VS Code auf dem Host), benchmarkt der Hybrid-Ansatz -- Bind Mount für Source Code, Docker Volume für node_modules -- bei circa 1,1-1,3x native.

Der Vorschlag, von dem ich mich selbst abbringen musste: Colima + Incus

Ich bin ehrlich: Ich habe ein paar Tage damit verbracht, eine Colima + Incus-Architektur zu designen. Incus System Containers in einer Lima VM. Elegantes Layering. Defense in Depth. Ich war begeistert davon.

Dann habe ich es wirklich durchdacht.

Incus Container teilen den Kernel der VM. Sie nutzen die gleichen Namespace- und Cgroup-Primitives wie Docker. Die Incus-Schicht fügt UID Remapping und nette operative Features wie Snapshots und Cloning hinzu, aber die bedeutungsvolle Isolation-Boundary ist immer noch die Lima VM selbst. Wie Security Researchers festgestellt haben, fügen Incus Container keine bedeutsame Sicherheit über Docker hinaus hinzu, da sie die gleichen zugrunde liegenden Mechanismen nutzen, und Kernel Exploits bleiben gleichermaßen möglich.

Was wäre mit Incus VMs (nicht Containern) für echte Hypervisor-Level-Isolation? Das erfordert Nested Virtualization, und die braucht M3+ Apple Silicon. M1- und M2-Macs können das nicht. Das killt ein Team-weites Deployment auf der Stelle -- ich werde kein Hardware-Upgrade für eine Sandboxing-Strategie vorschreiben.

Die Conclusion: Die Incus-Schicht weglassen und Docker direkt in der Lima VM nutzen. Gleiche Security Boundary, dramatisch weniger Komplexität. Niemand in der Community fährt den Colima + Incus-Stack für Claude Code, und jetzt verstehe ich warum.

OrbStack: Die Geschwindigkeitsmaschine mit Vorbehalt

Ich muss OrbStack erwähnen, weil die Performance-Zahlen lächerlich gut sind. 2 Sekunden Boot (vs. 30s für Lima). 40% weniger RAM als Docker Desktop. 75-95% von nativer Filesystem-Performance bei Operationen wie pnpm install (12,2s vs. 10,9s nativ). Das wird durch eine Custom-VirtioFS-Implementierung mit Dynamic Caching erreicht.

Aber OrbStack läuft mit allen Linux-Maschinen auf einem Shared Kernel (ähnlich WSL2). Isolation ist auf Container-Level, nicht VM-Level. File Sharing ist bidirektional und kann derzeit nicht per Maschine deaktiviert werden (offenes Feature Request #169). Für Isolation von nicht-vertrauenswürdigem Code bräuchte man Container innerhalb einer OrbStack-Maschine, was eine weitere Schicht hinzufügt. Und es ist Closed Source mit kommerzieller Lizenzierung.

Für vertrauenswürdige Entwicklungsarbeit: OrbStack ist phänomenal. Für das Sandboxing eines AI Agents mit --dangerously-skip-permissions: Das Isolation-Modell ist nicht stark genug.

Tart: Die Option, zu der ich für CI immer wieder zurückkehre

Tart von Cirrus Labs verdient Erwähnung, weil seine Defaults die sicherheitsbewusstesten aller Optionen sind. Keine Filesystem Mounts per Default. Ein Userspace Packet Filter namens Softnet, der VM-Networking mit konfigurierbaren CIDR-Allow-Listen einschränkt. VMs als OCI Images verteilbar (Push/Pull von Container Registries), was Environment-Standardisierung straightforward macht.

Der Trade-off ist Convenience: Kein automatisches Port Forwarding, kein automatisches File Sharing und ein CI-fokussiertes Design, dem interaktive Development-Ergonomie fehlt. Für automatisierte Claude Code Workflows in CI/CD Pipelines ist Tart vielleicht tatsächlich die beste Wahl. Für tägliche interaktive Entwicklung erzeugt es zu viel Friction.

Die Community-Landschaft

Jenseits der großen VM/Container-Optionen sind einige fokussierte Tools entstanden:

• nikvdp/cco ("Claude Condom") -- erkennt automatisch das beste verfügbare Sandbox-Backend. Auf macOS nutzt es sandbox-exec nativ, Docker als Fallback. Zero-Config, ein Command. Cleveres Naming, nützliches Tool.
• textcortex/claude-code-sandbox -- Web UI mit Auto-Push und Multi-Container-Management
• RchGrav/claudebox -- 15+ sprachspezifische Development-Profile für Docker-basiertes Sandboxing
• neko-kai/claude-code-sandbox -- blockiert einzigartigerweise den Read-Zugriff auf $HOME, nicht nur Writes. Das ist wichtig, um Prompt-Injection-basierte Daten-Exfiltration zu verhindern. Die meisten Sandboxes fokussieren auf Write-Beschränkungen, vergessen aber, dass das Lesen deiner SSH Keys bereits Game Over ist.

Wo die echten Sicherheitsrisiken stecken

Ich will hier direkt sein, weil die meisten Sandbox-Vergleiche sich auf das theoretische VM-Escape-Szenario konzentrieren. Die Angriffsfläche ist relativ klein (nur Virtio Devices, keine Legacy-Emulation), aber man sollte davon ausgehen, dass Hypervisors Bugs haben können, und die geteilte Angriffsfläche minimal halten. Apple patcht Sandbox- und Isolation-Bypasses in macOS regelmäßig; es wäre fahrlässig, irgendeine Isolation-Schicht als unüberwindbar zu behandeln.

Die praktischen Risiken drehen sich komplett um das, was in die Sandbox geteilt wird:

Write-Beschränkungen sind nett; Read-Beschränkungen sind oft wichtiger. Ein Read von ~/.ssh plus ausgehender Netzwerkzugriff ergibt sofortige Exfiltration. Die meisten Sandboxes konzentrieren sich auf das Verhindern von Writes, vergessen aber, dass das Lesen deiner SSH Keys, Cloud Credentials oder Git Tokens bereits Game Over ist.

Filesystem Sharing ist der primäre Angriffsvektor. Limas Standard-$HOME-Mount, OrbStacks bidirektionales Sharing, das nicht deaktiviert werden kann, jeder Bind Mount, der Credential-Verzeichnisse einschließt. SSH Keys, Cloud Credentials, .env Files, Git Tokens. Ein Agent muss nicht aus der VM ausbrechen, wenn man ihm seine Secrets schon übergeben hat.

Netzwerkzugang ist der sekundäre Vektor. Anthropics eigene Dokumentation sagt es klar: "Without network isolation, a compromised agent could exfiltrate sensitive files. Without filesystem isolation, a compromised agent could backdoor system resources." Docker Sandboxes handhabt das mit HTTP-Proxy-Domain-Filterung. Tart hat Softnet für Packet-Level-Filterung. Lima und OrbStack? Da muss man iptables im Guest selbst konfigurieren.

Container Escapes sind real. Eine kritische Schwachstelle vom August 2025 illustriert das: CVE-2025-9074 (CVSS 9.3) legte die interne Engine API von Docker Desktop jedem Container unter 192.168.65.7:2375 ohne Authentifizierung offen. Auf macOS bedeutete das Escape vom Container zur Docker-Desktop-VM und Kontrolle über dessen Daemon -- kein direkter Host-Zugang, da die Hypervisor-Schicht noch zwischen VM und macOS saß. Aber es unterstreicht, warum microVM-Isolation (Docker Sandboxes, Lima, Tart) eine fundamental stärkere Boundary bietet als reine Container-Ansätze: Selbst wenn ein Container Escape passiert, bleibt der Blast Radius innerhalb der VM.

Gerade im DACH-Raum, wo NIS2 und DSGVO echte Compliance-Anforderungen stellen, ist das keine akademische Übung. Wenn Agents autonomen Zugriff auf Infrastruktur haben, muss man den Blast Radius nachweisbar begrenzen können. "Der Agent läuft in einer VM" ist eine deutlich bessere Antwort für den Auditor als "Der Agent fragt vorher nach".

Die Filesystem-Performance-Realität

Jede macOS-VM-Lösung trifft auf die gleiche Wand: Die Hypervisor-Boundary für I/O zu überqueren kostet circa 3x Performance bei metadaten-intensiven Workloads.

Der beste unabhängige Benchmark, den ich gefunden habe, stammt von Paolo Mainardi (Januar 2025), gemessen mit npm install für eine React App auf einem M4 Pro mit Bind Mounts:

OrbStacks eigene Benchmarks behaupten 75-95% nativer Performance für pnpm install (12,2s vs. 10,9s nativ) -- beeindruckend, aber die Vendor-Quelle beachten. Die DDEV Community Benchmarks (Randy Fay, November 2023) bestätigten OrbStack als schnellsten Provider mit deaktiviertem Mutagen.

Die Implikation für Claude Code: Repos direkt in der VM klonen und Änderungen via Git pushen. Wenn Daten in der VM liegen, bekommt man native ext4-Geschwindigkeit -- die ~3x Penalty trifft nur Bind Mounts, die die Hypervisor-Boundary überqueren. Für Workflows, bei denen man Host-seitigen Dateizugriff braucht (Editieren in der nativen IDE), sind OrbStacks optimierte Mounts oder Dockers File-Sync-Feature akzeptable Trade-offs.

Zur virtiofs-Verbesserungskurve: Dockers Wechsel von gRPC-FUSE zu virtiofs brachte bis zu 90% Speedups bei schweren Workloads (unabhängig bestätigt von Jeff Geerling mit ~3,7x schneller). Bind Mounts gingen von ~5-6x langsamer als nativ auf ~3x -- besser, aber native Parität bleibt ein offener Wunsch.

Die Bewertungsmatrix

Nach Wochen des Testens und Recherchierens, hier ist mein Scoring dieser Optionen über die Dimensionen, die für unseren Use Case zählen. Die Gewichtungen reflektieren unsere spezifischen Prioritäten: unbeaufsichtigter Docker + vernetzte MCP-Server in einem kleinen Team-Setting. Deine Gewichtungen werden sich unterscheiden -- entsprechend anpassen.

Anmerkungen zu den Scores: Incus Container bekommen eine 7 für Isolation (Shared Kernel), Incus VMs würden eine 9 bekommen, brauchen aber M3+-Chips. Docker-in-Docker ist möglich in DevContainers, erfordert aber Privileged Mode. Filesystem Scores aufgeteilt zwischen Bind Mounts (6) und Klonen innerhalb der VM (9).

Meine Perspektive: Warum "es kommt darauf an" die ehrliche Antwort ist

Docker Sandboxes hat die beste Developer Experience. Aber "beste DX" und "was wir Kunden empfehlen können" sind nicht dasselbe.

Für unser eigenes Team bei Infralovers ist Docker Sandboxes das, was ich gerade evaluiere. Das microVM-Isolation-Modell ist genau richtig: eigener Docker Daemon, Network Policy Enforcement, Workspace Syncing, ein Command zum Hochfahren. Die Lizenzierung passt für unsere Teamgröße.

Aber wir sind ein Training- und Consulting-Unternehmen. Wir wählen nicht nur Tools für uns selbst -- wir müssen Lösungen verstehen und empfehlen, die unsere Kunden tatsächlich einsetzen können. Und die echte Welt da draußen ist kompliziert.

Die Lizenz-Barriere ist real. Docker Desktop ist nur kostenlos für Organisationen mit weniger als 250 Mitarbeitern UND weniger als 10 Mio. Dollar Umsatz. Viele unserer Enterprise-Kunden -- Banking, Telko, Manufacturing -- sprengen beide Schwellenwerte. Bei ~21 Dollar/User/Monat für Docker Business schaut eine 250-Personen-Engineering-Org auf circa 63.000 Dollar pro Jahr allein für die Container Runtime. Das ist kein technisches Argument, das ist eine Procurement-Diskussion. Und in regulierten Branchen können Procurement-Diskussionen Monate dauern.

Wer im DACH-Raum Enterprise IT kennt, weiß: Neue Software durch die Beschaffung zu bekommen ist manchmal schwieriger als die eigentliche technische Implementierung. Gerade im Banken- und Versicherungsumfeld, wo jedes Tool durch Compliance, Datenschutz und oft genug durch eine hausinterne Whitelist muss.

Kunden haben schon andere Tools. Geh in eine RHEL-Shop und die laufen mit Podman Desktop, nicht Docker Desktop. Podman ist die Default Container Runtime in RHEL 8+ und kommt kostenlos mit der Subscription, die sie ohnehin schon bezahlen. Es ist rootless per Default (kein Daemon, der als Root läuft), daemonless (kleinere Angriffsfläche) und liefert FIPS-140-2-Compliance auf RHEL. Für Organisationen mit SOC 2, ISO 27001 oder NIS2-Anforderungen sind das keine Nice-to-haves -- das sind Checkboxen, die ausgefüllt werden müssen.

Und gerade NIS2 -- auf EU-Ebene seit Januar 2023 in Kraft, Umsetzungsfrist für die Mitgliedstaaten war der 17. Oktober 2024 -- das viele DACH-Unternehmen immer noch in die Umsetzung bringt, stellt klare Anforderungen an die Absicherung von Entwicklungsumgebungen. Wenn ein AI Agent autonomen Zugriff auf Code, Credentials und Infrastruktur hat, dann ist "wir haben eine Sandbox" keine ausreichende Antwort -- man braucht nachweisbare Isolation-Boundaries und dokumentierte Network Policies. Rootless Container, VM-Level-Isolation und auditierbare Zugriffskontrolle sind genau die Dinge, die bei einem NIS2-Audit relevant werden.

Podman auf macOS nutzt das gleiche Apple Virtualization.framework wie Lima und läuft eine Fedora CoreOS VM (Default-Provider: applehv, alternativ libkrun oder qemu). Das Isolation-Modell ist vergleichbar. Community-Projekte wie claude-podman und claudeman lassen Claude Code bereits in Podman laufen, und das textcortex/claude-code-sandbox-Projekt erkennt Podman Sockets automatisch. Es funktioniert -- aber es ist nicht so poliert wie Docker Sandboxes, und es gibt noch kein Äquivalent zu Dockers microVM-per-Sandbox-Architektur.

Wo stehen wir also?

• Für unser eigenes Team: Docker Sandboxes ist der aktuelle Frontrunner. Beste DX, starke Isolation, akzeptable Lizenzierung.
• Für Kundenempfehlungen: Es kommt darauf an, was schon da ist. Podman-Shop? Lima/Colima gehärtet mit der Trail of Bits DevContainer Config ist der Open-Source-Weg. Docker Desktop schon im Einsatz? Docker Sandboxes ist das offensichtliche Upgrade.
• Für die Zukunft: Apple hat native Containerization auf der WWDC 2025 angekündigt -- eine dedizierte Lightweight VM pro Container, Sub-second Startup, minimale Angriffsfläche. Wenn das mit macOS 26 ausgeliefert wird, könnte es zur besten Sandboxing-Option für jede Runtime werden. Aber es ist noch nicht da.

Die ehrliche Antwort ist: Es gibt kein einzelnes "richtiges" Tool. Es gibt das richtige Tool für den spezifischen Toolstack eines Teams, seine Lizenzierungsvorgaben und seine Sicherheitsanforderungen. Als Berater finde ich diese Antwort unbefriedigend. Als jemand, der in genug Enterprise-Umgebungen war um es besser zu wissen, finde ich sie akkurat.

Was das für DevOps- und Platform-Teams bedeutet

Die Progression ist im Rückblick klarer als sie es beim Durchleben war:

1. Permission Prompts funktionieren, wenn jemand zuschaut. Sie sind der Sicherheitsgurt für interaktive Nutzung.
2. Die eingebaute /sandbox nimmt den Großteil der Friction für iteratives Coding. Echte Verbesserung, keine Infrastruktur nötig.
3. VM-Isolation ist das, was man braucht, sobald "agentic" aufhört ein Buzzword zu sein und anfängt die Art zu sein, wie man tatsächlich arbeitet -- Agents, die im Hintergrund laufen, Container bauen, externe APIs aufrufen, Specs implementieren während man etwas anderes reviewt.

Die entscheidende Erkenntnis ist peinlich einfach: Die VM-Boundary ist die Security-Boundary. Alles andere -- Incus Container, Docker Namespaces, DevContainer Configs, macOS Seatbelt Profiles -- liefert Defense in Depth, aber keine fundamental andere Isolation-Stufe.

Apples Virtualization.framework macht diese VM-Boundary leicht genug (30 Sekunden Boot, near-native CPU, 75-95% native Filesystem mit dem richtigen Ansatz), dass der alte Trade-off zwischen Isolation und Performance weitgehend aufgelöst ist. Die verbleibende Friction ist Filesystem Sharing, und Klonen innerhalb der VM eliminiert das komplett.

Wo man auf dieser Progression landet, hängt davon ab, wie man Claude Code einsetzt. Wenn es der Pair Programmer ist -- /sandbox und fertig. Wenn es das autonome Build-System ist, das Docker, MCP-Server und Netzwerkzugang braucht -- dann braucht man Level-3-Isolation. Welches Level-3-Tool? Das hängt davon ab, was schon im Stack ist und wer neue Software absegnet.

Ich habe zu lang damit verbracht, aufwändige Container-in-VM-in-VM-Architekturen zu designen, obwohl die Antwort viel einfacher war. Und dann habe ich noch mehr Zeit damit verbracht zu lernen, dass "einfacher" trotzdem "für jeden Kunden anders" bedeutet. Aber so ist das halt -- manchmal muss man den komplizierten Weg gehen, um den einfachen zu finden. Und dann stellt sich raus, dass es mehrere einfache gibt.

Hat jemand anderes diese Progression durchgemacht? Ich würde besonders gern von Teams hören, die Agentic Workflows in Enterprise-Umgebungen fahren -- was ist eure Container Runtime, und hat eure Sandboxing-Entscheidung den ersten Kontakt mit Procurement überlebt?

Ressourcen

Offizielle Dokumentation

• Docker Sandboxes for Claude Code -- Dockers offizieller Guide (microVM-Architektur, 4.58+)
• Anthropic Sandbox Dokumentation -- native /sandbox Command Details
• anthropic-experimental/sandbox-runtime -- Open-Source Sandbox Runtime (sandbox-exec + bubblewrap)
• Apple Containerization (WWDC 2025) -- per-Container VM-Isolation, macOS 26

VM- und Container-Runtimes

• Lima -- CNCF-Projekt für Linux-VMs auf macOS
• Colima -- Lima-Wrapper mit Docker/containerd/Incus-Support
• OrbStack -- schnelles Linux-VM- und Container-Management für macOS
• Tart -- Apple-Virtualization.framework-VMs für CI
• Podman Desktop -- Open Source, rootless, daemonless Container-Management
• How Podman runs on Macs -- Red Hats Architektur-Überblick (applehv, libkrun)

Community Sandbox-Projekte

• Trail of Bits claude-code-devcontainer -- security-gehärteter DevContainer mit Colima-Support
• nikvdp/cco -- "Claude Condom" auto-detecting Sandbox Wrapper
• textcortex/claude-code-sandbox -- Web UI, erkennt Docker und Podman automatisch
• RchGrav/claudebox -- sprachspezifische Docker-Profile für Claude Code
• neko-kai/claude-code-sandbox -- Sandbox, die $HOME Read-Zugriff blockiert
• EvanCarroll/claude-podman -- rootless Podman Sandbox für Claude Code
• scottrigby/claudeman -- Podman-nativer Wrapper mit Multi-Session-Support

Benchmarks und Performance

• Paolo Mainardi: Docker on macOS is still slow? (Januar 2025) -- M4 Pro Benchmarks, Lima/OrbStack/Docker Desktop verglichen
• OrbStack: Truly fast container filesystems on macOS (Mai 2024) -- Vendor Benchmark, 75-95% native Performance Claim
• DDEV: macOS Docker Provider Performance (November 2023) -- unabhängiger Multi-Provider-Vergleich
• Docker Blog: Speed boost on Docker Desktop 4.6 (März 2022) -- virtiofs vs gRPC-FUSE, "bis zu 90% schneller"
• Jeff Geerling: virtiofs file sync is 4x faster (März 2022) -- unabhängige virtiofs-Validierung

Security-Referenzen

• CVE-2025-9074 -- Docker Desktop Engine API Exposure (CVSS 9.3)
• OrbStack Issue #2295 -- Docker Sandboxes nicht auf OrbStack unterstützt
• OrbStack Issue #169 -- File Sharing kann nicht pro Maschine deaktiviert werden

Evaluierungen und Reviews

• Arcade.dev Sandbox Testing -- Real-World Docker Sandbox Evaluierung
• Matt Pocock über Docker Sandboxes -- "best DX of any local AI coding sandbox"
• RepoFlow: Apple Containers vs Docker Desktop vs OrbStack (November 2025) -- FIO + Metadata Benchmarks auf M4