Konfigurieren Sie das Sandboxed-Bash-Tool

Erfahren Sie, wie das Sandboxed-Bash-Tool von Claude Code Dateisystem- und Netzwerkisolation für sicherere und autonomere Agent-Ausführung bietet.

Die Bash-Sandbox ermöglicht es Claude, die meisten Shell-Befehle auszuführen, ohne um Genehmigung zu fragen. Anstatt jeden Befehl zu genehmigen, definieren Sie, welche Dateien und Netzwerk-Domains Befehle berühren können, und das Betriebssystem erzwingt diese Grenze für jeden Bash-Befehl und seine Kindprozesse.

Diese Seite behandelt Folgendes:

• Aktivieren Sie die Sandbox und wählen Sie, wie Sandbox-Befehle genehmigt werden
• Konfigurieren Sie, welche Pfade und Netzwerk-Domains Befehle erreichen können
• Kombinieren Sie Sandboxing mit Genehmigungsregeln und Genehmigungsmodi
• Erzwingen Sie Sandboxing in einer Organisation mit verwalteten Einstellungen

Erste Schritte

Die Sandbox ist in Claude Code integriert und läuft auf macOS, Linux und WSL2. Native Windows wird nicht unterstützt. Führen Sie Claude Code unter Windows in einer WSL2-Distribution aus.

Auf macOS gibt es nichts zu installieren: Sandboxing verwendet das integrierte Seatbelt-Framework. Auf Linux und WSL2 basiert die Sandbox auf zwei Paketen, die in Linux und WSL2 einrichten behandelt werden. Selbst wenn Sie diese noch nicht installiert haben, können Sie mit /sandbox beginnen, da sein Panel anzeigt, ob etwas fehlt.

/sandbox

Wenn Sie einen Modus im Panel auswählen, wird in die lokalen Einstellungen Ihres Projekts unter .claude/settings.local.json geschrieben, die für das aktuelle Projekt gelten und nicht in Git eingecheckt werden. Um die Sandbox in allen Ihren Projekten zu aktivieren, setzen Sie sandbox.enabled auf true in Ihren Benutzereinstellungen unter ~/.claude/settings.json. Um Sandboxing für jeden Entwickler in einer Organisation zu erzwingen, verwenden Sie verwaltete Einstellungen.

Linux und WSL2 einrichten

Auf Linux und WSL2 basiert die Sandbox auf zwei Paketen:

• bubblewrap: das unprivilegierte Sandboxing-Tool, das Dateisystem-Isolation erzwingt
• socat: das Relay, das verwendet wird, um Netzwerk-Datenverkehr durch den Sandbox-Proxy zu leiten

Installieren Sie diese mit dem Paketmanager Ihrer Distribution:

sudo apt-get install bubblewrap socat

sudo dnf install bubblewrap socat

Nach der Installation zeigt die Registerkarte 'Dependencies" in /sandbox an, ob ripgrep, bubblewrap, socat und der Seccomp-Filter auf Ihrer Plattform verfügbar sind. Ripgrep ist mit der nativen Claude Code-Binärdatei gebündelt. Der Seccomp-Filter ist optional und fügt Unix-Domain-Socket-Blockierung hinzu. Installieren Sie ihn mit npm install -g @anthropic-ai/sandbox-runtime, wenn er fehlt.

Wenn eine erforderliche Abhängigkeit fehlt, ist die Registerkarte „Dependencies" die einzige angezeigte Registerkarte, bis Sie sie installieren. Die Abhängigkeitsprüfung läuft beim Start, daher starten Sie Claude Code nach der Installation von Paketen neu, damit /sandbox diese erkennt.

Um zu überprüfen, ob Ihre Umgebung diese Einschränkung erzwingt, auch in WSL2, führen Sie `sysctl kernel.apparmor_restrict_unprivileged_userns` aus. Wenn der Schlüssel nicht existiert oder `0` zurückgibt, überspringen Sie diesen Schritt. Wenn er `1` zurückgibt, fügen Sie ein AppArmor-Profil hinzu, das `bwrap` diese Fähigkeit gewährt:

