Claude Code Sandboxing: Datei- und Netzwerkisolation

Claude Code kann Dateien löschen, Shell-Befehle ausführen und Netzwerkverbindungen aufbauen - genau das macht es als Coding-Agenten nützlich, und genau das macht die Frage berechtigt, was passiert, wenn ein Befehl das Falsche trifft. Ein Grundlagenartikel dieses Blogs hat dafür bereits die zentrale Unterscheidung eingeführt: Eine Regel in CLAUDE.md oder einem Skill ist eine Bitte an das Modell, keine Garantie; verbindlich wird eine Vorgabe erst über Hooks oder Managed Settings.

Sandboxing setzt eine Ebene tiefer an. Selbst wenn ein Befehl über Permission-Regeln freigegeben wurde - als sicher eingestuft, vom Auto-Mode-Classifier durchgewinkt, oder weil die Session mit --dangerously-skip-permissions läuft - , bleibt offen, was dieser Befehl während seiner Ausführung tatsächlich erreichen kann. Genau hier setzt der native Sandbox-Modus an: keine weitere Regel, die Claude interpretiert, sondern eine Grenze, die das Betriebssystem selbst durchsetzt - für jeden Bash-Befehl und dessen Kindprozesse.

Dieser Artikel ordnet ein, was der native Sandbox-Modus konkret einschränkt, wie er sich zu Permission-Regeln verhält, welche Betriebssystem-Voraussetzungen gelten, was er ausdrücklich nicht abdeckt, und welche offiziell dokumentierten Alternativen es für striktere Isolation gibt. Alle Angaben beziehen sich auf den Dokumentationsstand August 2026 und die Referenzversion 2.1.238 - Claude Code erscheint mehrmals wöchentlich, prüfen Sie versionsgebundene Details vor einem Rollout gegen die dann aktuelle Dokumentation.

Sandboxing vs. Permissions: eine zusätzliche, tiefere Ebene

Permission-Regeln und Sandboxing kontrollieren unterschiedliche Dinge, und Anthropic zieht diese Grenze explizit. Permission-Regeln entscheiden, ob ein Tool-Aufruf überhaupt läuft - geprüft, bevor irgendetwas ausgeführt wird, basierend auf dem Befehlstext und, im Auto-Mode, dem Urteil eines Classifiers. Sandboxing entscheidet, was ein bereits laufender Befehl erreichen kann, durchgesetzt vom Betriebssystem auf den laufenden Prozess. Ein Allow-Eintrag für npm install etwa prüft nur den Befehlsstring - er weiß nicht, ob das aufgerufene Skript im Hintergrund zusätzlich eine Datei außerhalb des Projekts überschreibt. Die Sandbox blockiert einen solchen Zugriff auf Syscall-Ebene, unabhängig davon, wie vertrauenswürdig der Befehl eingestuft wurde.

Damit ergänzt Sandboxing exakt die Lücke, die die „Bitte vs. Garantie”-Unterscheidung aus dem Grundlagenartikel offenlässt: Hooks erzwingen, dass eine Regel greift, bevor ein Tool-Aufruf passiert. Die Sandbox erzwingt eine Grenze, während ein bereits zugelassener Befehl läuft. Beide Mechanismen sind komplementär, nicht austauschbar - und beide folgen derselben Zero-Trust-Denkweise, die dieser Blog auch für Agenten-Identitäten in Microsoft-Umgebungen einordnet.

Eine Einschränkung gehört von Anfang an in dieses Bild: Der native Sandbox-Modus isoliert ausschließlich Bash-Befehle und ihre Kindprozesse. Eingebaute Datei-Tools wie Read, Edit und Write laufen im Claude-Code-Prozess selbst und werden über das Permission-System für Pfade gesteuert, nicht über die Sandbox. MCP-Server und Hooks sind eigene Prozesse, die auf dem Host unbeschränkt laufen.

Was die Sandbox beim Dateisystem einschränkt

