Skip to main content
Die Isolierung von Claude Code begrenzt, was eine Sitzung auf dem Dateisystem lesen, schreiben und im Netzwerk erreichen kann. Dies ist besonders wichtig, wenn Sie Claude mit weniger Genehmigungseingaben arbeiten lassen, es unbeaufsichtigt ausführen oder es auf Code verweisen, dem Sie nicht vollständig vertrauen. Claude Code kann in mehreren Arten isolierter Umgebungen ausgeführt werden, von einer leichtgewichtigen Sandbox pro Befehl bis zu einer vollständig separaten virtuellen Maschine. Diese Seite vergleicht sie danach, was sie isolieren und was sie erfordern, hilft Ihnen, eine für Ihr Bedrohungsmodell auszuwählen, und zeigt, wie Sie diese Wahl in einer Organisation durchsetzen.
Für das umfassendere Sicherheitsmodell siehe Sicherheit. Für Agent SDK-Bereitstellungen siehe Sichere Bereitstellung.

​
Sandboxing-Ansätze vergleichen

Die ersten beiden Ansätze in der folgenden Tabelle werden auf dem Host-Betriebssystem ohne Container ausgeführt. Die übrigen platzieren Claude Code in einem Container oder einer virtuellen Maschine. Das Sandboxed Bash tool ist in Claude Code integriert und beschränkt nur Bash-Befehle. Integrierte Datei-Tools, MCP-Server und Hooks werden weiterhin direkt auf Ihrem Host ausgeführt. Jeder andere Ansatz in der Tabelle platziert den gesamten Claude Code-Prozess innerhalb der Isolierungsgrenze, sodass auch Datei-Tools, MCP-Server und Hooks eingeschränkt sind.
Sandbox-Isolation reduziert die Auswirkungen einer Sicherheitsverletzung, beseitigt aber nicht das Risiko. Jeder Ansatz, der Netzwerk-Egress ermöglicht, kann immer noch Daten durchsickern lassen, die der Agent lesen kann, und jeder Ansatz, der Ihr Projektverzeichnis beschreibbar bereitstellt, kann immer noch diesen Code ändern. Überprüfen Sie die Sicherheitsbeschränkungen, bevor Sie sich auf eine Sandbox als harte Kontrolle verlassen.Isolation ändert auch nicht, was an das Modell gesendet wird. Ihre Eingabeaufforderungen und die Dateien, die Claude liest, werden an die Anthropic API oder Ihren konfigurierten Anbieter mit oder ohne Sandbox übertragen. Siehe Datennutzung für das, was Claude Code sendet und wie Sie es reduzieren können.

​
Wählen Sie einen Ansatz

Ordnen Sie Ihr Ziel einer Zeile unten zu und lesen Sie dann den folgenden Detailabschnitt.

​
Wie Isolation mit Berechtigungsmodi zusammenhängt