```bash theme={null}
sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
```

Das Profil gilt nur für `bwrap` selbst, nicht für die Befehle, die es in der Sandbox ausführt. Laden Sie AppArmor neu, um es anzuwenden:

```bash theme={null}
sudo systemctl reload apparmor
```

Sandbox-Modi

Claude Code bietet zwei Sandbox-Modi:

Auto-Allow-Modus: Bash-Befehle werden versuchen, in der Sandbox ausgeführt zu werden und sind automatisch zulässig, ohne dass eine Genehmigung erforderlich ist. Befehle, die nicht in der Sandbox ausgeführt werden können, z. B. solche, die Netzwerkzugriff auf nicht zulässige Hosts benötigen, fallen auf den regulären Genehmigungsfluss zurück, bei dem Claude Code Ihre Genehmigungsregeln überprüft und Sie für jeden Befehl auffordert, den diese Regeln nicht bereits zulassen.

Selbst im Auto-Allow-Modus gelten folgende Punkte:

• Explizite Deny-Regeln werden immer respektiert
• rm- oder rmdir-Befehle, die auf /, Ihr Home-Verzeichnis oder andere kritische Systempfade abzielen, lösen immer noch eine Genehmigungseingabe aus
• Inhaltsgebundene Ask-Regeln wie Bash(git push *) erzwingen immer noch eine Eingabeaufforderung, auch für Sandbox-Befehle
• Eine einfache Bash Ask-Regel oder die entsprechende Bash(*) Form wird für Befehle übersprungen, die in der Sandbox ausgeführt werden; sie gilt immer noch für Befehle, die auf den regulären Genehmigungsfluss zurückfallen

Regulärer Genehmigungsmodus: Alle Bash-Befehle durchlaufen den regulären Genehmigungsfluss, auch wenn sie in der Sandbox ausgeführt werden. Dies bietet mehr Kontrolle, erfordert aber mehr Genehmigungen.

In beiden Modi erzwingt die Sandbox die gleichen Dateisystem- und Netzwerk-Einschränkungen. Der Unterschied liegt nur darin, ob Sandbox-Befehle automatisch genehmigt oder explizit genehmigt werden müssen.

Das Sitzungs-Temp-Verzeichnis ist standardmäßig in der Sandbox beschreibbar, zusammen mit dem Arbeitsverzeichnis. Claude Code setzt $TMPDIR auf dieses Verzeichnis für Sandbox-Befehle, sodass Tools, die temporäre Dateien schreiben, ohne zusätzliche Konfiguration funktionieren. Unsandboxed-Befehle erben Ihr Shell-$TMPDIR unverändert, was bedeutet, dass Sandbox- und Unsandboxed-Befehle $TMPDIR in verschiedene Verzeichnisse auflösen. Um temporäre Dateien zwischen den beiden zu übergeben, schreiben Sie sie stattdessen unter das Arbeitsverzeichnis.

Einige Befehle können überhaupt nicht in der Sandbox ausgeführt werden, z. B. Tools, die nicht kompatibel sind oder einen Host benötigen, den Sie nicht zulässig gemacht haben. Anstatt die Aufgabe fehlschlagen zu lassen oder Sie zu zwingen, Sandboxing auszuschalten, enthält Claude Code eine Fluchtluke: Wenn ein Befehl aufgrund von Sandbox-Einschränkungen fehlschlägt, analysiert Claude den Fehler und kann den Befehl mit dem Parameter dangerouslyDisableSandbox erneut versuchen. Der erneut versuchte Befehl läuft außerhalb der Sandbox, daher durchläuft er den regulären Genehmigungsfluss und erfordert Ihre Genehmigung.