Standardmäßig dürfen sandboxed Befehle nur in das aktuelle Arbeitsverzeichnis und dessen Unterverzeichnisse schreiben, dazu in das Session-Temp-Verzeichnis, auf das $TMPDIR zeigt. Ein Schreibversuch außerhalb dieser Grenze scheitert am Betriebssystem selbst - mit einer Fehlermeldung auf Syscall-Ebene, nicht an einer Interpretation durch das Modell.

Beim Lesen ist die Voreinstellung deutlich offener: Sandboxed Befehle dürfen praktisch den gesamten Rechner lesen, mit Ausnahme einiger explizit gesperrter Verzeichnisse. Das gilt auch für Credential-Dateien wie ~/.aws/credentials oder ~/.ssh/ - wer das verhindern will, muss es explizit über sandbox.credentials oder sandbox.filesystem.denyRead konfigurieren, es passiert nicht automatisch nur weil die Sandbox aktiv ist.

Zusätzlich schützt die Sandbox unabhängig von Ihrer eigenen Konfiguration eine feste Liste von Pfaden vor Schreibzugriff, selbst innerhalb sonst beschreibbarer Verzeichnisse: die .claude-Settings-Dateien, .claude/skills, .claude/agents, .claude/hooks, .mcp.json, Shell-Startdateien wie .bashrc, sowie hooks und config innerhalb von .git. Ein Befehl, der diese Dateien ändern könnte, könnte sich selbst zusätzliche Berechtigungen verschaffen oder einen Hook bzw. MCP-Server hinzufügen, der anschließend außerhalb der Sandbox läuft. Diese Sperre lässt sich nicht durch eine allowWrite-Regel für den betroffenen Pfad aufheben - einzige Ausnahme ist sandbox.filesystem.disabled, was allerdings die gesamte Dateisystem-Isolation deaktiviert, nicht nur diesen einen Pfad.

Sollen Subprozess-Tools wie kubectl, terraform oder npm außerhalb des Arbeitsverzeichnisses schreiben dürfen, ist der dokumentierte Weg sandbox.filesystem.allowWrite statt eines pauschalen Ausschlusses aus der Sandbox:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"]
    }
  }
}

Solche Pfad-Arrays werden über alle Settings-Ebenen hinweg gemergt, nicht ersetzt - dieselbe Merge-Logik wie bei Permission-Regeln, die der Grundlagenartikel beschreibt. Über denyWrite, denyRead und ein erneut öffnendes allowRead innerhalb einer gesperrten Region lässt sich die Leseregel zusätzlich verschärfen - etwa das gesamte Home-Verzeichnis sperren, aber das Projektverzeichnis wieder freigeben.

Was die Sandbox beim Netzwerkzugriff einschränkt

Netzwerkzugriff läuft bei sandboxed Befehlen über einen lokalen Proxy außerhalb der Sandbox, nicht über Kernel-Blocking auf Paketebene. Claude Code erlaubt standardmäßig keine einzige Domain im Voraus. Braucht ein Befehl zum ersten Mal eine neue Domain, fragt Claude Code nach - oder im Auto-Mode entscheidet der Classifier. Wird zugestimmt, bleibt der Host für den Rest der Session erlaubt; mit „Yes, and don’t ask again” landet eine WebFetch(domain:...)-Regel dauerhaft in den lokalen Settings.

Für den Produktiveinsatz lassen sich Domains vorab freigeben, um Prompts zu vermeiden:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Wer statt eines Prompts eine harte Sperre will, setzt strictAllowlist in User-, Managed- oder --settings-Konfiguration - Hosts außerhalb der Allowlist werden dann verweigert; in Projekt- oder Local-Settings hat der Schlüssel keine Wirkung. allowManagedDomainsOnly erzwingt zusätzlich, dass ausschließlich die Managed-Liste zählt.

Zentral für die Risikobewertung: Der eingebaute Proxy terminiert und inspiziert per Default kein TLS. Er entscheidet allein anhand des angefragten Hostnamens, ob eine Verbindung zulässig ist - der Inhalt bleibt ungeprüft. Anthropic weist selbst darauf hin, dass eine breit gefasste Domain wie github.com einen Exfiltrationsweg eröffnen kann, etwa über Domain-Fronting. Ein experimentelles network.tlsTerminate lässt den Proxy TLS selbst terminieren, fügt aber keine Content-Filterung hinzu. Wer stärkere Garantien braucht, muss einen eigenen Proxy mit TLS-Inspektion konfigurieren.