Berechtigungsmodi entscheiden, ob ein Tool-Aufruf ausgeführt wird und ob Sie zuerst aufgefordert werden. Isolation beschränkt, was ein Befehl nach der Ausführung zugreifen kann. Die beiden arbeiten zusammen: Wenn ein Berechtigungsmodus Aktionen ohne Nachfrage ausführen lässt, begrenzt eine Isolierungsgrenze, was diese Aktionen erreichen können. Wenn Sie --dangerously-skip-permissions übergeben, handelt Claude ohne vorherige Nachfrage. Die Aktionen, die kein Modus automatisch genehmigt gelten weiterhin. Ohne Eingabeaufforderungen, um Fehler zu erkennen, ist die Isolierungsgrenze, die Sie wählen, das, was Ihr System schützt. Führen Sie --dangerously-skip-permissions-Sitzungen immer in einem Container, einer VM oder der Sandbox Runtime aus, damit Datei-Tools, MCP-Server und Hooks auch innerhalb der Grenze liegen. Unter Linux und macOS weigert sich Claude Code, mit diesem Flag zu starten, wenn es als Root ausgeführt wird. Führen Sie daher den Container, die VM oder die Sandbox Runtime als Nicht-Root-Benutzer aus. Auto-Modus ersetzt die Eingabeaufforderung durch einen Klassifizierer, der Aktionen überprüft. Der Klassifizierer ist eine Kontrolle pro Aktion, keine Isolierungsgrenze, daher fügt eine Isolierungsgrenze immer noch Verteidigungstiefe für unbeaufsichtigte Läufe hinzu und ist nicht erforderlich, wie es für --dangerously-skip-permissions der Fall ist. Das Sandboxed Bash tool allein beschränkt nur Shell-Befehle, daher ist es nicht ausreichend für vollständig unbeaufsichtigte Läufe in beiden Modi. Sie können Ansätze schichten: Das Ausführen des Sandboxed Bash tool in einem Container oder VM gibt Ihnen OS-Ebenen-Befehlsbeschränkungen zusätzlich zur äußeren Umgebungsgrenze. Für die Interaktion der Bash-Sandbox selbst mit Berechtigungsregeln und Modi siehe Wie Sandboxing mit Berechtigungen und Berechtigungsmodi zusammenhängt.

​
Sandboxed Bash tool

Diese Option unterstützt nicht natives Windows. Verwenden Sie auf Windows-Hosts WSL2 oder einen der Container- oder VM-Ansätze unten.
Das Sandboxed Bash tool ist in Claude Code integriert. Es verwendet Betriebssystem-Primitive, um den Dateisystem- und Netzwerkzugriff jedes Bash-, PowerShell- oder Monitor-Befehls, den Claude ausführt, einzuschränken. Führen Sie den /sandbox-Befehl aus, um das Sandbox-Panel zu öffnen und einen Modus auszuwählen. Der Sandboxing-Leitfaden behandelt die Genehmigungsmodi, die Standardgrenze und wie Sie sie erweitern oder einengen. Die Sandbox pro Befehl deckt nicht alles ab, das in einer Sitzung ausgeführt wird:
  • Andere integrierte Tools wie Read, Edit und WebFetch werden im Claude Code-Prozess ausgeführt und führen keinen beliebigen Code aus. Berechtigungsregeln für Pfad oder Domain kontrollieren sie stattdessen.
  • MCP-Server und command hooks sind separate Prozesse, die unkontrolliert auf dem Host ausgeführt werden.
Um integrierte Tools, MCP-Server und Hooks alle hinter einer OS-Grenze zu platzieren, führen Sie den gesamten Claude Code-Prozess in der Sandbox Runtime, dem Dev Container oder einem Custom Container aus.

​
Sandbox Runtime

Das @anthropic-ai/sandbox-runtime-Paket umhüllt einen gesamten Prozess mit der gleichen Seatbelt- oder bubblewrap-Isolation, die die integrierte Bash-Sandbox verwendet. Das Ausführen von Claude Code durch die Runtime beschränkt neben Shell-Befehlen auch die Tools, Hooks und MCP-Server der Sitzung. Die Runtime ist eine Beta-Research-Preview, und ihr Konfigurationsformat kann sich ändern, wenn sich das Paket weiterentwickelt. Dieser Abschnitt behandelt, was Sie konfigurieren und was die Runtime von selbst erzwingt. Informationen zum Bereitstellen der Runtime in Agent SDK-Anwendungen finden Sie im Leitfaden zur sicheren Bereitstellung.

​
Einrichtung und Start der Runtime