Sie können diese Fluchtluke deaktivieren, indem Sie "allowUnsandboxedCommands": false in Ihren Sandbox-Einstellungen setzen. Wenn deaktiviert, was die Registerkarte /sandbox Overrides als Strict Sandbox Mode anzeigt, wird der Parameter dangerouslyDisableSandbox vollständig ignoriert und alle Befehle müssen in der Sandbox ausgeführt oder explizit in excludedCommands aufgelistet werden.

Sandboxing konfigurieren

Passen Sie das Sandbox-Verhalten durch Ihre settings.json-Datei an. Siehe Einstellungen für die vollständige Konfigurationsreferenz.

Standardmäßig können Sandbox-Befehle nur in das aktuelle Arbeitsverzeichnis und das Sitzungs-Temp-Verzeichnis schreiben. Wenn Subprozess-Befehle wie kubectl, terraform oder npm außerhalb dieser Verzeichnisse schreiben müssen, verwenden Sie sandbox.filesystem.allowWrite, um Zugriff auf spezifische Pfade zu gewähren:

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

Diese Pfade werden auf OS-Ebene durchgesetzt, daher respektieren alle Befehle, die in der Sandbox ausgeführt werden, einschließlich ihrer Kindprozesse, diese. Dies ist der empfohlene Ansatz, wenn ein Tool Schreibzugriff auf einen bestimmten Ort benötigt, anstatt das Tool mit excludedCommands vollständig aus der Sandbox auszuschließen.

Wenn das gleiche Dateisystem-Array in mehreren Einstellungs-Scopes definiert ist, werden die Arrays zusammengeführt: Pfade aus jedem Scope werden kombiniert, nicht ersetzt.

Pfad-Präfixe steuern, wie Pfade aufgelöst werden:

Diese Syntax unterscheidet sich von Read- und Edit-Genehmigungsregeln, die //path für absolut und /path für projekt-relativ verwenden. Sandbox-Dateisystem-Pfade verwenden Standard-Konventionen: /tmp/build ist absolut.

Sie können auch Schreib- oder Lesezugriff mit sandbox.filesystem.denyWrite und sandbox.filesystem.denyRead blockieren und spezifische Pfade innerhalb einer blockierten Region mit sandbox.filesystem.allowRead erneut zulassen.

Das folgende Beispiel blockiert das Lesen aus dem gesamten Home-Verzeichnis und erlaubt gleichzeitig Lesevorgänge aus dem aktuellen Projekt. Platzieren Sie es in der Datei .claude/settings.json Ihres Projekts, da der relative Pfad . nur aufgelöst wird, wenn die Konfiguration in Projekt-Einstellungen lebt:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

Das . in allowRead wird zum Projekt-Root aufgelöst, da diese Konfiguration in Projekt-Einstellungen lebt. Wenn Sie die gleiche Konfiguration in ~/.claude/settings.json platzieren würden, würde . stattdessen zu ~/.claude aufgelöst, und Projektdateien würden durch die denyRead-Regel blockiert bleiben.

Wie Sandboxing funktioniert

Dateisystem-Isolation

Das Sandboxed-Bash-Tool beschränkt den Dateisystem-Zugriff auf spezifische Verzeichnisse:

• Standard-Schreibverhalten: Lese- und Schreibzugriff auf das aktuelle Arbeitsverzeichnis und seine Unterverzeichnisse, plus das Session-Temp-Verzeichnis, auf das $TMPDIR verweist
• Standard-Leseverhalten: Lesezugriff auf den gesamten Computer, außer bestimmten blockierten Verzeichnissen. Beachten Sie, dass diese Standard-Einstellung immer noch das Lesen von Anmeldedatendateien wie ~/.aws/credentials und ~/.ssh/ ermöglicht. Fügen Sie diese zu denyRead hinzu, um sie zu blockieren.
• Blockierter Zugriff: Kann Dateien außerhalb des aktuellen Arbeitsverzeichnisses und des Session-Temp-Verzeichnisses nicht ohne explizite Genehmigung ändern, einschließlich Shell-Konfigurationsdateien wie ~/.bashrc und System-Binärdateien in /bin/
• Git Worktrees: Wenn das Arbeitsverzeichnis ein verknüpftes Git Worktree ist, erlaubt die Sandbox auch Schreibzugriff auf das gemeinsame .git-Verzeichnis des Haupt-Repositorys, damit Befehle wie git commit Refs und den Index aktualisieren können. Schreibzugriffe auf hooks/ und config in diesem Verzeichnis bleiben blockiert.
• Konfigurierbar: Definieren Sie benutzerdefinierte zulässige und blockierte Pfade durch Einstellungen