Ergänzend erlaubt sandbox.credentials, Zugangsdaten-Dateien und Umgebungsvariablen gezielt vor sandboxed Befehlen zu verbergen - komplett sperren (deny) oder durch einen Platzhalter ersetzen, der beim Rausgehen über eine erlaubte Domain durch den echten Wert ersetzt wird (mask). So sieht ein Befehl nie den echten Token, kann sich aber trotzdem authentifizieren - relevant für Rollouts mit sensiblen Zugangsdaten.

Sandbox aktivieren: /sandbox, settings.json und die zwei Modi

Der Sandbox-Modus ist standardmäßig deaktiviert. Aktivieren lässt er sich auf drei Wegen:

Interaktiv über den Befehl /sandbox, der ein Panel mit den Tabs Mode, Overrides und Config öffnet - Auswahl in diesem Panel landet in den lokalen Projekt-Settings unter .claude/settings.local.json.
Für alle eigenen Projekte über sandbox.enabled: true in den User-Settings unter ~/.claude/settings.json.
Für die gesamte Organisation über denselben Schlüssel in Managed Settings - dazu mehr im Abschnitt weiter unten.

Innerhalb des Panels stehen zwei Modi zur Wahl, die dieselben Dateisystem- und Netzwerk-Restriktionen durchsetzen und sich nur darin unterscheiden, wie ein sandboxed Befehl freigegeben wird:

Auto-allow führt sandboxable Befehle automatisch aus, ohne nachzufragen - die Sandbox-Grenze selbst übernimmt die Rolle, die sonst der Permission-Prompt hätte. Ausdrückliche Deny-Regeln, kritische Pfade bei rm/rmdir und inhaltsbezogene Ask-Regeln wie Bash(git push *) gelten trotzdem weiter.
Regular permissions lässt jeden Bash-Befehl weiterhin durch den normalen Permission-Flow laufen, auch wenn er sandboxed läuft - mehr Kontrolle, mehr Rückfragen.

Für Befehle, die innerhalb der Sandbox scheitern - etwa weil ein Tool mit ihr inkompatibel ist oder einen nicht erlaubten Host braucht - , sieht Claude Code eine Ausweich-Option vor: Claude kann den Befehl mit dem Parameter dangerouslyDisableSandbox außerhalb der Sandbox erneut versuchen, wonach der reguläre Permission-Flow greift. Mit "allowUnsandboxedCommands": false lässt sich diese Ausweich-Option vollständig abschalten - dann muss jeder Befehl sandboxed laufen oder explizit in excludedCommands gelistet sein.

Ein Detail zur Fehlertoleranz: Fehlen Abhängigkeiten oder läuft die Plattform ohne Unterstützung, zeigt Claude Code standardmäßig nur eine Warnung und führt Befehle unsandboxed aus - die Sandbox scheitert also lautlos in einen offenen Zustand. Wer das nicht will, setzt sandbox.failIfUnavailable: true, damit ein fehlender Sandbox-Start Claude Code am Starten hindert, statt klammheimlich auf ungeschützten Betrieb zurückzufallen.

Betriebssystem-Voraussetzungen: Seatbelt, bubblewrap, kein natives Windows

Der native Sandbox-Modus nutzt je Plattform unterschiedliche, jeweils im Betriebssystem vorhandene Isolationsmechanismen:

Plattform	Mechanismus	Voraussetzungen
macOS	Seatbelt (`sandbox-exec`-Framework)	keine zusätzliche Installation nötig
Linux	bubblewrap	Pakete `bubblewrap` und `socat`; optionaler Seccomp-Filter für Unix-Socket-Blocking
WSL2	bubblewrap (wie Linux)	WSL2 zwingend - WSL1 wird nicht unterstützt, da bubblewrap Kernel-Features benötigt, die nur unter WSL2 verfügbar sind
Windows (nativ)	nicht unterstützt	Claude Code muss unter WSL2 laufen, um die Sandbox zu nutzen