Unter Linux und WSL2 basiert die Runtime auf den gleichen bubblewrap- und socat-Paketen wie die integrierte Sandbox, plus ripgrep, das Claude Code bündelt, aber die eigenständige Runtime aus Ihrem PATH auflöst. Installieren Sie bubblewrap und socat wie in Einrichtung von Linux und WSL2 beschrieben, und ripgrep aus dem Paketmanager Ihrer Distribution. Unter macOS benötigen Sie keine zusätzlichen Pakete. Die Runtime verwendet dort die integrierte Seatbelt-Sandbox. Standardmäßig verweigert die Runtime den Netzwerkzugriff und beschränkt Schreibvorgänge auf eine kleine Menge integrierter Runtime-Pfade, daher konfigurieren Sie sie vor dem Start von Claude Code durch sie. Legen Sie Ihre Konfiguration in ~/.srt-settings.json oder in einer Datei ab, die Sie mit --settings übergeben. Die Paket-README dokumentiert das Konfigurationsschema. Erlauben Sie Schreibzugriff auf mindestens:
  • Ihr Projektverzeichnis.
  • Claude Codes Konfigurationspfade ~/.claude und ~/.claude.json.
  • Das Verzeichnis, in das Claude Code Runtime-Dateien schreibt. Sofern Sie nicht CLAUDE_CODE_TMPDIR setzen, ist dieses Verzeichnis:
    • Linux und WSL2: /tmp
    • macOS: /private/tmp. /tmp ist ein Symlink auf dieses Verzeichnis, und Seatbelt prüft den aufgelösten Pfad.
Erlauben Sie die Netzwerk-Domains, die Ihre Sitzung benötigt:
  • api.anthropic.com oder den Endpunkt Ihres konfigurierten Anbieters. Bei einem Drittanbieter behalten Sie auch api.anthropic.com bei: Die WebFetch-Domänensicherheitsprüfung ruft sie standardmäßig auf, es sei denn, Sie setzen skipWebFetchPreflight: true.
  • claude.ai und platform.claude.com, die OAuth-Anmeldung und Token-Aktualisierung erfordern. Mit einem API-Schlüssel authentifizierte Läufe können diese beiden weglassen.
Unter Linux und WSL2 wendet die Runtime Schreibzugriffe nur auf Pfade an, die bereits vorhanden sind. Erstellen Sie in einer frischen Umgebung Claude Codes Konfigurationspfade vor dem ersten Start:
Sobald die Einstellungsdatei vorhanden ist, starten Sie Claude Code mit npx und übergeben Sie claude als den zu umhüllenden Befehl:
Claude Code startet in der Sandbox mit den Dateisystem- und Netzwerkgrenzen, die Sie konfiguriert haben. Der gleiche Befehl funktioniert zum Sandboxing eigenständiger MCP-Server oder anderer Hilfsprozesse.

​
Was die Runtime von selbst blockiert

Die Runtime blockiert die Schreibvorgänge mit dem höchsten Risiko ohne jede Konfiguration von Ihnen:
  • denyWrite hat Vorrang vor allowWrite.
  • Im Projektstammverzeichnis verweigert die Runtime .git/hooks, verweigert .git/config, es sei denn, Sie setzen filesystem.allowGitConfig: true, und verweigert .mcp.json, .claude/commands, .claude/agents und Shell-Startdateien.
  • Unter macOS werden diese Verweigerungen überprüft, wenn ein Schreibvorgang stattfindet, daher decken sie auch verschachtelte Dateien und während der Sitzung erstellte Repositorys ab.
  • Unter Linux und WSL2 erstellt die Runtime die Verweigerungsliste einmal beim Start. Sie deckt zuverlässig das Projektstammverzeichnis ab, führt einen Best-Effort-Shallow-Scan für verschachtelte Kopien durch, die zu diesem Zeitpunkt vorhanden sind, und deckt nichts ab, das die Sitzung später erstellt, wie git init, git clone oder Scaffolding. Der Abschnitt mandatoryDenySearchDepth der README beschreibt die genaue Semantik des Scans.
  • Wenn ~/.srt-settings.json nicht vorhanden ist und Sie --settings nicht übergeben, startet die Runtime trotzdem. Sie blockiert den Netzwerkzugriff und beschränkt Schreibvorgänge auf integrierte Runtime-Pfade wie /tmp/claude, ~/.npm/_logs und ~/.claude/debug. Nehmen Sie einen sauberen Start nicht als Beweis, dass Ihre Einstellungen geladen wurden.
  • Wenn die Einstellungsdatei vorhanden ist, aber leer, unlesbar oder ungültig ist, weigert sich die Runtime zu starten, ob es sich um ~/.srt-settings.json oder eine Datei handelt, die Sie mit --settings übergeben. Sie weigert sich auch zu starten, wenn die --settings-Datei nicht vorhanden ist.