Sie können Schreibzugriff auf zusätzliche Pfade mit sandbox.filesystem.allowWrite in Ihren Einstellungen gewähren. Diese Einschränkungen werden auf OS-Ebene durchgesetzt, daher gelten sie für alle Subprozess-Befehle, einschließlich Tools wie kubectl, terraform und npm, nicht nur für Claudes Datei-Tools.

Netzwerk-Isolation

Der Netzwerkzugriff wird durch einen Proxy-Server gesteuert, der außerhalb der Sandbox läuft:

• Domain-Einschränkungen: Keine Domains sind vorab zulässig. Wenn ein Befehl zum ersten Mal eine neue Domain benötigt, fordert Claude Code zur Genehmigung auf. Lassen Sie Domains vorab mit allowedDomains zu, um die Eingabeaufforderung zu vermeiden.
• Verwaltete Sperrung: Wenn allowManagedDomainsOnly in verwalteten Einstellungen gesetzt ist, werden nicht zulässige Domains automatisch blockiert, anstatt zu fragen, und nur allowedDomains aus verwalteten Einstellungen werden berücksichtigt.
• Benutzerdefinierte Proxy-Unterstützung: Fortgeschrittene Benutzer können benutzerdefinierte Regeln für ausgehenden Datenverkehr implementieren
• Umfassende Abdeckung: Einschränkungen gelten für alle Skripte, Programme und Subprozesse, die durch Befehle erzeugt werden

OS-Level-Durchsetzung

Das Sandboxed-Bash-Tool nutzt Betriebssystem-Sicherheits-Primitive:

• macOS: Verwendet Seatbelt für Sandbox-Durchsetzung
• Linux: Verwendet bubblewrap für Isolation
• WSL2: Verwendet bubblewrap, wie Linux

WSL1 wird nicht unterstützt, da bubblewrap Kernel-Features erfordert, die nur in WSL2 verfügbar sind. Diese OS-Level-Einschränkungen stellen sicher, dass alle Kindprozesse, die durch Claude Code-Befehle erzeugt werden, die gleichen Sicherheitsgrenzen erben.

Diese gleichen Primitive sind als das eigenständige Paket @anthropic-ai/sandbox-runtime verfügbar, das die Seite Sandbox-Umgebungen als separaten Ansatz zum Wrapping des gesamten Claude Code-Prozesses behandelt.

Wie Sandboxing sich auf Genehmigungen und Genehmigungsmodi bezieht

Sandboxing, Genehmigungsregeln und Genehmigungsmodi sind komplementäre Schichten. Die folgenden Abschnitte behandeln, wie die Sandbox mit jedem interagiert.

Genehmigungsregeln

Genehmigungsregeln und Sandboxing steuern verschiedene Dinge:

• Genehmigungsregeln steuern, welche Tools Claude Code verwenden kann, und werden evaluiert, bevor ein Tool ausgeführt wird. Sie gelten für alle Tools: Bash, Read, Edit, WebFetch, MCP und andere.
• Sandboxing bietet OS-Level-Durchsetzung, die einschränkt, worauf Bash-Befehle auf Dateisystem- und Netzwerk-Ebene zugreifen können. Es gilt nur für Bash-Befehle und ihre Kindprozesse.

