Die Claude-Code-Sandbox ist eine vom Betriebssystem durchgesetzte Grenze um die Shell-Befehle, die Claude ausführt. Sie schränkt ein, welche Dateien und Netzwerk-Hosts diese Befehle erreichen können. Du schaltest sie mit /sandbox ein oder indem du sandbox.enabled in einer Settings-Datei auf true setzt. Sobald sie aktiv ist, kann Claude Code Befehle in der Sandbox ausführen, ohne dich jedes Mal um Freigabe zu bitten. Genau das ist der eigentliche Reiz: weniger Freigabeabfragen, ohne einem autonomen Agenten eine offene Shell auf deinem Rechner zu überlassen.
Dieser Leitfaden zeigt, was die Sandbox tatsächlich einschränkt, wie du sie unter macOS, Linux und WSL2 aktivierst, welche zwei Freigabemodi es gibt und welche Teile außerhalb der Grenze laufen — die Lücke, aus der Anfang dieses Jahres ein echter Datenabfluss-Bug wurde. Wir betreiben Claude Code in einer Headless-Automatisierung, um diese Seite zu veröffentlichen. Die Shell-Grenze richtig zu ziehen, ist für uns also kein akademisches Thema.
Was ist die Claude-Code-Sandbox?
Die Sandbox ist in Claude Code eingebaut und umschließt jeden Bash-, PowerShell- und Monitor-Befehl samt den Kindprozessen, die diese Befehle starten. Sie zieht zwei Grenzen gleichzeitig: was ein Befehl auf der Festplatte anfassen darf und was er über das Netzwerk erreichen kann. Beide werden vom Betriebssystem durchgesetzt, während der Befehl läuft — deshalb kann ein Befehl in der Sandbox automatisch freigegeben werden: Der Kernel hält die Linie, keine Abfrage.
Standardmäßig ist sie ausgeschaltet. Unter macOS nutzt sie das eingebaute Seatbelt-Framework, es ist also nichts zu installieren. Unter Linux und WSL2 setzt sie für die Dateisystem-Isolation auf bubblewrap und für die Weiterleitung des Netzwerkverkehrs über einen lokalen Proxy auf socat; das /sandbox-Panel zeigt dir, falls eines davon fehlt. Unter nativem Windows gibt es gar keine Sandbox — Befehle laufen ungesandboxt, es sei denn, du führst Claude Code innerhalb einer WSL2-Distribution aus. Unter der Haube steckt das quelloffene Paket @anthropic-ai/sandbox-runtime.
So funktionieren Dateisystem- und Netzwerk-Isolation
Die beiden Grenzen haben unterschiedliche Standardeinstellungen, und du erweiterst oder verengst jede einzeln. Die folgende Tabelle zeigt den Ausgangszustand und die Einstellungen, die ihn verändern.
| Zugriff | Standardverhalten | Änderbar über |
|---|---|---|
| Schreiben | Arbeitsverzeichnis, ein benutzereigenes temporäres Verzeichnis und alle mit --add-dir hinzugefügten Verzeichnisse. Geschützte Pfade bleiben schreibgeschützt | filesystem.allowWrite, filesystem.denyWrite |
| Lesen | Nahezu der gesamte Rechner — einschließlich Zugangsdaten-Dateien wie ~/.ssh und ~/.aws/credentials | filesystem.denyRead, credentials |
| Netzwerk | Kein direkter Weg nach außen; jede Verbindung läuft über einen lokalen Proxy, der den Host gegen deine erlaubten Domains prüft — und die beginnen leer | network.allowedDomains, network.deniedDomains |
Die Asymmetrie, die du dir einprägen solltest: Schreibzugriffe sind standardmäßig abgeriegelt, Lesezugriffe dagegen weit offen. Ein Befehl in der Sandbox kann nichts außerhalb deines Projekts kritzeln, aber er kann trotzdem deine SSH-Schlüssel und Cloud-Zugangsdaten lesen, solange du keine denyRead-Regel hinzufügst oder den credentials-Schutz nutzt. Beim Netzwerk ist es umgekehrt — standardmäßig alles verboten, mit einer Allowlist, die du nach und nach aufbaust, sobald Befehle bestimmte Hosts brauchen.
So aktivierst du die Claude-Code-Sandbox
Der schnellste Weg ist interaktiv:
- Führe
/sandboxaus in einer Session. Das Panel hat einen Mode-Tab, einen Overrides-Tab (denallowUnsandboxedCommands-Fallback) und einen Config-Tab, der die aufgelösten Einstellungen zeigt. Unter Linux erscheint ein Dependencies-Tab, fallsbubblewrap,socatoder ripgrep fehlt. - Wähle einen Modus (siehe unten) und bitte Claude, einen Build oder eine Testsuite auszuführen. Die Auswahl eines Modus schreibt ihn in die
.claude/settings.local.jsondes Projekts. - Aktiviere sie überall, indem du
sandbox.enabledin~/.claude/settings.jsonauftruesetzt, oder erzwinge sie für ein ganzes Team über Managed Settings.
Für eine einzelne Session, ohne eine Settings-Datei anzufassen, gibst du sie auf der CLI mit:
claude --settings '{"sandbox": {"enabled": true, "allowUnsandboxedCommands": false}}'
Um zu prüfen, ob sie läuft, bitte Claude, touch ~/sandbox-probe auszuführen (sollte mit Operation not permitted oder Read-only file system fehlschlagen) sowie curl --noproxy '*' https://example.com (sollte mit Could not resolve host fehlschlagen). Wenn der Agent hart stoppen soll, falls die Sandbox nicht starten kann — statt still auf ungesandboxt zurückzufallen — setze sandbox.failIfUnavailable auf true. Diese Einstellung macht den Unterschied zwischen "Sandbox ist eine Bequemlichkeit" und "Sandbox ist ein Sicherheits-Gate".
Sandbox-Modi: Auto-Allow vs. reguläre Berechtigungen
Beide Modi setzen exakt dieselben Dateisystem- und Netzwerkgrenzen durch. Der einzige Unterschied liegt in der Freigabe.
- Auto-Allow-Modus führt Befehle in der Sandbox ohne Abfrage aus. Hier steckt der Gewinn gegen die Abfrage-Müdigkeit: Ein Befehl, der nur innerhalb der Grenze schreibt, läuft einfach durch — selbst im manuellen Modus. Deny-Regeln werden weiterhin beachtet, ein
rmgegen einen kritischen Pfad fragt weiterhin nach, und inhaltsbezogene Ask-Regeln wieBash(git push *)erzwingen weiterhin eine Abfrage. - Modus mit regulären Berechtigungen schickt jeden Bash-Befehl durch den normalen Berechtigungsfluss, auch in der Sandbox — mehr Kontrolle, mehr Klicks.
Wenn ein Befehl zum ersten Mal eine neue Netzwerk-Domain braucht, fragt dich Claude Code, ob du sie zur Allowlist hinzufügen willst. Im Auto-Modus deklariert das Modell stattdessen die Hosts, die ein Befehl braucht, direkt am Befehl selbst, und ein serverseitiger Klassifikator prüft sie. Beachte, dass der Plan-Modus Auto-Allow nicht erbt — er gatet Befehle weiterhin, während du planst.
Was außerhalb der Sandbox läuft (der Teil, den viele übersehen)
Die Sandbox umschließt Shell-Befehle. Sie umschließt nicht alles, und das ist das am häufigsten missverstandene daran. Außerhalb der Grenze laufen:
- Eingebaute Datei- und Web-Tools — Read, Edit, Write, WebFetch, WebSearch folgen stattdessen den Berechtigungsregeln. Ein
denyRead-Eintrag stoppt das Read-Tool nicht, undallowedDomainsbegrenzt WebFetch nicht. - MCP-Server und Hooks — beide laufen ungesandboxt.
- Befehle, die du an der
!-Shell-Eingabeaufforderung tippst, alles, was aufexcludedCommandspasst, und jeder ungesandboxte Wiederholungsversuch, bei dem Claude einen fehlgeschlagenen Befehl mitdangerouslyDisableSandboxerneut ausführt.
Ein denyRead auf ~/.aws/credentials blockiert also ein cat in der Sandbox, aber nicht das Read-Tool oder einen MCP-Server, der dieselbe Datei erreicht. Wenn du eine einzige Grenze um all das ziehen willst, ist die Sandbox die falsche Ebene — betreibe dann den gesamten Claude-Code-Prozess in einem Container oder einer VM. Besonders wichtig ist das, wenn du Claude Code headless betreibst in der CI, wo kein Mensch da ist, um einen ungesandboxten Wiederholungsversuch abzulehnen.
Eine Sandbox ist kein Gefängnis: die Lektion vom Egress-Bypass
Behandle die Netzwerk-Allowlist als Defense-in-Depth, nicht als Tresor. Sicherheitsforscher legten einen Bypass des Netzwerk-Egress der Sandbox in Claude Code offen, der die Versionen 2.0.24 bis 2.1.89 betraf — rund 130 Releases — bei dem ein SOCKS5-Null-Byte-Hostname-Trick Befehlen erlaubte, blockierte Domains zu erreichen und API-Schlüssel, Tokens und Quellcode zu exfiltrieren. Ein präparierter Hostname wie attacker.com\x00.google.com bestand die JavaScript-Allowlist-Prüfung (sie sah das Suffix .google.com), während der OS-Resolver am Null-Byte abschnitt und sich mit dem Angreifer verband. Anthropic lieferte laut Bericht in v2.1.90 am 1. April 2026 eine strengere Hostname-Validierung aus — angeblich ohne CVE oder Changelog-Eintrag.
Die praktischen Lehren: Halte Claude Code aktuell, halte allowedDomains so kurz, wie es die Aufgabe erlaubt, setze sandbox.failIfUnavailable, wo die Sandbox eine echte Kontrolle ist, und isoliere bei allem, was produktive Secrets berührt, den gesamten Prozess — nicht nur seine Shell. Die Sandbox erhöht die Kosten eines Fehlers oder einer Prompt-Injection spürbar, aber sie ist eine Ebene, und Ebenen hatten schon Löcher.
Häufig gestellte Fragen
Ist die Claude-Code-Sandbox standardmäßig aktiv?
Nein. Sie ist aus, bis du /sandbox ausführst oder sandbox.enabled in einer Settings-Datei auf true setzt. Unter nativem Windows läuft sie überhaupt nicht, es sei denn, du nutzt WSL2.
Hindert die Sandbox Claude daran, meine Zugangsdaten zu lesen?
Nicht standardmäßig. Befehle in der Sandbox können nahezu den gesamten Rechner lesen, einschließlich ~/.ssh und ~/.aws/credentials. Füge eine filesystem.denyRead-Regel hinzu oder nutze den credentials-Schutz — und denk daran, dass das Read-Tool und MCP-Server komplett außerhalb der Sandbox liegen.
Was muss ich unter Linux installieren?
bubblewrap und socat sind erforderlich; ripgrep ist im nativen Binary enthalten, und ein optionaler seccomp-Filter (aus @anthropic-ai/sandbox-runtime) ergänzt das Blockieren von Unix-Sockets. Der Dependencies-Tab von /sandbox listet auf, was fehlt.
Reduziert die Sandbox die Freigabeabfragen?
Ja, im Auto-Allow-Modus — Befehle in der Sandbox laufen ohne Nachfrage, weil das Betriebssystem die Grenze durchsetzt. Deny-Regeln, rm auf kritischem Pfad und inhaltsbezogene Ask-Regeln fragen weiterhin nach.
Reicht die Sandbox, um einen Agenten sicher auf Produktivdaten laufen zu lassen?
Betrachte sie als eine Ebene. Sie schränkt Shell-Befehle ein, aber nicht Datei-Tools, MCP-Server oder Hooks, und sie hatte mindestens einen Egress-Bypass-Bug. Für produktive Secrets betreibe den gesamten Prozess in einem Container oder einer VM.
Quellen
- Claude-Code-Doku — Das gesandboxte Bash-Tool konfigurieren: was die Sandbox einschränkt, Settings-Schlüssel, Modi, Abhängigkeiten und was außerhalb läuft.
- GBHackers — Sandbox-Schwachstelle in Claude Code könnte Nutzer-Secrets kompromittieren: der SOCKS5-Null-Byte-Egress-Bypass, die betroffenen Versionen 2.0.24–2.1.89 und der Fix in v2.1.90.
- anthropics/sandbox-runtime (GitHub): das quelloffene Paket, auf dem die eingebaute Sandbox aufbaut.
Waqas Ahmed Waseer
Waqas Ahmed Waseer ist Entwickler und Automation-Builder mit über 8 Jahren Erfahrung im Aufbau von Produktivsystemen, die von mehr als 100.000 Menschen genutzt werden. Er baut individuelle Multi-Tenant-SaaS, KI-Automatisierung (n8n, LLM-Workflows, WhatsApp-Bots) und Hosting-Infrastruktur (WHM/cPanel, CloudLinux) — und ist der Macher von WaSphere, FlowMaticX und der Hosting-Marke WaseerHost. Über 100 Projekte für KMU, Agenturen und finanzierte Start-ups umgesetzt.