Ihre Schreibzugriffe enthalten immer noch andere Pfade, aus denen Claude Code Konfiguration lädt, daher verweigern Sie diese mit denyWrite. Eine in einer Sandbox ausgeführte Sitzung, die diese schreiben kann, kann Hooks, Berechtigungsregeln oder MCP-Server dauerhaft hinterlegen, die beim nächsten Start von Claude Code außerhalb der Sandbox ausgeführt werden.

​
Nach unbeaufsichtigten Läufen

Überprüfen Sie die Pfade, die Sie beschreibbar hielten. Unter Linux und WSL2 überprüfen Sie auch alles, das die Sitzung erstellt hat.

​
Dev Container

Ein Dev Container führt Claude Code in einem Docker-Container aus, den VS Code oder ein kompatibler Editor verwaltet, mit Ihrem Projekt bereitgestellt. Sie können Ihren eigenen mit einem .devcontainer/-Verzeichnis in Ihrem Repository definieren. Das claude-code-Repository veröffentlicht einen Beispiel-Dev-Container mit einer Standard-Deny-iptables-Firewall als Ausgangspunkt. Kopieren Sie ihn in Ihr Repository und passen Sie die Firewall-Allowlist, das Basis-Image und die angeheftete Claude Code-Version an Ihre Umgebung an. Da die Firewall nicht genehmigten Egress blockiert, unterstützt eine Konfiguration wie diese das Ausführen von Claude Code mit --dangerously-skip-permissions für unbeaufsichtigte Arbeit.

​
Custom Container

Sie können Claude Code in einem beliebigen Docker- oder OCI-Container-Image mit Ihren eigenen Netzwerkrichtlinien, bereitgestellten Volumes und seccomp-Profilen ausführen. Dies ist der häufigste Weg für Organisationen mit bestehender Container-Infrastruktur oder CI-Runnern. Mehrere verwaltete Sandbox- und Remote-Ausführungsdienste können den Container für Sie hosten. Die gleiche Checkliste gilt wie für jeden Container, den Sie betreiben: Überprüfen Sie, was beschreibbar bereitgestellt ist, welche Anmeldedaten und Token darin erreichbar sind, und welche Netzwerk-Egress-Richtlinie erlaubt ist. Sie können die integrierte Bash-Sandbox im Container schichten, um Befehlsbeschränkungen pro Befehl zu erhalten. Unprivilegierte Container benötigen enableWeakerNestedSandbox, beschrieben in Bubblewrap startet nicht innerhalb eines Containers.

​
Virtuelle Maschine

Eine dedizierte virtuelle Maschine bietet die stärkste Trennung mit ihrem eigenen Kernel und in Cloud- oder microVM-Bereitstellungen ihrer eigenen virtualisierten Hardware. Optionen umfassen Cloud-Instanzen, lokale Hypervisoren und microVMs wie Firecracker. Verwenden Sie diesen Ansatz, wenn Sie nicht vertrauenswürdigen Code evaluieren, wenn Ihre Sicherheitsrichtlinie Kernel-Ebenen-Trennung zwischen dem Agent und dem Host erfordert, oder wenn kein Host-Ebenen-Ansatz Ihre Compliance-Anforderungen erfüllt. Docker Sandboxes bietet eine microVM mit ihrem eigenen Docker-Daemon und Workspace-Synchronisierung, die Claude Code auf jedem Host mit installiertem Docker Sandboxes ausführen kann. Es ist ein kostenloses, eigenständiges Produkt von Docker, das Docker Desktop nicht erfordert.