Die beiden Schichten unterscheiden sich auch in ihrer Durchsetzung. Claude Code evaluiert Genehmigungsentscheidungen, bevor ein Befehl ausgeführt wird, basierend auf der Befehlszeichenfolge und, im Auto-Modus, dem Urteil eines separaten Klassifizierers darüber, ob der Befehl sicher ist. Das Betriebssystem erzwingt die Sandbox-Grenze auf dem laufenden Prozess, daher gilt sie unabhängig davon, was das Modell ausführen wollte, und selbst wenn ein zulässiger Befehl mehr tut als sein Name vermuten lässt.

Dateisystem- und Netzwerk-Einschränkungen werden sowohl durch Sandbox-Einstellungen als auch durch Genehmigungsregeln konfiguriert:

Pfade aus beiden sandbox.filesystem-Einstellungen und Genehmigungsregeln werden zusammengeführt in die endgültige Sandbox-Konfiguration.

Das Repository der claude-code mit Beispielen enthält Starter-Einstellungskonfigurationen für häufige Bereitstellungsszenarien, einschließlich Sandbox-spezifischer Beispiele. Verwenden Sie diese als Ausgangspunkte und passen Sie sie an Ihre Anforderungen an.

Genehmigungsmodi

/sandbox ist kein Genehmigungsmodus. Genehmigungsmodi entscheiden, ob ein Tool-Aufruf ausgeführt wird und ob Sie zuerst aufgefordert werden, während die Sandbox einschränkt, worauf ein Bash-Befehl zugreifen kann, sobald er ausgeführt wird. Sie unterscheiden sich darin, was sie steuern und was die Pro-Aktion-Eingabeaufforderung ersetzt:

Der Auto-Allow-Modus der Sandbox ist separat vom Auto-Modus: Auto-Allow genehmigt Bash-Befehle, weil die Sandbox-Grenze sie enthält, während der Auto-Modus einen Klassifizierer verwendet, um Aktionen zu überprüfen. Die beiden funktionieren unabhängig und können kombiniert werden. Um eine Isolationsgrenze für unbeaufsichtigte Läufe zu wählen, siehe Sandbox-Umgebungen.

Konfigurieren Sie die Sandbox für Ihre Organisation

Administratoren können Sandboxing für jeden Benutzer erfordern, Entwickler daran hindern, die Richtlinie zu erweitern, und Sandbox-Datenverkehr durch einen Unternehmens-Proxy leiten.

Erzwingen Sie Sandboxing mit verwalteten Einstellungen

Um die Sandbox für jeden Entwickler zu erfordern, liefern Sie die sandbox-Schlüssel über verwaltete Einstellungen, entweder als Datei, die von Ihrem MDM verwaltet wird, oder über server-verwaltete Einstellungen auf Claude.ai.

Die folgende Konfiguration verwalteter Einstellungen aktiviert die Sandbox, weigert sich, Claude Code zu starten, wenn die Sandbox nicht initialisiert werden kann, und verhindert, dass das Modell Befehle außerhalb der Sandbox erneut versucht:

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

Die beiden Schlüssel über enabled hinaus steuern, was passiert, wenn die Sandbox einen Befehl nicht ausführen kann:

• failIfUnavailable: Eine fehlende Abhängigkeit wie bubblewrap auf Linux blockiert Claude Code vom Start, anstatt eine Warnung anzuzeigen und auf unsandboxed-Ausführung zurückzufallen
• allowUnsandboxedCommands: false: Die Fluchtluke dangerouslyDisableSandbox wird ignoriert, daher können Befehle, die unter der Sandbox fehlschlagen, nicht außerhalb davon erneut versucht werden

Zwei Ergänzungen sind erwägenswert. Fügen Sie excludedCommands für alle von der Organisation genehmigten Tools hinzu, die ohne Isolation ausgeführt werden müssen. Fügen Sie denyRead-Einträge für Anmeldedaten-Verzeichnisse wie ~/.aws und ~/.ssh hinzu, die die Standard-Lesrichtlinie immer noch zulässt.