Auf Ubuntu 24.04 und neuer verhindert die Default-AppArmor-Policy teils, dass bubblewrap die benötigten User-Namespaces erzeugt - Anthropic dokumentiert dafür ein nachzutragendes AppArmor-Profil für bwrap. /sandbox prüft beim Start selbst, ob eine Abhängigkeit fehlt. Für gemischte Windows-Flotten bleibt die Konsequenz einfach: Auf einem nativen Windows-Host lässt sich der Bash-Sandbox-Modus nicht aktivieren, Organisationen müssen auf WSL2 setzen oder auf eine der Container-/VM-Alternativen weiter unten ausweichen - ein Punkt, der bei einem Intune-Rollout von Managed Settings mitgedacht werden sollte.

Was die Sandbox ausdrücklich nicht verhindert

Anthropic dokumentiert die Grenzen der eigenen Sandbox ungewöhnlich offen - ein Abschnitt „Security limitations”, der für eine ehrliche Risikoeinschätzung Pflichtlektüre ist, bevor man sich auf die Sandbox als alleinige Kontrolle verlässt:

Kein Content-Filtering bei Netzwerkverkehr - wie oben beschrieben bleibt eine breit gefasste erlaubte Domain ein potenzieller Exfiltrationsweg.
Unix-Sockets können die Sandbox aushebeln. Wird etwa /var/run/docker.sock über allowUnixSockets freigegeben, entspricht das faktisch vollem Host-Zugriff über den Docker-Daemon.
Zu breite Schreibrechte ermöglichen Privilege Escalation - etwa Schreibzugriff auf Verzeichnisse mit Programmen im $PATH, Systemkonfiguration oder Shell-Startdateien.
enableWeakerNestedSandbox schwächt die Isolation bewusst, um bubblewrap den Betrieb in einem unprivilegierten Container ohne eigene Namespaces zu erlauben - laut Doku nur zu verwenden, wenn eine andere Schicht die eigentliche Isolationsgarantie bereits übernimmt.
Apple Events auf macOS sind ein Alles-oder-nichts-Schalter. allowAppleEvents behebt Fehler bei open, osascript oder Auth-Flows, hebt dabei aber die Code-Ausführungs-Isolation komplett auf.
Umgebungsvariablen werden standardmäßig vollständig vererbt, einschließlich darin gesetzter Zugangsdaten - Schutz gibt es nur über sandbox.credentials oder CLAUDE_CODE_SUBPROCESS_ENV_SCRUB.
Computer Use und Subagents bleiben außerhalb bzw. innerhalb derselben Grenze. Steuert Claude Bildschirm oder Anwendungen direkt, läuft das ungesandboxed auf dem echten Desktop; Subagents dagegen übernehmen einfach die Sandbox-Konfiguration der Hauptsession, ohne eigene, engere Grenze.

Anthropics eigene Zusammenfassung bringt die Kernaussage auf den Punkt: Ohne Netzwerk-Isolation könnte ein kompromittierter Agent sensible Dateien wie SSH-Schlüssel exfiltrieren; ohne Dateisystem-Isolation könnte er sich einen Weg zurück zu Netzwerkzugriff verschaffen. Beide Schichten müssen zusammenwirken - wer die eine aufweicht, sollte prüfen, ob dadurch die Schutzwirkung der anderen unterlaufen wird.

Alternativen für strengere Isolation: Sandbox-Runtime, Container, VMs

Wer mehr als Bash-Befehle absichern will, findet dafür mehrere offiziell dokumentierte Ansätze, keine Community-Bastellösungen. Anthropic vergleicht sie auf einer eigenen Seite, sortiert nach Isolationstiefe:

Sandbox-Runtime (@anthropic-ai/sandbox-runtime, npm-Paket): wrappt den kompletten Claude-Code-Prozess in dieselbe Seatbelt-/bubblewrap-Isolation wie der Bash-Sandbox-Modus - dann sind auch Datei-Tools, MCP-Server und Hooks erfasst. Anthropic führt das Paket ausdrücklich als „beta research preview” mit noch änderbarem Konfigurationsformat. Start über npx @anthropic-ai/sandbox-runtime claude, Konfiguration über ~/.srt-settings.json.
Dev Container: Claude Code läuft komplett in einem Docker-Container, den ein Editor wie VS Code verwaltet, mit dem Projektverzeichnis eingebunden. Anthropics Referenzkonfiguration bringt ein init-firewall.sh-Skript mit Default-Deny-iptables-Firewall mit - ausdrücklich „provided as a working example rather than a maintained base image”, eignet sich laut Anthropic damit auch für unbeaufsichtigtes --dangerously-skip-permissions.
Custom Container: jedes Docker- oder OCI-Image mit eigenen Netzwerk-Policies, Volumes und Seccomp-Profilen - üblicher Weg für Organisationen mit bestehender Container-Infrastruktur oder CI-Runnern; der Bash-Sandbox-Modus lässt sich zusätzlich darin aktivieren.
Virtuelle Maschine: die stärkste Trennung, mit eigenem Kernel und, bei Cloud-/MicroVM-Deployments, eigener virtualisierter Hardware - Cloud-Instanzen, lokale Hypervisoren oder MicroVMs wie Firecracker, laut Anthropic für nicht vertrauenswürdigen Code oder Kernel-Trennung aus Compliance-Gründen. Als konkretes Produkt nennt Anthropic Docker Sandboxes: eine MicroVM mit eigenem Docker-Daemon, kostenloses Standalone-Produkt ohne Docker-Desktop-Voraussetzung.
Claude Code on the web: jede Session läuft in einer isolierten, Anthropic-verwalteten VM, mit Netzwerk-Proxy und Default-Allowlist sowie einem separaten Proxy, der das GitHub-Token außerhalb der Sandbox hält.

Ein zentraler Hinweis relativiert alle Optionen gleichermaßen: Isolation ändert nichts daran, was an das Modell gesendet wird - Prompts und gelesene Dateien gehen mit oder ohne Sandbox an die Anthropic-API oder den konfigurierten Provider. Die Sandbox begrenzt, was ein kompromittierter Prozess tun kann, nicht, was Claude sieht.

Anthropics Faustregel: Für alltägliche Arbeit reicht der eingebaute Bash-Sandbox-Modus. Für unbeaufsichtigten Betrieb mit --dangerously-skip-permissions oder Auto-Mode empfiehlt Anthropic Container, VM oder Sandbox-Runtime, da der Bash-Sandbox-Modus allein weder MCP-Server noch Hooks abdeckt. Für nicht vertrauenswürdige Repositories stehen eine dedizierte VM oder Claude Code on the web im Vordergrund.

Sandbox per Managed Settings organisationsweit erzwingen

Von den hier vorgestellten Ansätzen lässt sich nur der eingebaute Bash-Sandbox-Modus direkt durch Claude Code selbst organisationsweit erzwingen - über die sandbox-Schlüssel in Managed Settings, geliefert als Datei über MDM oder als server-managed Settings. Ein Beispiel, das die Sandbox verpflichtend macht und die Ausweich-Option unterbindet:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

Für boolesche Schlüssel wie enabled gilt der Managed-Wert unbedingt, lokale Entwickler-Einstellungen werden ignoriert. Array-Schlüssel wie excludedCommands oder allowRead werden dagegen über die Ebenen gemergt - ein Entwickler kann sie erweitern, aber nicht die Managed-Vorgabe entfernen. Wer das verhindern will, setzt zusätzlich allowManagedReadPathsOnly bzw. allowManagedDomainsOnly, damit ausschließlich Managed-Einträge zählen. Da der Sandbox-Modus unter nativem Windows nicht läuft, muss eine solche Policy für gemischte Flotten auf macOS und Linux beschränkt oder mit einer Vorgabe für WSL2 bzw. Container kombiniert werden.