​
Cloud-Sitzungen

Eine Cloud-Sitzung wird in einer isolierten, von Anthropic verwalteten virtuellen Maschine ausgeführt. Ein Netzwerk-Proxy erzwingt eine Standard-Allowlist, und ein separater Proxy hält Ihren GitHub-Token außerhalb der Sandbox, während er scoped Anmeldedaten für Repository-Zugriff darin ausstellt. Sitzungen, die Ihre Organisation an eine selbstgehostete Umgebung leitet, werden stattdessen auf einer Infrastruktur ausgeführt, die Sie bereitstellen, wobei Isolation, Egress-Kontrolle und Git-Anmeldedaten die Verantwortung Ihrer Bereitstellung sind. Verwenden Sie diesen Ansatz, wenn Sie vollständige VM-Isolation ohne Bereitstellung von Infrastruktur selbst möchten, oder wenn Sie Aufgaben von einem Gerät delegieren, das keine lokale Entwicklungsumgebung hat. Es erfordert ein Claude-Abonnement. Wenn Sie nicht über die CLI starten, benötigen Sie auch ein verbundenes GitHub-Konto, damit die Sandbox Ihr Repository klonen kann. Wenn Sie über die CLI mit --cloud starten, kann Claude Code stattdessen Ihr lokales Repository bündeln und hochladen. Siehe Claude Code in der Cloud verwenden für Planverfügbarkeit und GitHub-Authentifizierungsoptionen.

​
Isolation über eine Organisation erzwingen

Einzelne Entwickler können sich für jeden der auf dieser Seite beschriebenen Sandboxing-Ansätze anmelden. Was eine Organisation erzwingen kann und mit welchen Tools hängt vom Ansatz ab:
  • Integrierte Bash-Sandbox: der einzige Ansatz, den Claude Code selbst erzwingt. Liefern Sie die sandbox-Einstellungsschlüssel durch verwaltete Einstellungen, entweder als eine Datei, die von Ihrem MDM verwaltet wird, oder durch servergesteuerte Einstellungen auf Claude.ai. Siehe Sandboxing mit verwalteten Einstellungen erzwingen für die bereitzustellenden Schlüssel und wie Sie Entwickler davon abhalten, die Richtlinie zu erweitern.
  • Dev Container: Committen Sie den Beispiel-Dev-Container in Ihre Repositories, um die Umgebung über ein Team zu standardisieren. Dies ist eher eine Konvention als eine Erzwingungsgrenze, da Claude Code keinen Container erfordert. Wenn Entwickler Claude Code nicht außerhalb davon ausführen sollten, erzwingen Sie dies mit den Gerätemanagement- oder Software-Allowlisting-Tools Ihrer Organisation.
  • Custom Container und VMs: Verteilen Sie Claude Code über das genehmigte Image und verwenden Sie die Gerätemanagement- oder Software-Allowlisting-Tools Ihrer Organisation, um die Installation außerhalb davon zu verhindern.

​
Siehe auch

Diese Seiten behandeln Konfiguration und Richtliniendetails für die oben genannten Sandboxing-Ansätze.
  • Sandboxing: Konfigurieren Sie das integrierte Sandboxed Bash tool
  • Dev Container: Der vorkonfigurierte Docker-Entwicklungs-Container
  • Sicherheit: Das vollständige Claude Code-Sicherheitsmodell
  • Sichere Bereitstellung: Isolierungsleitfaden für Agent SDK-Anwendungen
  • Einstellungen: Alle Sandbox-Konfigurationsschlüssel, einschließlich verwalteter Einstellungsbereitstellung