Die Sandbox läuft nicht auf native Windows, daher müssen Sie diese Konfiguration auf macOS und Linux beschränken oder diese Benutzer Claude Code in WSL2 oder einem Container ausführen lassen, wenn Ihre Flotte Windows-Hosts enthält.

Verhindern Sie, dass Entwickler die Richtlinie erweitern

Für boolesche Schlüssel wie enabled und failIfUnavailable verwendet Claude Code den verwalteten Wert und ignoriert alles, das ein Entwickler lokal setzt. Für Array-Schlüssel wie excludedCommands und allowRead führt Claude Code Einträge aus jedem Scope zusammen, daher kann ein Entwickler Einträge anhängen, die die Richtlinie erweitern.

Setzen Sie allowManagedReadPathsOnly auf true in verwalteten Einstellungen, damit nur allowRead-Einträge aus verwalteten Einstellungen berücksichtigt werden. Benutzer-, Projekt- und lokale allowRead-Einträge werden ignoriert. Dies verhindert, dass Entwickler den Lesezugriff über die von der Organisation genehmigten Pfade hinaus erweitern. Um Netzwerk-Domains auf die gleiche Weise auf die verwalteten Werte zu sperren, setzen Sie allowManagedDomainsOnly.

excludedCommands hat keine äquivalente verwaltete Sperrung, daher kann ein Entwickler immer Einträge anhängen, die zusätzliche Befehle außerhalb der Sandbox ausführen. Halten Sie die verwaltete Liste eng.

Benutzerdefinierte Proxy-Konfiguration

Für Organisationen, die erweiterte Netzwerk-Sicherheit erfordern, können Sie einen benutzerdefinierten Proxy implementieren, um:

• HTTPS-Datenverkehr zu entschlüsseln und zu inspizieren
• Benutzerdefinierte Filterregeln anzuwenden
• Alle Netzwerk-Anfragen zu protokollieren
• Mit bestehender Sicherheitsinfrastruktur zu integrieren

Um Claude Code auf Ihren Proxy zu verweisen, setzen Sie die Proxy-Ports in Sandbox-Einstellungen:

{
  "sandbox": {
    "network": {
      "httpProxyPort": 8080,
      "socksProxyPort": 8081
    }
  }
}

Fehlerbehebung

Einige Befehle schlagen in der Sandbox fehl, obwohl sie außerhalb davon funktionieren. Die folgenden Fixes behandeln die häufigsten Fälle.