Dev Container, Custom Container und VM lassen sich dagegen nicht über Claude-Code-eigene Mechanismen erzwingen - hier bleibt nur, das Standard-Image über organisationsweites Device-Management oder Software-Allowlisting durchzusetzen. Wie sich der sandbox-Schlüssel neben den übrigen Managed-Settings-Kategorien konkret per Intune ausrollen lässt, vertieft der eigene Rollout-Artikel. Wer zusätzlich mit Agent Teams arbeitet, sollte die Interaktion mit dem Permission-Modus im Blick behalten: Teammates starten laut Anthropic mit dem Permission-Modus der Hauptsession - läuft die Hauptsession mit --dangerously-skip-permissions, gilt das auch für jedes Teammate. Näher ordnet das der Agent-Teams-Artikel dieses Blogs ein.

Aus unseren Projekten: Bei KRITIS-Kunden setzen wir den Sandbox-Modus ein, um die Arbeitsumgebung abzusichern - dort ist der Nachweis, dass ein Werkzeug nicht unkontrolliert auf das System zugreifen kann, Teil der Anforderung und keine Komfortfrage.

Häufige Fragen zum Claude Code Sandbox-Modus

Ist der Sandbox-Modus in Claude Code standardmäßig aktiv?

Nein. Er muss explizit aktiviert werden - interaktiv über /sandbox, dauerhaft für alle eigenen Projekte über sandbox.enabled: true in den User-Settings, oder organisationsweit über denselben Schlüssel in Managed Settings.

Läuft der Sandbox-Modus unter Windows?

Nativ nicht. Unterstützt werden macOS (Seatbelt), Linux (bubblewrap) und WSL2 (ebenfalls bubblewrap) - WSL1 fällt heraus. Auf einem nativen Windows-Host bleibt nur der Umweg über WSL2, einen Container oder eine VM.

Schützt die Sandbox auch MCP-Server und Hooks?

Nein. Der eingebaute Bash-Sandbox-Modus isoliert ausschließlich Bash-Befehle und deren Kindprozesse; MCP-Server und Hooks laufen als eigene Prozesse unbeschränkt auf dem Host. Dafür braucht es die Sandbox-Runtime, einen Dev Container, einen Custom Container oder eine VM.

Reicht der native Sandbox-Modus für unbeaufsichtigten Betrieb mit `--dangerously-skip-permissions`?

Laut Anthropics eigener Einordnung nicht allein. Empfohlen werden dafür Container, VM oder Sandbox-Runtime, weil diese auch Datei-Tools, MCP-Server und Hooks in die Isolationsgrenze einschließen.

Was verhindert die Sandbox ausdrücklich nicht?

Unter anderem: Inhaltsprüfung von TLS-verschlüsseltem Netzwerkverkehr, Missbrauch freigegebener Unix-Sockets, Privilege Escalation über zu breite Schreibrechte, sowie jeden Zugriff über Computer Use oder eingebaute Datei-Tools außerhalb der Sandbox-Grenze.

Fazit

Der native Sandbox-Modus von Claude Code schließt eine Lücke, die Permission-Regeln allein nicht schließen können: Er entscheidet nicht, ob ein Befehl laufen darf, sondern begrenzt auf Betriebssystemebene, was er während der Ausführung erreichen kann. Auf macOS und Linux/WSL2 lässt sich das mit überschaubarem Aufwand aktivieren; unter nativem Windows bleibt nur der Umweg über WSL2 oder eine der schwereren Alternativen. Wer unbeaufsichtigten Betrieb plant oder MCP-Server und Hooks in dieselbe Grenze einschließen will, braucht mehr als den Bash-Sandbox-Modus - Sandbox-Runtime, Dev Container oder VM sind dafür die offiziell dokumentierten Wege, keine erfundenen Community-Behelfe. Sandboxing reduziert Risiko, ersetzt aber keine bewusste Entscheidung darüber, welche Domains, Pfade und Zugangsdaten überhaupt erreichbar sein müssen.

Quellen (Stand: August 2026, Abruf 20.08.2026, Referenzversion 2.1.238):