• Befehle schlagen mit einem Host-not-allowed-Fehler fehl: Viele CLI-Tools müssen bestimmte Hosts erreichen. Das Gewähren der Genehmigung bei Aufforderung fügt den Host zu Ihrer Zulassungsliste hinzu, damit das Tool in Zukunft in der Sandbox ausgeführt wird.
• jest hängt oder schlägt fehl: watchman ist nicht kompatibel mit der Sandbox. Führen Sie stattdessen jest --no-watchman aus.
• Go-basierte CLIs schlagen TLS-Verifizierung auf macOS fehl: Tools wie gh, gcloud und terraform können unter Seatbelt TLS-Verifizierung fehlschlagen. Listen Sie diese Tools in excludedCommands auf, um sie außerhalb der Sandbox auszuführen. Wenn Sie httpProxyPort mit einem MITM-Proxy und benutzerdefinierter CA verwenden, setzen Sie stattdessen enableWeakerNetworkIsolation auf true.
• open, osascript oder browserbasierte Authentifizierungsflows schlagen mit Fehler -600 auf macOS fehl: Die Sandbox blockiert Apple Events standardmäßig. Setzen Sie allowAppleEvents in Ihren Benutzer-, verwalteten oder CLI-Einstellungen auf true, um diese zuzulassen. Projekteinstellungen werden für diesen Schlüssel ignoriert. Das Aktivieren entfernt die Code-Ausführungsisolation, da Sandbox-Befehle dann andere Anwendungen ohne Benutzeraufforderung unsandboxed starten können und AppleScript-Befehle an laufende Anwendungen senden können, unterliegen jedoch der macOS-Automatisierungszustimmungsaufforderung (TCC). Alternativ können Sie den Befehl zu excludedCommands hinzufügen, um ihn außerhalb der Sandbox auszuführen.
• docker-Befehle schlagen fehl: docker ist nicht kompatibel mit der Sandbox. Fügen Sie docker * zu excludedCommands hinzu, um es außerhalb der Sandbox auszuführen.
• Bubblewrap schlägt beim Start in einem Container fehl: In einem unprivilegierten Container kann bubblewrap kein frisches /proc-Dateisystem mounten. Setzen Sie enableWeakerNestedSandbox auf true, damit die innere Sandbox das vorhandene /proc des Containers bind-mountet. Verwenden Sie diese Einstellung nur, wenn der äußere Container bereits die Isolationsgrenze bietet, die Sie benötigen, da sie Prozessinformationen für Sandbox-Befehle verfügbar macht, die ein frisches /proc-Mount verbergen würde.
• Seccomp-Filter auf Linux: Der Seccomp-Filter ist erforderlich, um Unix-Domain-Sockets zu blockieren. Die Registerkarte „Dependencies" in /sandbox zeigt an, ob er verfügbar ist. Wenn er fehlt, führen Sie npm install -g @anthropic-ai/sandbox-runtime aus, um den Helper zu installieren.
• --dangerously-skip-permissions schlägt als Root fehl: Dieses Flag wird blockiert, wenn es als Root oder über sudo auf Linux und macOS ausgeführt wird, da Root-Zugriff kombiniert mit keinen Genehmigungseingaben jede Datei oder jeden Service auf dem System ändern kann. Die Prüfung wird automatisch in einer erkannten Sandbox übersprungen. Um autonom in einem Container auszuführen, verwenden Sie die Dev-Container-Konfiguration, die Claude Code als Nicht-Root-Benutzer ausführt.

Einschränkungen

Sandboxing reduziert das Risiko, ist aber keine vollständige Isolationsgrenze. Überprüfen Sie die folgenden Einschränkungen, bevor Sie sich darauf als Hard-Sicherheitskontrolle verlassen.

Sicherheitsbeschränkungen

• Netzwerk-Filterung: Das Netzwerk-Filtersystem funktioniert durch Einschränkung der Domains, mit denen Prozesse verbunden werden dürfen. Der integrierte Proxy beendet oder führt keine TLS-Inspektion auf ausgehenden Datenverkehr durch, daher werden die Inhalte verschlüsselter Verbindungen nicht untersucht. Sie sind verantwortlich dafür, dass nur vertrauenswürdige Domains in Ihrer Richtlinie zulässig sind.

• Privilege Escalation über Unix-Sockets: Die Konfiguration allowUnixSockets kann versehentlich Zugriff auf leistungsstarke System-Services gewähren, die zu Sandbox-Umgehungen führen könnten. Wenn Sie beispielsweise Zugriff auf /var/run/docker.sock zulassen, würde dies effektiv Zugriff auf das Host-System durch den Docker-Socket gewähren. Überdenken Sie sorgfältig alle Unix-Sockets, die Sie durch die Sandbox zulassen.
• Dateisystem-Genehmigungseskalation: Übermäßig breite Dateisystem-Schreibgenehmigungen können Privilege-Escalation-Angriffe ermöglichen. Das Zulassen von Schreibvorgängen zu Verzeichnissen, die ausführbare Dateien in $PATH, System-Konfigurationsverzeichnisse oder Benutzer-Shell-Konfigurationsdateien wie .bashrc oder .zshrc enthalten, kann zu Code-Ausführung in verschiedenen Sicherheitskontexten führen, wenn andere Benutzer oder System-Prozesse auf diese Dateien zugreifen.
• Linux-Sandbox-Stärke: Die Linux-Implementierung bietet starke Dateisystem- und Netzwerk-Isolation, enthält aber einen enableWeakerNestedSandbox-Modus, der es ermöglicht, in Docker-Umgebungen ohne privilegierte Namespaces zu funktionieren, oder auf Linux-Hosts, wo unprivilegierte Benutzer-Namespaces durch sysctl deaktiviert sind. Diese Option schwächt die Sicherheit erheblich ab und sollte nur verwendet werden, wenn zusätzliche Isolation anderweitig durchgesetzt wird.
• Apple Events auf macOS: Die macOS-Sandbox blockiert Apple Events standardmäßig. Die Einstellung allowAppleEvents hebt diese Einschränkung auf, damit Tools wie open und osascript funktionieren, aber es entfernt Code-Ausführungs-Isolation: Sandbox-Befehle können andere Anwendungen ohne Sandbox ohne Benutzer-Eingabeaufforderung starten und können AppleScript-Befehle an laufende Anwendungen senden, vorbehaltlich der Pro-App-macOS-Automatisierungs-Zustimmungsaufforderung (TCC). Es wird nur von Benutzer-, verwalteten oder CLI-Einstellungen berücksichtigt. Projekteinstellungen können es nicht aktivieren.
• Einstellungsdateien geschützt: Die Sandbox verweigert automatisch Schreibzugriff auf Claude Code's settings.json-Dateien in jedem Scope und auf das verwaltete Einstellungsverzeichnis, daher kann ein Sandbox-Befehl seine eigene Richtlinie nicht ändern.

Plattform- und Tool-Kompatibilität

• Plattform-Unterstützung: Unterstützt macOS, Linux und WSL2. WSL1 und native Windows werden nicht unterstützt.
• Performance-Overhead: Minimal, aber einige Dateisystem-Operationen können leicht langsamer sein.
• Tool-Kompatibilität: Einige Tools, die spezifische System-Zugriffsmuster erfordern, benötigen möglicherweise Konfigurationsanpassungen oder müssen möglicherweise außerhalb der Sandbox ausgeführt werden.

Umfang

Die Sandbox isoliert Bash-Subprozesse. Andere Tools funktionieren unter verschiedenen Grenzen:

• Integrierte Datei-Tools: Read, Edit und Write verwenden das Genehmigungssystem direkt, anstatt durch die Sandbox zu laufen. Siehe Genehmigungen.
• Computer-Nutzung: Wenn Claude Apps öffnet und Ihren Bildschirm steuert, läuft es auf Ihrem tatsächlichen Desktop, anstatt in einer isolierten Umgebung. Pro-App-Genehmigungseingaben kontrollieren jede Anwendung. Siehe Computer-Nutzung in der CLI oder Computer-Nutzung auf Desktop.
• Umgebungsvariablen: Sandbox-Bash-Befehle erben die Umgebung des übergeordneten Prozesses standardmäßig, einschließlich aller dort gesetzten Anmeldedaten. Um Anthropic- und Cloud-Provider-Anmeldedaten aus Subprozessen zu entfernen, setzen Sie CLAUDE_CODE_SUBPROCESS_ENV_SCRUB.
• Subagenten: Subagenten laufen im gleichen Prozess wie die übergeordnete Sitzung und verwenden die gleiche Sandbox-Konfiguration. Bash-Befehle in einem Subagenten werden in der Sandbox ausgeführt, wenn Sandboxing in der übergeordneten Sitzung aktiviert ist.

Siehe auch

• Sandbox-Umgebungen: Vergleichen Sie die integrierte Sandbox mit Dev-Containern, Containern und VMs
• Sicherheit: Umfassende Sicherheitsfeatures und Best Practices
• Genehmigungen: Genehmigungskonfiguration und Zugriffskontrolle
• Einstellungen: Vollständige Konfigurationsreferenz
• CLI-Referenz: Befehlszeilenoptionen