Das Bash-Tool in der Sandbox konfigurieren

Beschränken Sie mit der integrierten Sandbox, auf welche Dateien und Netzwerk-Hosts die Shell-Befehle von Claude Code zugreifen können. Aktivieren Sie sie, legen Sie die Grenze fest und beheben Sie, was dadurch nicht mehr funktioniert.

Die Bash-Sandbox ist eine Grenze, die das Betriebssystem um die Shell-Befehle durchsetzt, die Claude auf Ihrem Rechner ausführt. Sie legen fest, auf welche Dateien und Netzwerkdomänen diese Befehle zugreifen können, und die Beschränkungen gelten für Bash-, PowerShell- und Monitor-Befehle sowie für die Prozesse, die diese starten. Da das Betriebssystem die Beschränkungen während der Ausführung eines Befehls anwendet, kann Claude Code Befehle in der Sandbox ausführen, ohne Sie zu fragen, ob Sie jeden einzelnen genehmigen.

Die Sandbox umfasst nur Shell-Befehle. Die Datei-Tools von Claude, MCP-Server und Hooks laufen außerhalb davon.

Die Sandbox läuft unter macOS, Linux und WSL2. Unter nativem Windows führt Claude Code Befehle ohne Sandbox aus. Um die Sandbox auf einem Windows-Rechner zu verwenden, führen Sie Claude Code innerhalb einer WSL2-Distribution aus.

Was die Sandbox einschränkt

Solange die Sandbox aktiviert ist, starten die Shell-Befehle, die Claude ausführt, innerhalb ihrer Grenzen, ebenso wie die Prozesse, die diese Befehle starten. Die Sandbox ist standardmäßig deaktiviert. Um sie zu aktivieren, führen Sie /sandbox in einer Sitzung aus, wie unter Erste Schritte gezeigt, oder setzen Sie sandbox.enabled in einer Einstellungsdatei wie ~/.claude/settings.json auf true.

Die Tabelle zeigt, worauf ein in der Sandbox ausgeführter Befehl standardmäßig zugreifen kann, und welche Einstellungen den jeweiligen Standard ändern.

Zugriff	Standard	Ändern mit
Schreiben	Das Arbeitsverzeichnis, ein benutzerspezifisches temporäres Verzeichnis und von Ihnen hinzugefügte Verzeichnisse. Geschützte Pfade bleiben für Schreibzugriffe gesperrt	`filesystem.allowWrite`, `filesystem.denyWrite`
Lesen	Der Großteil des Rechners, einschließlich Dateien mit Anmeldedaten wie `~/.ssh` und `~/.aws/credentials`	`filesystem.denyRead`, `credentials`
Netzwerk	Keine direkte Verbindung nach außen. Verbindungen laufen über einen Proxy auf Ihrem Rechner, der jeden Host mit Ihren erlaubten Domains abgleicht, die zunächst leer sind. Ihr Berechtigungsmodus entscheidet, was mit anderen Hosts geschieht	`network.allowedDomains`, `network.deniedDomains`
Umgebungsvariablen	Von Claude Code übernommen, einschließlich aller Secrets in dessen Umgebung	`credentials`, `CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`

Claude Code baut die Sandbox auf dem Open-Source-Paket @anthropic-ai/sandbox-runtime auf.

Was außerhalb der Sandbox läuft

Die Sandbox umschließt Shell-Befehle. Diese Tools und Prozesse laufen außerhalb davon:

Integrierte Datei- und Web-Tools: Tools wie Read, Edit, Write, WebFetch und WebSearch folgen stattdessen Berechtigungsregeln. Ein denyRead-Eintrag hält das Read-Tool nicht auf, und allowedDomains schränkt WebFetch nicht ein
Andere Prozesse, die Claude Code startet: Befehls-Hooks, lokale MCP-Server, Plugin-Monitore, LSP-Server und Hilfsbefehle wie Ihr Statuszeilen-Befehl und apiKeyHelper laufen mit Ihrem vollen Zugriff

Einige Shell-Befehle laufen je nach Ihren Einstellungen ebenfalls außerhalb der Sandbox:

Befehle, die Sie selbst eingeben: Ein Befehl, den Sie an der !-Eingabeaufforderung im Shell-Modus eingeben, läuft in den meisten Sitzungen ohne Sandbox. Unter Strikter Sandbox-Modus sind die Sitzungen aufgeführt, in denen ein von Ihnen eingegebener Befehl in der Sandbox läuft
Ausgenommene Befehle: Befehle, die mit excludedCommands übereinstimmen, laufen ohne Sandbox
Wiederholungsversuche ohne Sandbox: Claude kann darum bitten, einen Befehl ohne Sandbox auszuführen, in der Regel nachdem er in der Sandbox fehlgeschlagen ist

Um die Tools, Prozesse und Befehle aus diesem Abschnitt hinter eine gemeinsame Grenze zu stellen, führen Sie den Claude-Code-Prozess selbst in einem Container, einer virtuellen Maschine oder der Sandbox-Runtime aus.

Erste Schritte

Die Sandbox ist in Claude Code integriert. Was Sie installieren müssen, hängt von Ihrer Plattform ab:

macOS: Das Sandboxing verwendet das integrierte Seatbelt-Framework, sodass Sie direkt mit den Schritten beginnen können
Linux und WSL2: Die Sandbox benötigt bubblewrap und socat, wie unter Linux und WSL2 einrichten beschrieben. Auch wenn Sie diese noch nicht installiert haben, können Sie mit /sandbox beginnen, da dessen Panel anzeigt, ob etwas fehlt

/sandbox ausführen

Starten Sie eine Claude Code-Sitzung und führen Sie den Befehl /sandbox aus:

/sandbox

Dadurch wird das Sandbox-Panel mit drei Tabs geöffnet, unter Linux zusätzlich mit einem Tab „Dependencies“, wenn der optionale seccomp-Filter fehlt:

Mode: Legen Sie fest, wie Befehle in der Sandbox genehmigt werden; dies wird im nächsten Schritt beschrieben
Overrides: Legen Sie fest, ob Befehle, die in der Sandbox fehlschlagen, ersatzweise außerhalb der Sandbox ausgeführt werden dürfen. Dies ist die Einstellung allowUnsandboxedCommands
Config: Zeigen Sie die aufgelösten Sandbox-Einstellungen an

Wenn das Panel nur einen Tab „Dependencies“ anzeigt, fehlt ein erforderliches Paket. Installieren Sie es wie unter Linux und WSL2 einrichten beschrieben, starten Sie Claude Code neu und führen Sie /sandbox erneut aus.

Einen Modus wählen

Wählen Sie im Tab „Mode“ entweder Auto-Allow oder reguläre Berechtigungen. Auto-Allow führt Befehle in der Sandbox ohne Nachfrage aus, während reguläre Berechtigungen die üblichen Berechtigungsabfragen beibehält, auch wenn Befehle in der Sandbox ausgeführt werden. Unter Sandbox-Modi erfahren Sie, bei welchen Befehlen im Auto-Allow-Modus dennoch nachgefragt wird.

Einen Bash-Befehl ausführen

Bitten Sie Claude, einen Befehl auszuführen, etwa einen Build oder eine Testsuite. Standardmäßig können Befehle innerhalb der Sandbox in das Arbeitsverzeichnis, ein benutzerspezifisches temporäres Verzeichnis und alle Verzeichnisse schreiben, die Sie mit --add-dir, /add-dir oder permissions.additionalDirectories hinzugefügt haben.

Wenn ein Befehl zum ersten Mal eine neue Netzwerkdomain benötigt, bittet Claude Code um Genehmigung; im Auto-Modus gibt Claude stattdessen die Hosts, die ein Befehl benötigt, direkt am Befehl an, damit der Klassifikator sie zusammen mit ihm prüft.

Wie Sie erweitern oder einschränken, was die Sandbox zulässt, erfahren Sie unter Sandboxing konfigurieren.

Wenn Befehle in der Sandbox innerhalb eines Containers mit Operation not permitted fehlschlagen, lesen Sie den Bubblewrap-Eintrag unter Fehlerbehebung.

Wenn Sie im Panel einen Modus auswählen, speichert Claude Code ihn in den lokalen Einstellungen Ihres Projekts unter .claude/settings.local.json, die für das aktuelle Projekt gelten. Claude Code fügt diese Datei Ihrer globalen gitignore hinzu, wenn es dort eine Einstellung speichert. Um die Sandbox für alle Ihre Projekte zu aktivieren, setzen Sie sandbox.enabled in Ihren Benutzereinstellungen unter ~/.claude/settings.json auf true. Um das Sandboxing für alle Entwickler einer Organisation durchzusetzen, verwenden Sie verwaltete Einstellungen.

Um die Sandbox für eine einzelne Sitzung zu ändern, ohne in eine Einstellungsdatei zu schreiben, starten Sie Claude Code mit --settings. Dieser Befehl startet beispielsweise eine Sitzung mit Sandbox, in der Claude einen blockierten Befehl nicht außerhalb der Sandbox erneut versuchen kann:

claude --settings '{"sandbox": {"enabled": true, "allowUnsandboxedCommands": false}}'

Prüfen, ob Befehle in der Sandbox ausgeführt werden

Um zu prüfen, ob die Sandbox funktioniert, bitten Sie Claude, jede Zeile der Tabelle auszuführen. Was Sie an der !-Eingabeaufforderung eingeben, wird in der Regel außerhalb der Sandbox ausgeführt, daher testet es die Sandbox nicht, wenn Sie eine Zeile selbst eingeben.

Befehl	Ergebnis innerhalb der Sandbox
`touch ~/sandbox-probe`	Schlägt unter macOS mit `Operation not permitted` fehl, unter Linux und WSL2 mit `Read-only file system`
`curl --noproxy '*' https://example.com`	Schlägt mit `Could not resolve host` fehl, da der Befehl keine Route am Sandbox-Proxy vorbei hat

Wenn Claude anbietet, einen fehlgeschlagenen Befehl außerhalb der Sandbox erneut zu versuchen, lehnen Sie den Wiederholungsversuch ab. Wenn touch erfolgreich ist und Ihr Home-Verzeichnis nicht zu den Verzeichnissen gehört, in die Befehle in der Sandbox schreiben dürfen, löschen Sie ~/sandbox-probe. Führen Sie dann /sandbox aus, um zu prüfen, ob die Sandbox aktiviert ist und ihre Abhängigkeiten installiert sind.

Linux und WSL2 einrichten

Unter Linux und WSL2 benötigt die Sandbox diese Pakete:

bubblewrap: das unprivilegierte Sandboxing-Tool, das die Dateisystemisolation durchsetzt
socat: das Relay, über das der Netzwerkverkehr durch den Sandbox-Proxy geleitet wird

Installieren Sie sie mit dem Paketmanager Ihrer Distribution:

sudo apt-get install bubblewrap socat

sudo dnf install bubblewrap socat

Wenn eine Abhängigkeit fehlt, listet der Tab „Dependencies“ in /sandbox auf, welche von ripgrep, bubblewrap, socat und dem seccomp-Filter auf Ihrer Plattform fehlen. Wenn Sie den Tab nach der Installation und einem Neustart von Claude Code nicht sehen, sind alle Abhängigkeiten vorhanden.

Ripgrep ist in der nativen Claude Code-Binärdatei enthalten. Der seccomp-Filter ist optional und ergänzt das Blockieren von Unix-Domain-Sockets. Installieren Sie ihn mit npm install -g @anthropic-ai/sandbox-runtime, falls er fehlt.

Wenn eine erforderliche Abhängigkeit fehlt, ist der Tab „Dependencies“ der einzige angezeigte Tab, bis Sie sie installieren. Wenn nur der optionale seccomp-Filter fehlt, erscheint der Tab „Dependencies“ neben den anderen Tabs. Die Abhängigkeitsprüfung läuft beim Start, starten Sie Claude Code daher nach der Installation von Paketen neu, damit /sandbox sie erkennt.

Unter Ubuntu 24.04 und neuer verhindert die standardmäßige AppArmor-Richtlinie, dass bubblewrap die User Namespaces erstellt, die es für die Isolation benötigt.

Um zu prüfen, ob Ihre Umgebung diese Einschränkung durchsetzt, auch innerhalb von WSL2, führen Sie `sysctl kernel.apparmor_restrict_unprivileged_userns` aus. Wenn der Befehl `0` zurückgibt, überspringen Sie diesen Schritt. Wenn er einen `No such file or directory`-Fehler ausgibt, existiert der Schlüssel nicht, und Sie können diesen Schritt überspringen. 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 innerhalb der Sandbox ausführt. Laden Sie AppArmor neu, um es anzuwenden:

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

Hinweise zu WSL2

Prüfen Sie Ihre WSL-Version mit wsl -l -v in PowerShell. Wenn Sie Sandboxing requires WSL2 sehen, läuft Ihre Distribution unter WSL1. Aktualisieren Sie sie auf WSL2 oder führen Sie Claude Code ohne Sandboxing aus.

Unter WSL2 übergibt WSL den Start einer Windows-Binärdatei wie cmd.exe, powershell.exe oder von allem unter /mnt/c/ über einen Unix-Socket an den Windows-Host. Ob ein Befehl in der Sandbox eine solche Datei starten kann, richtet sich daher nach den Unix-Socket-Einstellungen der Sandbox: Der optionale seccomp-Filter muss installiert sein, damit der Socket überhaupt blockiert wird. Um diese Starts zu erlauben, setzen Sie allowAllUnixSockets, wodurch jeder Unix-Socket für Befehle in der Sandbox geöffnet wird.

Sandbox-Modi

Claude Code bietet zwei Sandbox-Modi. In beiden setzt die Sandbox dieselben Dateisystem- und Netzwerkeinschränkungen durch; der Unterschied besteht nur darin, ob Befehle in der Sandbox automatisch genehmigt werden oder eine ausdrückliche Berechtigung erfordern.

Auto-Allow-Modus

Claude Code genehmigt einen Befehl automatisch und ohne Nachfrage, wenn er innerhalb der Sandbox ausgeführt wird. Ein Befehl durchläuft den regulären Berechtigungsablauf, wenn er außerhalb der Sandbox ausgeführt wird, weil er auf excludedCommands passt oder weil Claude ihn ohne Sandbox erneut versucht.

Ein Befehl in der Sandbox, der eine Verbindung zu einem Host herstellt, den Sie nicht erlaubt haben, bleibt in der Sandbox. Unter Hosts außerhalb Ihrer erlaubten Domains erfahren Sie, wer entscheidet, ob die Verbindung zustande kommt.

Auch im Auto-Allow-Modus gilt weiterhin Folgendes:

Ausdrückliche Verweigerungsregeln werden immer beachtet
rm- oder rmdir-Befehle, die auf einen kritischen Pfad zielen, durchlaufen weiterhin den regulären Berechtigungsablauf
Inhaltsbezogene Nachfrageregeln wie Bash(git push *) erzwingen weiterhin eine Nachfrage, auch für Befehle in der Sandbox
Eine einfache Bash-Nachfrageregel oder die gleichwertige Form Bash(*) wird für Befehle, die in der Sandbox ausgeführt werden, übersprungen; sie gilt weiterhin für Befehle, die auf den regulären Berechtigungsablauf zurückfallen. Im Plan-Modus wird die Regel nicht übersprungen: Sie fragt auch bei Befehlen in der Sandbox nach, einschließlich nur lesender Befehle. Vor v2.1.212 galt das Überspringen auch im Plan-Modus

Info

Der Auto-Allow-Modus funktioniert unabhängig von Ihrer Einstellung für den Berechtigungsmodus, mit drei Ausnahmen: dem Plan-Modus, einem Befehl im Auto-Modus mit befehlsspezifisch erlaubten Domains und der serverseitigen Prüfung durch den Klassifikator für Befehle in der Sandbox im Auto-Modus. Auch wenn Sie sich nicht im „accept edits“-Modus befinden, werden Bash-Befehle in der Sandbox automatisch ausgeführt, wenn Auto-Allow aktiviert ist. Das bedeutet, dass Bash-Befehle, die Dateien innerhalb der Sandbox-Grenzen ändern, ohne Nachfrage ausgeführt werden, selbst im Manual-Modus, in dem die Tools zur Dateibearbeitung nachfragen würden.

Im Plan-Modus erweitert Auto-Allow die Genehmigungen nicht; unter Plan-Modus erfahren Sie, wie Claude Code Befehle während der Planung kontrolliert. Vor v2.1.212 führte Auto-Allow Befehle in der Sandbox auch im Plan-Modus ohne Nachfrage aus.

Modus für reguläre Berechtigungen

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

Der Ausweg über den Wiederholungsversuch ohne Sandbox

Der Wiederholungsversuch ohne Sandbox ist ein Ausweg für Befehle, die innerhalb der Sandbox fehlschlagen, etwa Tools, die nicht mit ihr kompatibel sind. Wenn die Sandbox eine Netzwerkverbindung blockiert, nennt Claude Code den abgelehnten Host im Ergebnis des Befehls, sodass Claude sieht, was blockiert wurde. Claude analysiert den Fehler und versucht den Befehl möglicherweise mit dem Parameter dangerouslyDisableSandbox erneut.

Der erneut versuchte Befehl wird ohne Sandbox ausgeführt. In einer interaktiven Terminal-Sitzung hängt es von Ihrem Berechtigungsmodus ab, wer ihn genehmigt:

bypassPermissions-Modus: Der Wiederholungsversuch wird ohne Nachfrage ausgeführt
Manual-Modus und acceptEdits-Modus: Sie erhalten eine Berechtigungsabfrage mit dem Titel „Bash command (unsandboxed)“
Auto-Modus: Ein separates Klassifikator-Modell bewertet den zugrunde liegenden Befehl
dontAsk-Modus: Claude Code lehnt den Wiederholungsversuch ab
Plan-Modus: Siehe wie Claude Code Befehle während der Planung kontrolliert

Diese Regeln und Einstellungen ändern, wer den Wiederholungsversuch genehmigt:

Eine passende Erlaubnisregel: Wenn eine Erlaubnisregel wie Bash(curl *) auf den Befehl passt, genehmigt sie auch den Wiederholungsversuch, sodass der Befehl ohne Nachfrage außerhalb der Sandbox ausgeführt wird
Eine Nachfrageregel für den Parameter: Fügen Sie eine Nachfrageregel für Bash(dangerouslyDisableSandbox:true) hinzu, damit bei Bash-Wiederholungsversuchen nachgefragt wird. Sie erhalten die Nachfrage auch im Auto-Modus und im bypassPermissions-Modus, und die Regel hat Vorrang vor einer passenden Erlaubnisregel
permissions.blockReadsOutsideWorkingDirectories: Unter Aktionen, die kein Modus automatisch genehmigt erfahren Sie, bei welchen Wiederholungsversuchen nachgefragt wird, solange diese Einstellung aktiv ist

Den Wiederholungsversuch mit dem strikten Sandbox-Modus deaktivieren

Sie können den Wiederholungsversuch ohne Sandbox deaktivieren, indem Sie in Ihren Sandbox-Einstellungen "allowUnsandboxedCommands": false setzen. Bei deaktiviertem Wiederholungsversuch ignoriert Claude Code den Parameter dangerouslyDisableSandbox. Solange die Sandbox läuft, werden die Befehle, die Claude ausführt, dann in der Sandbox ausgeführt, sofern sie nicht auf einen excludedCommands-Eintrag passen. Damit Claude Code keine Befehle ohne Sandbox ausführt, wenn die Sandbox nicht starten kann, setzen Sie zusätzlich failIfUnavailable. Der Tab Overrides in /sandbox zeigt diese Einstellung als Strict sandbox mode an.

Ein false in Ihren Benutzereinstellungen, in --settings oder in verwalteten Einstellungen bleibt bestehen, auch wenn die Einstellungen eines Projekts true setzen. Ein false in Ihren Benutzereinstellungen macht die Sandbox nicht administratorpflichtig, sodass die übrigen Sandbox-Einstellungen eines Projekts weiterhin gelten. Vor v2.1.285 überschrieb ein true eines Projekts ein false in Ihren Benutzereinstellungen.

Wenn Sie oder Ihr Administrator den Wiederholungsversuch in verwalteten Einstellungen oder mit dem Flag --settings deaktivieren, wird die Sandbox administratorpflichtig. Claude Code ignoriert dann die Einstellungen in den Dateien eines Repositorys, die die Sandbox lockern, einschließlich excludedCommands-Einträgen. Unter Repository-Einstellungen bei einer administratorpflichtigen Sandbox sind sie aufgeführt.

Der strikte Sandbox-Modus gilt für die Befehle, die Claude ausführt. Befehle, die Sie selbst an der Eingabeaufforderung des !-Shell-Modus eingeben, werden außerhalb der Sandbox ausgeführt, es sei denn, die Sitzung ist eine der folgenden:

Eine Hintergrundsitzung: Der strikte Sandbox-Modus umfasst auch Befehle im Shell-Modus
Eine Linux-Sitzung, in der CLAUDE_CODE_SUBPROCESS_ENV_SCRUB gesetzt ist: Jeder Befehl wird in der Sandbox ausgeführt, einschließlich Befehlen im Shell-Modus

Vor v2.1.260 führte der strikte Sandbox-Modus Befehle im Shell-Modus in jeder Sitzung in der Sandbox aus.

Temporäre Verzeichnisse

Ein benutzerspezifisches temporäres Verzeichnis ist innerhalb der Sandbox standardmäßig beschreibbar, zusätzlich zum Arbeitsverzeichnis. Sofern Sie die Dateisystemisolation nicht deaktivieren, setzt Claude Code $TMPDIR für Befehle in der Sandbox auf dieses Verzeichnis, sodass Tools, die temporäre Dateien schreiben, ohne zusätzliche Konfiguration funktionieren.

Befehle außerhalb der Sandbox übernehmen das $TMPDIR Ihrer Shell, sofern es gesetzt ist. Solange die Dateisystemisolation aktiv ist, lösen Befehle innerhalb und außerhalb der Sandbox $TMPDIR daher in unterschiedliche Verzeichnisse auf. Wenn Ihre Shell $TMPDIR nicht setzt oder leer lässt, erhält ein Befehl außerhalb der Sandbox, der auf $TMPDIR verweist, Ihre Überschreibung CLAUDE_CODE_TMPDIR oder das temporäre Verzeichnis des Betriebssystems, wenn Sie keine festgelegt haben oder die Überschreibung ein langer Pfad ist, sodass die Variable nicht zu einer leeren Zeichenfolge expandiert wird. Um temporäre Dateien zwischen beiden auszutauschen, schreiben Sie sie stattdessen unterhalb des Arbeitsverzeichnisses.

Sandboxing konfigurieren

Passen Sie das Verhalten der Sandbox über Ihre settings.json-Datei an. Die vollständige Konfigurationsreferenz finden Sie unter Einstellungen.

Standardmäßig können in der Sandbox ausgeführte Befehle in das aktuelle Arbeitsverzeichnis, das benutzerspezifische temporäre Verzeichnis und alle Verzeichnisse schreiben, die Sie mit --add-dir, /add-dir oder permissions.additionalDirectories hinzugefügt haben. Wenn Unterprozessbefehle wie kubectl, terraform oder npm außerhalb dieser Verzeichnisse schreiben müssen, verwenden Sie sandbox.filesystem.allowWrite, um Zugriff auf bestimmte Pfade zu gewähren:

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

Diese Pfade werden auf Betriebssystemebene durchgesetzt, sodass alle in der Sandbox ausgeführten Befehle einschließlich ihrer Kindprozesse sie beachten. Dies ist der empfohlene Ansatz, wenn ein Tool Schreibzugriff auf einen bestimmten Ort benötigt, anstatt das Tool mit excludedCommands vollständig von der Sandbox auszunehmen.

Wenn Sie dasselbe Dateisystem-Array in mehreren Einstellungs-Geltungsbereichen definieren, führt Claude Code diese zusammen und kombiniert die Pfade aus jedem Geltungsbereich, anstatt das Array eines Geltungsbereichs durch das eines anderen zu ersetzen.

Wenn Sie eine Quelle mit --setting-sources in der CLI oder mit settingSources im Agent SDK ausschließen, ignoriert Claude Code beim Erstellen der Sandbox-Konfiguration deren sandbox.filesystem-Einträge, deren Edit-Berechtigungsregeln und deren Read-deny-Regeln. Erfordert Claude Code v2.1.246 oder höher.

Wenn Sie diese Dateisystemlisten während einer Sitzung bearbeiten, wendet Claude Code die Änderung auf die laufende Sitzung an, sodass der nächste in der Sandbox ausgeführte Befehl mit den neuen Pfaden läuft.

Pfadpräfixe steuern, wie Pfade aufgelöst werden:

Präfix	Bedeutung	Beispiel
`/`	Absoluter Pfad ab dem Dateisystem-Stammverzeichnis	`/tmp/build` bleibt `/tmp/build`
`~/`	Relativ zum Home-Verzeichnis	`~/.kube` wird zu `$HOME/.kube`
`./` oder kein Präfix	Relativ zum Projektstammverzeichnis bei Projekteinstellungen oder zu `~/.claude` bei Benutzereinstellungen	`./output` in `.claude/settings.json` wird zu `<project-root>/output` aufgelöst

Diese Syntax unterscheidet sich von den Berechtigungsregeln für Read und Edit, die //path für absolute und /path für projektrelative Pfade verwenden. Dateisystempfade der Sandbox folgen den üblichen Konventionen: /tmp/build ist absolut. Wie Claude Code einen abschließenden Schrägstrich oder einen Platzhalter in diesen Pfaden behandelt, erfahren Sie unter Sandbox-Pfadpräfixe.

Sie können Schreib- oder Lesezugriff auch mit sandbox.filesystem.denyWrite und sandbox.filesystem.denyRead verweigern und bestimmte Pfade innerhalb eines gesperrten Bereichs mit sandbox.filesystem.allowRead wieder freigeben. Wenn sich Leseregeln überschneiden, gilt die Regel mit dem engeren Pfad:

Beispielregeln	Ergebnis
`"denyRead": ["~/"]` mit `"allowRead": ["~/projects"]`	`~/projects` ist lesbar, und der Rest des Home-Verzeichnisses bleibt gesperrt. Die engere allow-Regel öffnet diesen Teil des gesperrten Bereichs wieder
`"allowRead": ["~/"]` mit `"denyRead": ["~/.env"]`	`~/.env` bleibt gesperrt, und der Rest des Home-Verzeichnisses ist lesbar. Die deny-Regel gilt auch innerhalb einer weiter gefassten allow-Regel, sodass eine breite allow-Regel ein Geheimnis nicht unbemerkt wieder freilegen kann
`"allowRead": ["~/"]` mit `"denyRead": ["~/**/.env"]`	Jede `.env` unterhalb des Home-Verzeichnisses bleibt gesperrt, und der Rest ist lesbar. Eine deny-Regel mit Platzhalter gilt innerhalb einer weiter gefassten allow-Regel genauso wie ein exakter Pfad

Das folgende Beispiel sperrt das Lesen aus dem gesamten Home-Verzeichnis, erlaubt aber weiterhin das Lesen aus dem aktuellen Projekt. Legen Sie es in der .claude/settings.json Ihres Projekts ab, da der relative Pfad . nur dann zum Projektstammverzeichnis aufgelöst wird, wenn sich die Konfiguration in den Projekteinstellungen befindet:

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

Würden Sie dieselbe Konfiguration in ~/.claude/settings.json ablegen, würde . stattdessen zu ~/.claude aufgelöst, und Projektdateien blieben durch die denyRead-Regel gesperrt.

Um Befehlen in der Sandbox den Lesezugriff auf Home-Verzeichnisse und eingebundene Volumes zu verweigern und die Arbeitsverzeichnisse dennoch lesbar zu halten, setzen Sie permissions.blockReadsOutsideWorkingDirectories, anstatt Pfadregeln zu schreiben.

Befehle mit `excludedCommands` außerhalb der Sandbox ausführen

Tragen Sie ein Befehlsmuster in sandbox.excludedCommands ein, um passende Befehle außerhalb der Sandbox auszuführen, also ohne Dateisystembeschränkungen und ohne Netzwerk-Proxy. Verwenden Sie dies für ein Tool, das innerhalb der Sandbox nicht funktioniert und dem Sie Ihren vollen Zugriff anvertrauen. Ein Tool, das nur ein weiteres Verzeichnis oder einen weiteren Host benötigt, funktioniert möglicherweise mit allowWrite oder allowedDomains, wodurch der Befehl in der Sandbox bleibt.

Dieses Beispiel nimmt docker compose-Befehle aus der Sandbox heraus. Speichern Sie es in ~/.claude/settings.json, um es auf alle Ihre Projekte anzuwenden:

{
  "sandbox": {
    "enabled": true,
    "excludedCommands": ["docker compose *"]
  }
}

Claude Code prüft Ihre Einträge bei jedem Bash- und Monitor-Aufruf. Ein Aufruf ist die gesamte Befehlszeile, die Claude sendet, und kann mehrere Befehle verketten. Die folgenden Regeln entscheiden, ob ein Aufruf die Sandbox verlässt:

Beenden Sie das Muster mit *: Einträge verwenden dieselbe Syntax wie eine Bash(...)-Berechtigungsregel, bei der ein Muster ohne Platzhalter eine exakte Übereinstimmung ist. docker passt nur auf docker ohne Argumente. docker * passt auf docker mit oder ohne Argumente
Jeder Befehl im Aufruf muss passen: npm ci && docker compose build bleibt in der Sandbox, sofern kein anderer Eintrag npm ci abdeckt
Claude Code gleicht den Text des Aufrufs ab: Ein Skript oder make-Target, das intern docker aufruft, passt nicht, ebenso wenig /usr/local/bin/docker
Manche Aufrufe bleiben in der Sandbox: Eine Umleitung in eine Datei, ein cd oder eine Befehlssubstitution wie $(...) hält den gesamten Aufruf in der Sandbox. Der Referenzeintrag listet weitere Aufrufe auf, die in der Sandbox bleiben
Wo Sie den Eintrag speichern, kann eine Rolle spielen: Solange die Sandbox vom Administrator vorgeschrieben ist, ignoriert Claude Code Einträge in .claude/settings.json und .claude/settings.local.json

Ein ausgenommener Befehl durchläuft den regulären Berechtigungsablauf:

Nur lesende Befehle und Befehle, die Ihre allow-Regeln abdecken, werden ohne Nachfrage ausgeführt
Im Auto-Modus prüft der Klassifikator andere ausgenommene Befehle
Im bypassPermissions-Modus wird ein ausgenommener Befehl ohne Nachfrage ausgeführt, sofern keine ask-Regel auf ihn passt

Um zu bestätigen, dass ein Eintrag passt, wechseln Sie in den Manual-Modus und bitten Claude, einen passenden Befehl auszuführen, der etwas verändert, etwa docker compose up -d. Die Berechtigungsabfrage trägt den Titel „Bash command (unsandboxed)“.

Dateisystem-Isolation deaktivieren

Setzen Sie sandbox.filesystem.disabled auf true, um die Dateisystem-Isolation zu überspringen und die Netzwerk-Isolation beizubehalten. Das folgende Beispiel schaltet die Dateisystem-Isolation aus und behält eine Allowlist von Netzwerkdomains bei:

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

Die Sandbox besteht aus zwei unabhängigen Ebenen: Die Dateisystem-Isolation steuert, welche Pfade Befehle in der Sandbox lesen und schreiben können, und die Netzwerk-Isolation steuert, welche Domains sie erreichen können. Ist die Dateisystemebene ausgeschaltet, erhalten Befehle in der Sandbox uneingeschränkten Lese- und Schreibzugriff auf das Dateisystem des Hosts, während ihr ausgehender Netzwerkverkehr auf Ihre erlaubten Domains beschränkt bleibt. Schalten Sie die Ebene aus, wenn Sie die Sandbox verwenden, um zu steuern, wohin Befehle sich verbinden, und nicht, was sie schreiben.

Die Einstellung ist standardmäßig deaktiviert und gilt auf den Plattformen, auf denen die Sandbox läuft: macOS, Linux und WSL2. Erfordert Claude Code v2.1.216 oder höher.

Welche Einstellungen sie deaktivieren können

Da das Ausschalten der Dateisystem-Isolation erweitert, was Befehle in der Sandbox tun können, berücksichtigt Claude Code filesystem.disabled nur aus diesen Einstellungsquellen:

Benutzereinstellungen, verwaltete Einstellungen und das CLI-Flag --settings können sie setzen. Projekteinstellungen in .claude/settings.json und .claude/settings.local.json können das nicht, sodass ein ausgechecktes Projekt die Dateisystem-Isolation nicht ausschalten kann.
Wenn verwaltete Einstellungen sandbox.filesystem überhaupt konfigurieren oder einen sandbox.credentials.files-Eintrag mit "mode": "deny" enthalten, können nur verwaltete Einstellungen den Schlüssel setzen. So bleiben vom Administrator bereitgestellte Dateisystembeschränkungen in Kraft; um eine solche Bereitstellung zu lockern, setzen Sie "disabled": true in den verwalteten Einstellungen.
Wenn CLAUDE_CODE_SUBPROCESS_ENV_SCRUB gesetzt ist, ignoriert Claude Code filesystem.disabled aus jeder Quelle, einschließlich der verwalteten Einstellungen, und lässt die Dateisystem-Isolation eingeschaltet.

Ob ein verwalteter credentials.files-Eintrag filesystem.disabled festlegt, also den Schlüssel auf verwaltete Einstellungen beschränkt, sodass Entwickler die Dateisystem-Isolation nicht ausschalten können, hängt vom mode des Eintrags ab und davon, was mit dem Eintrag beim Start der Sandbox geschieht:

Verwalteter Eintrag	Legt `filesystem.disabled` fest	Was die Datei schützt, wenn die Isolation aus ist
`"mode": "deny"`	Ja	Nichts: Die Lesesperre ist Teil der Dateisystemebene
`"mode": "mask"`, als Maske angewendet	Nein	Die Maskierung selbst: die Sentinel-Kopie und der Proxy unter Linux und WSL2, die eigenen Leseregeln der Sandbox unter macOS
`"mode": "mask"`, beim Einrichten auf `deny` zurückgefallen	Nein	Nichts, wie bei `deny`. Tragen Sie einen Pfad, der nicht maskiert werden kann, etwa ein Verzeichnis, als expliziten `deny`-Eintrag ein, der den Schlüssel festlegt
`"mode": "mask"`, durch die Validierung zu `deny` herabgestuft	Ja, wie ein expliziter `deny`-Eintrag	Nichts, wie bei `deny`

Ein Fallback erfolgt beim Start der Sandbox, nachdem Claude Code die Einstellungen, auf denen die Prüfung der Festlegung basiert, bereits gelesen hat. Ein zurückgefallener Eintrag legt den Schlüssel daher nie fest. Die Validierung schreibt einen ungültigen Eintrag beim Laden der Einstellungen in deny um, sodass ein herabgestufter Eintrag den Schlüssel genauso festlegt wie einer, den Sie als deny geschrieben haben.

Was sich bei ausgeschalteter Dateisystem-Isolation ändert

Das Setzen von filesystem.disabled hebt die Schutzmaßnahmen auf, die die Dateisystemebene selbst durchsetzt. Schutzmaßnahmen, die andere Ebenen durchsetzen, gelten weiterhin:

Schutzmaßnahme	Bei ausgeschalteter Dateisystem-Isolation
`filesystem.denyRead` und `deny`-Lesesperren aus `credentials.files`	Nicht durchgesetzt. Die Dateisystemebene wendet beide an
`deny`- und `mask`-Einträge in `credentials.envVars`	Durchgesetzt. Das Bereinigen von Umgebungsvariablen ist unabhängig von der Dateisystemebene
`mask`-Einträge in `credentials.files`, die als Masken angewendet werden	Durchgesetzt: Die Maskierung ist unabhängig von der Dateisystemebene. Ein Eintrag, der auf `deny` zurückgefallen ist, wird wie jeder `deny`-Eintrag nicht durchgesetzt

Zwei weitere Dinge ändern sich:

Befehle in der Sandbox übernehmen das $TMPDIR Ihrer Shell anstelle des benutzerspezifischen temporären Verzeichnisses, da jedes temporäre Verzeichnis beschreibbar ist und Claude Code Befehle nicht mehr auf das benutzerspezifische umleitet.

Unter Linux ist die Variable in der übergeordneten Shell oft nicht gesetzt. Die Hinweise des Bash-Tools weisen Claude an, temporäre Arbeitsverzeichnisse mit mktemp -d zu erstellen, anstatt sich auf $TMPDIR zu verlassen.
autoAllowBashIfSandboxed ist weiterhin standardmäßig true, sodass Befehle in der Sandbox weiterhin ohne Nachfrage ausgeführt werden. Setzen Sie den Wert auf false, um bei Befehlen in der Sandbox nachfragen zu lassen.

Anmeldedaten schützen

Die Einstellung sandbox.credentials legt Dateien mit Anmeldedaten und Umgebungsvariablen fest, die vor Befehlen in der Sandbox geschützt werden sollen. Jeder Eintrag benennt einen Dateipfad oder eine Umgebungsvariable sowie einen mode. Der eigene credentials-Block hält Regeln für Anmeldedaten zusammen und getrennt von allgemeinen Dateisystemregeln.

Bei Einträgen mit "mode": "deny" wird für Dateipfade das Lesen innerhalb der Sandbox verweigert, dieselbe Einschränkung, die filesystem.denyRead anwendet, und Umgebungsvariablen werden vor jedem Befehl in der Sandbox entfernt. Der Dateischutz ist Teil der Dateisystemebene und gilt daher nicht, wenn Sie die Dateisystem-Isolation deaktivieren; der Schutz der Umgebungsvariablen gilt weiterhin.

Das folgende Beispiel sperrt das Lesen der AWS-Anmeldedatendatei und des SSH-Verzeichnisses und entfernt GITHUB_TOKEN und NPM_TOKEN aus der Umgebung von Befehlen in der Sandbox:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Einträge für Umgebungsvariablen und Dateien akzeptieren auch "mode": "mask", beschrieben unter Anmeldedaten maskieren.

Dateipfade folgen denselben Präfixregeln wie die sandbox.filesystem.*-Einstellungen.

Claude Code führt die deny-Einträge aus jedem Einstellungs-Geltungsbereich zusammen, den die Sitzung lädt. Ein deny-Eintrag schränkt den Zugriff immer nur ein, daher kann jeder Geltungsbereich einen hinzufügen, aber kein Geltungsbereich kann einen entfernen, den ein anderer hinzugefügt hat.

Wenn Sie eine Einstellungsquelle ausschließen:

Projekt- oder lokale Einstellungen: Claude Code wendet keinen ihrer credentials-Einträge an. Erfordert Claude Code v2.1.246 oder höher.
Benutzereinstellungen: Claude Code wendet die deny-Einträge in ~/.claude/settings.json weiterhin an und behält deren mask-Einträge für Dateien als Einschränkungen bei, verwirft aber deren mask-Einträge für Umgebungsvariablen.

Es gibt keine integrierte Denylist für Anmeldedaten, daher sind nur die Dateien und Variablen eingeschränkt, die Sie auflisten.

sandbox.credentials wirkt sich nur auf Bash-Befehle in der Sandbox aus. Um Anmeldedaten unabhängig vom Sandboxing aus allen Unterprozessen zu entfernen, setzen Sie CLAUDE_CODE_SUBPROCESS_ENV_SCRUB.

Anmeldedaten maskieren

Die Maskierung geht weiter als ein deny-Eintrag unter Anmeldedaten schützen. Anstatt Anmeldedaten zu sperren, zeigt Claude Code Befehlen in der Sandbox einen Platzhalter, den Sentinel, und der Sandbox-Proxy setzt bei ausgehenden Anfragen an von Ihnen erlaubte Hosts den echten Wert ein. Bei Dateien ist die Ersetzung ein Verhalten unter Linux und WSL2; macOS sperrt die Datei stattdessen.

Umgebungsvariablen maskieren

"mode": "mask" schützt Anmeldedaten und sorgt dafür, dass die Tools, die sich damit authentifizieren, weiterhin funktionieren. deny entfernt die Variable vollständig, wodurch auch Tools nicht mehr funktionieren, die sie benötigen, etwa gh oder npm. Erfordert Claude Code v2.1.199 oder höher.

Mit mask sieht der Befehl in der Sandbox einen sitzungsspezifischen Sentinel-Wert anstelle des echten Werts. Jeder mask-Eintrag kann injectHosts auflisten, die Hosts, die der echte Wert erreichen darf. Wenn eine Anfrage die Sandbox in Richtung eines dieser Hosts verlässt, ersetzt der Sandbox-Proxy den Sentinel durch den echten Wert. Der Befehl und alles, was er protokolliert, enthalten nie die echten Anmeldedaten, aber seine Anfragen werden dennoch authentifiziert.

Der Proxy ersetzt die Anmeldedaten innerhalb des Anfrageinhalts und muss diesen daher sehen können. Setzen Sie network.tlsTerminate, damit der Proxy TLS selbst terminiert.

Ohne diese Einstellung schlägt die Maskierung fehl, ohne etwas preiszugeben: Der Befehl sieht weiterhin nur den Sentinel, aber der Sentinel erreicht den Server unverändert, und die Authentifizierung schlägt fehl. Claude Code meldet diese Fehlkonfiguration beim Start.

Die Ersetzung umfasst Header und Anfrage-Bodys. Anfragen, die sich mit einer aus den Anmeldedaten abgeleiteten Signatur statt mit den Anmeldedaten selbst authentifizieren, müssen am Proxy neu signiert werden; AWS-Anfragen neu signieren beschreibt, wie das bei AWS funktioniert.

Der Proxy fügt Anmeldedaten nur bei Verbindungen ein, die die Domain-Allowlist zulässt. Jedes injectHosts-Ziel muss daher auch über network.allowedDomains erreichbar sein.

Das folgende Beispiel maskiert zwei Token. GH_TOKEN wird nur bei Anfragen an api.github.com ersetzt, während NPM_TOKEN keine injectHosts hat und bei Anfragen an jeden Host in network.allowedDomains ersetzt wird.

{
  "sandbox": {
    "enabled": true,
    "network": {
      "tlsTerminate": {},
      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
    },
    "credentials": {
      "envVars": [
        { "name": "GH_TOKEN", "mode": "mask", "injectHosts": ["api.github.com"] },
        { "name": "NPM_TOKEN", "mode": "mask" }
      ]
    }
  }
}

Schreiben Sie ein IPv6-Ziel in den beiden Listen unterschiedlich, da jede Liste ihren eigenen Matcher hat:

network.allowedDomains: die in Domainlisten verwendete Form mit eckigen Klammern, etwa "[::1]". Der Proxy prüft diese Liste, um die Verbindung zuzulassen.
injectHosts: die reine Adresse in ihrer kanonischen komprimierten Form, etwa "::1" oder "2001:db8::1". Der Proxy gleicht jeden Eintrag mit der reinen Zieladresse der Verbindung ab und ignoriert dabei Ports. Eine Schreibweise mit eckigen Klammern, Zonen-ID oder anderer Komprimierung passt daher nie, und der Proxy fügt die Anmeldedaten dort nie ein.

claude doctor kennzeichnet injectHosts-Einträge, die nie passen können, mit der Warnung Sandbox credential injectHosts entries can never match their destination. Diese Prüfung erfordert Claude Code v2.1.229 oder höher.

Anders als deny autorisiert die Maskierung den Proxy, Ihre echten Anmeldedaten an die aufgelisteten Hosts zu senden. Claude Code berücksichtigt sie daher nur aus Einstellungen, die Sie oder Ihr Administrator kontrollieren: Benutzereinstellungen, verwaltete Einstellungen und das CLI-Flag --settings. Claude Code ignoriert mask-Einträge in der .claude/settings.json oder .claude/settings.local.json eines Repositorys. In diesen Dateien ignoriert es auch network.tlsTerminate und credentials.allowPlaintextInject, die Einstellung, mit der der Proxy Anmeldedaten in unverschlüsselte Anfragen einfügen darf. Wenn Sie Benutzereinstellungen ausschließen, verwirft Claude Code auch die mask-Einträge für Umgebungsvariablen in ~/.claude/settings.json.

Wenn Ihr Administrator mask-Einträge, network.tlsTerminate oder credentials.allowPlaintextInject über serververwaltete Einstellungen bereitstellt, zählen diese zu den Einstellungen, die eine Genehmigung erfordern.

Wenn dieselbe Variable in einem beliebigen Geltungsbereich mit deny aufgeführt ist, hat deny Vorrang.

Die Maskierung ersetzt standardmäßig den gesamten Wert der Variable, was für ein einfaches Token geeignet ist. Optionale Eintragsfelder, die Claude Code v2.1.224 oder höher erfordern, verarbeiten strukturierte Werte:

extract: ein regulärer Ausdruck, den Claude Code auf den gesamten Wert anwendet, wobei nur der von Gruppe 1 jeder Übereinstimmung erfasste Text ersetzt wird. So funktioniert ein Tool, das den Wert parst, etwa bei einem DATABASE_URL-Verbindungsstring, auch innerhalb der Sandbox weiter. Das Muster muss mindestens eine Erfassungsgruppe enthalten.
onExtractNoMatch steuert, was passiert, wenn das Muster auf nichts passt:
- warn, der Standard, gibt eine Warnung aus und reicht die Variable unmaskiert durch
- deny entfernt die Variable innerhalb der Sandbox
- error stoppt die Einrichtung der Sandbox, bis Sie die Konfiguration korrigieren
decode: "jwt": für eine Variable, die ein JSON Web Token (JWT) enthält. Claude Code prüft, ob der Wert ein JWT ist, und ersetzt ihn durch ein strukturell gültiges gefälschtes Token, sodass Code innerhalb der Sandbox, der das Token dekodiert, weiterhin funktioniert. Fügen Sie maskClaims hinzu, um Claims der obersten Ebene der Payload aufzulisten, die einzeln maskiert werden sollen, anstatt das gesamte Token zu ersetzen; die übrigen Claims bleiben lesbar. Wenn sich der Wert nicht als JWT verifizieren lässt oder kein aufgeführter Claim passt, reicht Claude Code die Variable mit einer Warnung unmaskiert durch. decode kann nicht mit extract kombiniert werden.

Die vollständige Feldliste finden Sie in den Zeilen zu credentials.envVars[] in der Einstellungsreferenz.

AWS-Anfragen neu signieren

AWS-Anfragen tragen SigV4-Signaturen über den Anfrageinhalt. Maskieren Sie daher AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY gemeinsam. Der Proxy erkennt eine SigV4-Anfrage am Sentinel des Zugriffsschlüssels und signiert sie neu, nachdem er die echten Werte eingesetzt hat. Wird nur der geheime Schlüssel maskiert, bleiben Anfragen mit dem Platzhalter signiert, den der Proxy nicht erkennen kann, sodass sie bei AWS fehlschlagen; Claude Code warnt in diesem Fall beim Start, jedoch nicht, wenn nur die Zugriffsschlüssel-ID maskiert ist. Eine erkannte Anfrage, die der Proxy nicht neu signieren kann, etwa eine ohne x-amz-date-Header, schlägt mit einem Proxy-Fehler fehl, anstatt den Server mit einer fehlerhaften Signatur zu erreichen.

Claude Code verknüpft die üblichen Variablen AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und AWS_SESSION_TOKEN automatisch zu einem Satz Anmeldedaten, wenn Sie deren gesamte Werte maskieren. Wenn Ihre AWS-Anmeldedaten in Variablen mit anderen Namen liegen, gruppieren Sie diese selbst mit credentials.awsPairs, was Claude Code v2.1.224 oder höher erfordert. Dieses Beispiel fügt die Zuordnung einer Konfiguration hinzu, die MY_KEY_ID, MY_SECRET_KEY und MY_SESSION_TOKEN bereits vollständig maskiert, wie in der obigen Maskierungskonfiguration:

{
  "sandbox": {
    "credentials": {
      "awsPairs": [
        {
          "accessKeyIdVar": "MY_KEY_ID",
          "secretAccessKeyVar": "MY_SECRET_KEY",
          "sessionTokenVar": "MY_SESSION_TOKEN"
        }
      ]
    }
  }
}

Jeder Eintrag folgt diesen Regeln:

accessKeyIdVar und secretAccessKeyVar benennen die maskierten envVars-Einträge, die die Zugriffsschlüssel-ID und den geheimen Schlüssel enthalten. Das optionale sessionTokenVar benennt den Eintrag mit dem Sitzungstoken für temporäre Anmeldedaten; wenn es gesetzt ist, sendet der Proxy bei neu signierten Anfragen das echte Token als x-amz-security-token.
Jede benannte Variable muss ein mask-Eintrag sein, der ihren gesamten Wert maskiert, ohne extract oder decode.
Der Proxy signiert Anfragen an die Hosts neu, die in den injectHosts des Eintrags für die Zugriffsschlüssel-ID aufgeführt sind.
Wird eine der üblichen Variablen in einem Paar benannt, ersetzt dies die automatische Zuordnung.

Wie mask-Einträge wird awsPairs nur aus Benutzereinstellungen, verwalteten Einstellungen und dem CLI-Flag --settings berücksichtigt.

Drei Formen von AWS-Anfragen tragen Signaturen, die der Proxy nicht neu berechnen kann. Wenn eine solche Anfrage mit dem Platzhalter eines maskierten Paars signiert ist, lässt der Proxy sie fehlschlagen, anstatt eine fehlerhafte Signatur weiterzuleiten; Anfragen, die mit unmaskierten Anmeldedaten signiert sind, sind nie betroffen. Die Einstellung credentials.sigv4, die Claude Code v2.1.224 oder höher erfordert, lockert dies je Form: Wird der Schlüssel einer Form auf passthrough gesetzt, wird die Anfrage mit ihrer vom Platzhalter abgeleiteten Signatur weitergeleitet, sodass das aufrufende Tool die Ablehnungsantwort von AWS selbst statt eines Proxy-Fehlers erhält. Wie awsPairs wird sigv4 nur aus Benutzereinstellungen, verwalteten Einstellungen und dem CLI-Flag --settings berücksichtigt.

Anfrageform	`sigv4`-Schlüssel	Warum der Proxy sie nicht neu signieren kann
aws-chunked-Streaming-Uploads	`streaming`	Die Signaturen pro Chunk bauen auf der Ausgangssignatur auf, sodass ein Neusignieren das Umschreiben des Bodys erfordern würde
Vorsignierte URLs	`presigned`	Die Signatur befindet sich in der URL selbst, ohne `Authorization`-Header
Asymmetrische SigV4A-Signaturen	`sigv4a`	Es gibt keinen HMAC mit gemeinsamem Schlüssel, der neu berechnet werden könnte

Dateien mit Anmeldedaten maskieren

Dateieinträge akzeptieren ebenfalls "mode": "mask", was Claude Code v2.1.221 oder höher erfordert. Was ein Befehl in der Sandbox sieht, hängt von der Plattform ab:

Linux und WSL2: Befehle in der Sandbox lesen eine Sentinel-Kopie der Datei, einen Ersatz, dessen Geheimnis durch einen Platzhalterwert ersetzt ist, und der Sandbox-Proxy setzt beim ausgehenden Verkehr den echten Wert ein.
macOS: Befehle in der Sandbox können die aufgeführte Datei überhaupt nicht lesen. Claude Code erstellt keine Sentinel-Kopie und ersetzt beim ausgehenden Verkehr nichts, sodass Tools, die sich mit der Datei authentifizieren, innerhalb der Sandbox nicht funktionieren, mit derselben Wirkung wie deny. Anders als bei einem deny-Eintrag bleibt die Lesesperre auch dann bestehen, wenn Sie die Dateisystem-Isolation deaktivieren.

Auf jeder Plattform wendet Claude Code die Anforderung network.tlsTerminate und injectHosts genauso an wie bei maskierten Umgebungsvariablen und ignoriert Repository-Einstellungen auf dieselbe Weise. Wenn Sie Benutzereinstellungen ausschließen, behält Claude Code die mask-Einträge für Dateien in ~/.claude/settings.json als Einschränkungen bei, aber die Einträge autorisieren den Proxy nicht mehr, den echten Wert einzusetzen.

Das folgende Beispiel maskiert ein GitHub-Token, das in ~/.config/gh/hosts.yml gespeichert ist; das weiter unten beschriebene extract-Muster teilt Claude Code mit, welcher Teil der Datei das Geheimnis ist. Unter Linux und WSL2 erhalten Befehle in der Sandbox, die die Datei lesen, einen Sentinel anstelle des Tokens, und der Proxy setzt bei Anfragen an api.github.com das echte Token ein:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "tlsTerminate": {},
      "allowedDomains": ["*.github.com"]
    },
    "credentials": {
      "files": [
        {
          "path": "~/.config/gh/hosts.yml",
          "mode": "mask",
          "extract": "oauth_token:\\s*(\\S+)",
          "injectHosts": ["api.github.com"]
        }
      ]
    }
  }
}

Um zu bestätigen, dass die Maske aktiv ist, bitten Sie Claude, cat ~/.config/gh/hosts.yml in einem Befehl in der Sandbox auszuführen: Unter Linux und WSL2 zeigt die Ausgabe einen Sentinel-Wert anstelle des Tokens, und unter macOS schlägt das Lesen stattdessen fehl.

Unter Linux und WSL2 sorgt das extract-Muster dafür, dass der Rest von hosts.yml lesbar bleibt. Claude Code wendet den regulären Ausdruck auf die gesamte Datei an und ersetzt nur den von Gruppe 1 jeder Übereinstimmung erfassten Text, sodass gh seine Konfiguration weiterhin parst und nur das Token ein Platzhalter ist. Verwenden Sie extract für jede strukturierte Datei, die Tools parsen, etwa .netrc, JSON oder YAML; das Muster muss mindestens eine Erfassungsgruppe enthalten. Ohne extract ersetzt Claude Code den gesamten Dateiinhalt durch einen einzigen Sentinel-Wert, was für eine Datei geeignet ist, die nur ein einzelnes Geheimnis und sonst nichts enthält.

Für eine Datei, die ein JSON Web Token (JWT) enthält, setzen Sie decode: "jwt" anstelle von oder zusammen mit extract. decode erfordert Claude Code v2.1.224 oder höher. Claude Code findet JWT-Kandidaten mit einem integrierten Muster oder, falls gesetzt, mit Ihrem extract-Muster, prüft, ob jeder Kandidat ein JWT ist, und ersetzt ihn durch ein strukturell gültiges gefälschtes Token, sodass Code, der das Token innerhalb der Sandbox dekodiert, weiterhin funktioniert. Fügen Sie maskClaims hinzu, um nur die benannten Claims der obersten Ebene der Payload innerhalb jedes verifizierten Tokens zu maskieren und die übrigen Claims lesbar zu lassen. Wenn sich kein Kandidat verifizieren lässt oder kein benannter Claim passt, bestimmt das unten beschriebene Feld onExtractNoMatch das Ergebnis, genauso wie bei einem Muster, das auf nichts passt.

Zwei optionale Felder verfeinern das Abgleichverhalten. Beide gelten nur, wenn mode auf mask steht und extract oder decode gesetzt ist. Unter macOS wendet Claude Code mask-Einträge bei eingeschalteter Dateisystem-Isolation als deny an, bevor das Muster ausgeführt wird. Diese Felder und die unten beschriebenen Ergebnisse bei fehlender Übereinstimmung wirken dort daher nur, wenn die Dateisystem-Isolation ausgeschaltet ist:

onExtractNoMatch steuert, was passiert, wenn der Abgleich in der Datei nichts zum Maskieren findet:
- warn, der Standard, gibt eine Warnung aus und überspringt den Eintrag, sodass Befehle in der Sandbox die echte Datei unmaskiert lesen können. Der Standard eignet sich für Anmeldedaten, die berechtigterweise fehlen können; wenn das Geheimnis vorhanden sein könnte, das Muster es aber möglicherweise verfehlt, verwenden Sie deny
- deny macht die Datei stattdessen unlesbar
- error stoppt die Einrichtung der Sandbox, bis Sie die Konfiguration korrigieren
Claude Code behandelt deny als error, wann immer die Lesesperre nicht durchgesetzt würde: wenn Sie die Dateisystem-Isolation deaktivieren und wenn ein filesystem.allowRead-Eintrag den Pfad der Datei wieder freigibt.
maskDuplicates ersetzt zusätzlich wörtliche Kopien jedes maskierten Anmeldedatenwerts, also einer extract-Erfassung oder eines durch decode verifizierten Tokens, die außerhalb der abgeglichenen Bereiche gefunden werden, für ein Geheimnis, das an Stellen wiederholt wird, die der Abgleich nicht erreicht. Es gleicht rohe Teilstrings ab, sodass ein kurzer oder häufiger Wert überall ersetzt würde, wo er vorkommt; verwenden Sie es daher nur für lange Geheimnisse mit hoher Entropie. Standard: false.

mask gilt für eine einzelne Datei, listen Sie daher jede Datei mit Anmeldedaten einzeln auf. Claude Code fällt bei einem mask-Eintrag, den es nicht sicher maskieren kann, auf deny zurück: bei einem Verzeichnispfad, einem Glob-Muster, einer Datei größer als 8 MiB oder einer Datei, die kein UTF-8-Text ist. Tragen Sie Verzeichnisse stattdessen als explizite deny-Einträge ein; die Tabelle unter Welche Einstellungen sie deaktivieren können beschreibt, ob jede Form filesystem.disabled festlegt und wie sie sich bei ausgeschalteter Dateisystem-Isolation verhält.

Wie Sandboxing funktioniert

Dateisystemisolation

Das in einer Sandbox ausgeführte Bash-Tool beschränkt den Dateisystemzugriff auf bestimmte Verzeichnisse:

Standardverhalten beim Schreiben: Lese- und Schreibzugriff auf das aktuelle Arbeitsverzeichnis und seine Unterverzeichnisse, auf alle Verzeichnisse, die Sie mit --add-dir, /add-dir oder permissions.additionalDirectories hinzugefügt haben, sowie auf das benutzerspezifische temporäre Verzeichnis, auf das $TMPDIR verweist
Standardverhalten beim Lesen: Lesezugriff auf den gesamten Computer, mit Ausnahme bestimmter gesperrter Verzeichnisse. Diese Standardeinstellung erlaubt weiterhin das Lesen von Dateien mit Anmeldedaten, daher sollten Sie Anmeldedaten schützen, die Befehle nicht lesen sollen.
Lesesperre: Wenn permissions.blockReadsOutsideWorkingDirectories aktiviert ist, verlieren in der Sandbox ausgeführte Befehle außerdem den Lesezugriff auf Ihr Home-Verzeichnis und die anderen Verzeichnisse, die Benutzerdateien enthalten, mit Ausnahme der Pfade, die unter Befehle in der Sandbox unter der Sperre aufgeführt sind. Dieser Abschnitt beschreibt auch, wann dieser Teil der Sperre nicht gilt.
Git-Worktrees: Wenn das Arbeitsverzeichnis ein verknüpfter Git-Worktree ist, erlaubt die Sandbox auch Schreibvorgänge im gemeinsamen .git-Verzeichnis des Haupt-Repositorys, damit Befehle wie git commit Refs und den Index aktualisieren können. Schreibvorgänge in hooks/ und config innerhalb dieses Verzeichnisses bleiben gesperrt.

Um die Dateisystemisolation vollständig zu überspringen und gleichzeitig die Netzwerkisolation beizubehalten, setzen Sie sandbox.filesystem.disabled.

Geschützte Pfade

Innerhalb der Verzeichnisse, in die in der Sandbox ausgeführte Befehle schreiben dürfen, verweigert die Sandbox weiterhin Schreibvorgänge in die Dateien, aus denen Claude Code Konfiguration und Code lädt. Ein Befehl, der diese Dateien bearbeiten könnte, könnte sich selbst Berechtigungen erteilen oder einen Hook oder MCP-Server hinzufügen, den Claude Code außerhalb der Sandbox ausführt. Das Berechtigungssystem hat eigene geschützte Pfade, die steuern, was Claude Code genehmigt, bevor ein Tool ausgeführt wird; die Liste der Sandbox gilt für einen Befehl, der bereits läuft. Sie umfasst vier Gruppen von Pfaden:

In Ihrem Arbeitsverzeichnis und den darüberliegenden Verzeichnissen: die .claude-Einstellungsdateien, die Verzeichnisse .claude/skills, .claude/agents, .claude/commands und .claude/hooks, .mcp.json sowie die Dateien, die Claude Code selbstständig ausführt, etwa .claude/workflows und .claude/scheduled_tasks.json
Nur in Ihrem Arbeitsverzeichnis: Shell-Startdateien wie .bashrc und .zshrc, .gitconfig, die Verzeichnisse .vscode und .idea sowie hooks und config innerhalb von .git
Dateien, die Ihr Arbeitsverzeichnis in ein Bare-Git-Repository verwandeln würden: HEAD, objects und refs auf oberster Ebene sowie dort vorhandene config- und hooks-Einträge, wenn daneben ein HEAD liegt. Eine Datei namens config wird auch ohne HEAD gesperrt. Unter Linux und WSL2 löscht die Sandbox eine HEAD-Datei bzw. ein objects- oder refs-Verzeichnis auf oberster Ebene, das erscheint, während ein Befehl in der Sandbox läuft
In ~/.claude oder dem Verzeichnis, auf das CLAUDE_CONFIG_DIR verweist: der Großteil des Inhalts sowie ~/.claude.json und der Anmeldedatenspeicher .credentials.json

Wenn während der Sitzung ein Symlink am Pfad einer geschützten Einstellungsdatei erscheint, verweigert die Sandbox ab dem nächsten Befehl auch Schreibvorgänge in die Datei, auf die er verweist.

Es gibt keine Möglichkeit, einen dieser Pfade auszunehmen: Ein allowWrite-Eintrag oder eine Edit-allow-Regel, die den Pfad abdeckt, hebt den Schutz nicht auf. Die einzige Möglichkeit, den Schutz auszuschalten, ist filesystem.disabled, wodurch die Dateisystemisolation für alle Pfade ausgeschaltet wird. Um die meisten dieser Pfade für Ihren Rechner aufgelöst zu sehen, führen Sie /sandbox aus und öffnen Sie den Tab Config, der sie unter Denied within allowed zusammen mit Ihren eigenen denyWrite-Einträgen auflistet.

Wenn git merge oder git checkout bei einem dieser Pfade mit unable to unlink old fehlschlägt, lesen Sie Fehlerbehebung.

Netzwerkisolation

Ein in der Sandbox ausgeführter Befehl hat keinen direkten Zugang zum Netzwerk:

Linux und WSL2: Der Befehl läuft in einem separaten Netzwerk-Namespace, der keine Verbindung zu Ihrem Netzwerk hat
macOS: Das Sandbox-Framework Seatbelt blockiert standardmäßig alle Verbindungen außer der zum Sandbox-Proxy

Claude Code betreibt den Sandbox-Proxy auf Ihrem Rechner außerhalb der Sandbox und leitet Befehle mit HTTP_PROXY, HTTPS_PROXY, ALL_PROXY und verwandten Umgebungsvariablen zu ihm. Der Proxy prüft den Hostnamen jeder Verbindung anhand Ihrer erlaubten und gesperrten Domains.

Was ein Tool erreichen kann, hängt davon ab, ob es den Proxy verwendet:

Tools, die die Proxy-Variablen lesen: curl, npm, git über HTTPS und ähnliche Tools verbinden sich, sobald ihr Host erlaubt ist. Ein allowedDomains-Eintrag ohne Port erlaubt jeden Port auf diesem Host
Tools, die die Proxy-Variablen ignorieren: einfaches ssh, die meisten Datenbanktreiber und ähnliche Tools können sich nicht verbinden, selbst zu einem erlaubten Host. Siehe Ein Datenbank-Client oder ein anderes Nicht-HTTP-Tool erreicht einen erlaubten Host nicht
Alles, was nicht TCP ist: UDP, HTTP/3 über QUIC und ICMP-Tools wie ping können die Sandbox nicht verlassen

Die folgenden Einstellungen und Verhaltensweisen steuern, welche Hosts der Proxy erlaubt:

Domain-Beschränkungen: Ihre erlaubten Domains sind anfangs leer. Hosts außerhalb Ihrer erlaubten Domains beschreibt, was passiert, wenn ein Befehl zum ersten Mal eine neue Domain benötigt.
Genehmigungsoptionen: Wenn Sie bei der Abfrage Yes wählen, erlaubt Claude Code den Host für den Rest der aktuellen Sitzung. Wenn Sie „Yes, and don't ask again" wählen, speichert Claude Code eine WebFetch(domain:...)-allow-Regel in Ihren lokalen Einstellungen, sodass der Host auch in zukünftigen Sitzungen erlaubt bleibt. Solange die Sandbox vom Administrator vorgeschrieben ist, speichert Claude Code die Regel in Ihren Benutzereinstellungen, wo sie in jedem Projekt gilt.
Vorab erlaubte Domains: Erlauben Sie Domains vorab mit allowedDomains, um die Abfrage ganz zu vermeiden. Claude Code erlaubt außerdem vorab Domains aus WebFetch(domain:...)-allow-Regeln, wie unter Berechtigungsregeln beschrieben.
Strikte Allowlist: Wenn Sie strictAllowlist in Benutzer-, verwalteten oder CLI---settings-Einstellungen auf true setzen, verweigert Claude Code Befehlen in der Sandbox den Zugriff auf jeden Host außerhalb der Allowlist, statt nachzufragen. Die Allowlist besteht aus allowedDomains plus Domains aus WebFetch(domain:...)-allow-Regeln oder nur aus den Einträgen der verwalteten Einstellungen, wenn allowManagedDomainsOnly gesetzt ist. Sperren, die ohne vom Administrator vorgeschriebene Sandbox gelten behandelt die Einträge eines Repositorys. Claude Code erzwingt dies nur für Befehle in der Sandbox; prozessinterne Tools wie WebFetch folgen weiterhin ihren Berechtigungsregeln. Das Setzen in .claude/settings.json oder .claude/settings.local.json eines Repositorys hat keine Wirkung. Erfordert Claude Code v2.1.219 oder höher.
Verwaltete Sperre: Wenn allowManagedDomainsOnly in verwalteten Einstellungen gesetzt ist, werden nicht erlaubte Domains automatisch blockiert, statt nachzufragen, und nur allowedDomains und WebFetch(domain:...)-allow-Regeln aus verwalteten Einstellungen werden berücksichtigt.
Unternehmens-Proxy: Wenn Ihr Netzwerk verlangt, dass ausgehender Datenverkehr über einen Unternehmens-Proxy läuft, setzen Sie HTTPS_PROXY, HTTP_PROXY und NO_PROXY wie unter Proxy-Konfiguration beschrieben, und zwar im env-Block Ihrer Einstellungen, damit auch Hintergrund-Agenten sie erhalten, oder in der Umgebung, aus der Sie Claude Code starten. Claude Code erzwingt die Domain-Allowlist und tunnelt erlaubte Verbindungen dann über diesen vorgelagerten Proxy. http://- und https://-Proxy-URLs funktionieren, bei Bedarf mit Basic-Authentifizierung in der URL.

In einer WebFetch(domain:...)-Regel berücksichtigt die Sandbox zwei Platzhalterformen: ein führendes *., etwa *.example.com, und ein alleinstehendes *. Die Form mit alleinstehendem * erfordert Claude Code v2.1.186 oder höher. Ein Platzhalter an jeder anderen Position, etwa WebFetch(domain:example.*), passt weiterhin auf Abrufe, hat aber keine Wirkung auf Befehle in der Sandbox.

Hosts außerhalb Ihrer erlaubten Domains

Wenn sich ein Befehl in der Sandbox mit einem Host verbindet, der nicht zu Ihren erlaubten Domains gehört, bleibt der Befehl in der Sandbox und wartet auf eine Entscheidung. In einer interaktiven Terminal-Sitzung hängt die Entscheidung von Ihrem Berechtigungsmodus ab:

Berechtigungsmodus	Was mit der Verbindung passiert
`bypassPermissions`-Modus sowie Plan-Modus mit verfügbarem Umgehen von Berechtigungen	Ohne Abfrage erlaubt
Manueller Modus, `acceptEdits`-Modus und Plan-Modus in anderen Fällen	Sie erhalten eine Abfrage
Auto-Modus	Abgelehnt, sofern der Befehl den Host nicht aufgeführt hat und der Klassifikator die Liste genehmigt hat
`dontAsk`-Modus	Abgelehnt

Wenn strictAllowlist oder allowManagedDomainsOnly aktiviert ist, lehnt der integrierte Sandbox-Proxy die Verbindung in jedem Berechtigungsmodus ab. Im bypassPermissions-Modus sind Hosts außerhalb Ihrer erlaubten Domains erlaubt, sofern keine dieser Einstellungen aktiviert ist. Der Notausgang des Wiederholungsversuchs außerhalb der Sandbox beschreibt, wann ein Befehl die Sandbox in diesem Modus verlassen kann. Eine Verbindung zu einem Host in deniedDomains wird ebenfalls in jedem Berechtigungsmodus abgelehnt.

Hostnamen, die zu lokalen Adressen aufgelöst werden

Nachdem ein Hostname die Allowlist passiert hat, löst der Sandbox-Proxy ihn auf und lehnt die Verbindung ab, wenn der Name ausschließlich zu lokalen Adressen aufgelöst wird. Zu den lokalen Adressen gehören Loopback-Adressen wie 127.0.0.1, Link-Local-Adressen wie der Cloud-Metadaten-Endpunkt 169.254.169.254 sowie Adressen, die Ihrem eigenen Rechner zugewiesen sind. Die Namen localhost und *.localhost dürfen zu Loopback aufgelöst werden.

Ein erlaubter Intranet-Hostname, der zu einem privaten Bereich wie 10.0.0.0/8 aufgelöst wird, verbindet sich. Damit ein Name zu einer abgelehnten Adresse aufgelöst werden darf, fügen Sie diese IP-Adresse zu allowedDomains hinzu, etwa "127.0.0.1:8080".

Die Prüfung gilt für Hostnamen. Über eine Verbindung zu einer IP-Adresse entscheiden Ihre erlaubten Domains und Ihr Berechtigungsmodus. Der Proxy überspringt die Prüfung außerdem bei Verbindungen, die er über einen vorgelagerten Unternehmens-Proxy sendet, da dieser Proxy den Namen auflöst.

Erlaubte Domains pro Befehl im Auto-Modus

Im Auto-Modus mit aktiviertem Sandboxing benennt Claude die Hosts, die ein Befehl benötigt, direkt am Befehl, statt für jede Verbindung eine Netzwerkgenehmigung auszulösen. Jeder Bash-, PowerShell- oder Monitor-Befehl, der in der Sandbox läuft, kann eine Liste von Hosts über die Allowlist der Sandbox hinaus mitführen: eine Domain wie registry.npmjs.org, einen Platzhalter wie *.pythonhosted.org oder eine IP-Adresse, jeweils mit optionalem :port. Der Klassifikator prüft die Hosts zusammen mit dem Befehl. Erfordert Claude Code v2.1.271 oder höher.

Eine genehmigte Liste öffnet diese Hosts nur für diesen einen Befehl, solange er läuft. Weder den erlaubten Hosts Ihrer Sitzung noch Ihren Einstellungen wird etwas hinzugefügt; der nächste Befehl benennt seine eigenen Hosts.

Ein Befehl, der Hosts mitführt, geht an den Klassifikator, statt durch eine Berechtigungsregel oder den Auto-Allow-Modus der Sandbox genehmigt zu werden. Wenn eine ask-Regel eine Abfrage für den Befehl erzwingt, listet der Berechtigungsdialog in Ihrem Terminal die Hosts daneben auf, und eine Genehmigung dort deckt beides ab.

Eine Liste pro Befehl erweitert nur das, was die Sandbox standardmäßig verweigert. Einträge in deniedDomains blockieren weiterhin. Wenn strictAllowlist oder allowManagedDomainsOnly die Allowlist sperrt, lehnt Claude Code Listen pro Befehl ab.

Solange Listen pro Befehl gelten, lehnt Claude Code eine Verbindung zu einem Host, den kein genehmigter Befehl aufgeführt hat, ohne Abfrage und ohne Prüfung durch den Klassifikator ab. Die Ablehnung nennt den Host im Ergebnis des Befehls, und Claude führt den Befehl mit hinzugefügtem Host erneut aus.

IPv6-Adressen in Domain-Listen

Die Domain-Listen der Sandbox sind allowedDomains, deniedDomains und die WebFetch(domain:...)-Regeln, die in sie einfließen. Um in einer davon eine IPv6-Adresse abzugleichen, schreiben Sie das Literal in eckigen Klammern: "[::1]" passt auf diese Adresse an jedem Port, und "[::1]:443" passt nur an Port 443. Schreiben Sie den Port als Zahl von 1 bis 65535 ohne führende Nullen. Die Form in eckigen Klammern erfordert Claude Code v2.1.229 oder höher. Vor v2.1.229 las Claude Code den Text nach dem letzten Doppelpunkt eines Eintrags ohne Klammern als Port, wenn es sich um eine Portnummer handelte, sodass ::1:443 die Adresse ::1 an Port 443 bezeichnete.

Wenn Sie bei der Netzwerk-Genehmigungsabfrage für eine IPv6-Adresse „Yes, and don't ask again" wählen, speichert Claude Code die WebFetch(domain:...)-Regel mit der Adresse in eckigen Klammern, sodass die Regel die Adresse auch in zukünftigen Sitzungen weiterhin abgleicht.

Ein Eintrag ohne Klammern mit zwei oder mehr Doppelpunkten ist mehrdeutig: ::1:443 ist sowohl eine vollständige IPv6-Adresse als auch eine Adresse gefolgt von einem Port. Claude Code setzt mehrdeutige Schreibweisen konservativ durch, statt zu raten, welche Lesart Sie gemeint haben:

Denylists: Claude Code sperrt jede Lesart, als die der Eintrag geparst werden kann, sodass die von Ihnen gemeinte Lesart in jedem Fall blockiert ist. Bei einem Eintrag ohne parsbare Lesart blockiert Claude Code nichts.
Allowlists: Claude Code erlaubt nie mehr, als Sie geschrieben haben. Es schreibt einen mehrdeutigen Eintrag in seine Host-und-Port-Lesart um, wenn diese Lesart sauber geparst werden kann, und verwirft den Eintrag gegebenenfalls ganz, statt die Allowlist zu erweitern.

Führen Sie claude doctor in Ihrem Terminal aus, um die betroffenen Einträge zu finden: Die Warnung Sandbox network domain entries have unreliable spellings nennt bis zu drei davon und zählt die übrigen. Schreiben Sie jeden davon in die Form mit eckigen Klammern um, damit die Warnung verschwindet. Die Warnung nennt auch Einträge, deren Schreibweise aus anderen Gründen unzuverlässig ist, etwa wegen @, Pfad- oder Query-Zeichen oder Platzhaltern innerhalb eckiger Klammern.

Durchsetzung auf Betriebssystemebene

Das in einer Sandbox ausgeführte Bash-Tool verwendet Sicherheitsprimitive des Betriebssystems:

macOS: verwendet Seatbelt zur Durchsetzung der Sandbox
Linux: verwendet bubblewrap zur Isolation
WSL2: verwendet bubblewrap, wie Linux

WSL1 wird nicht unterstützt, da bubblewrap Kernel-Funktionen benötigt, die nur in WSL2 verfügbar sind.

Sie können das Paket @anthropic-ai/sandbox-runtime auch eigenständig ausführen, um den Claude Code-Prozess zu umschließen. Siehe Sandbox-Laufzeit.

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, außer dass eine Deny- oder Ask-Regel EndConversation nicht blockieren kann, während ein anderes Tool verbleibt.
Sandboxing bietet OS-Level-Durchsetzung, die einschränkt, worauf Shell-Befehle auf Dateisystem- und Netzwerk-Ebene zugreifen können. Es gilt nur für Bash, PowerShell und Monitor-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:

Einstellung oder Regel	Was es tut
`sandbox.filesystem.allowWrite`	Gewährt Subprozess-Schreibzugriff auf Pfade außerhalb des Arbeitsverzeichnisses
`sandbox.filesystem.denyWrite` und `sandbox.filesystem.denyRead`	Blockiert Subprozess-Zugriff auf spezifische Pfade
`sandbox.filesystem.allowRead`	Erlaubt das Lesen spezifischer Pfade innerhalb einer `denyRead`-Region erneut
`sandbox.filesystem.disabled`	Deaktiviert die Dateisystem-Schicht vollständig, während die Netzwerk-Isolation beibehalten wird
`Edit` Zulassungsregeln	Gewähren Schreibzugriff auf spezifische Pfade, auf die gleiche Weise wie `sandbox.filesystem.allowWrite`
`Read` und `Edit` Deny-Regeln	Blockiert Zugriff auf spezifische Dateien oder Verzeichnisse
`WebFetch(domain:...)` Zulassungs- und Deny-Regeln	Steuern Domain-Zugriff
Sandbox `allowedDomains`	Steuert, auf welche Domains Shell-Befehle zugreifen können
Sandbox `deniedDomains`	Blockiert spezifische Domains, auch wenn ein breiteres `allowedDomains`-Wildcard sie sonst zulassen würde

Pfade und Domains aus beiden Sandbox-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:

	Was es steuert	Was die Eingabeaufforderung ersetzt
`/sandbox`	Worauf ein Bash-Befehl zugreifen kann, sobald er ausgeführt wird	Die Sandbox-Grenze selbst, im Auto-Allow-Modus
Auto-Modus	Ob jeder Tool-Aufruf ausgeführt wird	Ein Klassifizierer, der Aktionen überprüft
`--dangerously-skip-permissions`	Ob jeder Tool-Aufruf ausgeführt wird	Nichts. Geschützte Pfad-Prüfungen werden auch übersprungen; die Aktionen, die kein Modus automatisch genehmigt, gelten immer noch

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, mit den Ausnahmen, die unter Sandbox-Modi aufgelistet sind. Um eine Isolationsgrenze für unbeaufsichtigte Läufe zu wählen, siehe Sandbox-Umgebungen. Eine Tabelle mit häufigen Genehmigungsmodus- und Sandbox-Paarungen mit den Flags, die jeweils starten, finden Sie unter Häufige Setups.

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, verweigert den Start von Claude Code, wenn die Plattform nicht unterstützt wird oder eine Abhängigkeit fehlt, 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 verhindert den Start von Claude Code, anstatt auf eine Ausführung ohne Sandbox zurückzufallen
allowUnsandboxedCommands: false: Claude Code ignoriert die dangerouslyDisableSandbox-Fluchtluke. Wenn ein Befehl unter der Sandbox fehlschlägt, kann Claude ihn daher nicht ohne Sandbox erneut versuchen

Erwägen Sie zusätzlich diese Ergänzungen:

Fügen Sie excludedCommands für alle von der Organisation genehmigten Tools hinzu, die ohne Isolation ausgeführt werden müssen, da diese Konfiguration verhindert, dass die Einstellungen eines Repositorys Befehle aus der Sandbox herausnehmen
Fügen Sie sandbox.credentials-Einträge für Anmeldedaten-Verzeichnisse wie ~/.aws und ~/.ssh und für geheime Umgebungsvariablen hinzu, da die Standard-Leserichtlinie diese immer noch zulässt

Diese Konfiguration führt die Befehle, die Claude ausführt, in der Sandbox aus. Ein Entwickler kann immer noch einen Befehl an der !-Shell-Modus-Eingabeaufforderung eingeben und ihn außerhalb der Sandbox ausführen, mit dem gleichen Zugriff, den er bereits in jedem Terminal außerhalb von Claude Code hat. Siehe strikter Sandbox-Modus für die Sitzungen, in denen eingegebene Befehle in der Sandbox ausgeführt werden.

Die Sandbox läuft nicht auf nativem Windows, daher beendet sich Claude Code auf diesen Rechnern beim Start, wenn failIfUnavailable gesetzt ist. Wenn Ihre Flotte Windows-Hosts enthält, können Sie:

Die Konfiguration nach Betriebssystem ausliefern: Stellen Sie sie über Ihr MDM oder als Datei für verwaltete Einstellungen nur auf macOS- und Linux-Rechnern bereit. Server-verwaltete Einstellungen gelten für alle Benutzer in der Organisation
Windows-Benutzer in eine unterstützte Umgebung verlagern: Lassen Sie sie Claude Code in WSL2 oder einem Container ausführen

Verhindern Sie, dass Entwickler die Richtlinie erweitern

Wenn verwaltete Einstellungen einen booleschen Schlüssel wie enabled oder failIfUnavailable setzen, verwendet Claude Code den verwalteten Wert und ignoriert alles, was ein Entwickler lokal setzt. Für Array-Schlüssel wie allowRead führt Claude Code Einträge aus den Geltungsbereichen zusammen, die die Sitzung lädt, daher kann ein Entwickler Einträge anhängen, die die Richtlinie erweitern, sofern keine Sperre diesen Schlüssel abdeckt.

Sofern verwaltete Einstellungen sie nicht setzen, können die Benutzereinstellungen eines Entwicklers oder --settings die folgenden Schlüssel einschalten. Die .claude/settings.json eines Repositorys kann dies ebenfalls, es sei denn, die Sandbox ist vom Administrator erforderlich. Jeder dieser Schlüssel schwächt die Sandbox, setzen Sie ihn daher in verwalteten Einstellungen auf false, wenn Sie nicht möchten, dass er verwendet wird:

enableWeakerNestedSandbox
enableWeakerNetworkIsolation
network.allowAllUnixSockets
network.allowLocalBinding
allowAppleEvents, den ein Repository nicht einschalten kann

Setzen Sie allowManagedReadPathsOnly auf true in verwalteten Einstellungen, damit nur allowRead-Einträge aus verwalteten Einstellungen berücksichtigt werden. 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. Bei aktiver Sperre können nur verwaltete Einstellungen einen Proxy-Port setzen.

Wenn verwaltete Einstellungen sandbox.filesystem konfigurieren oder einen beliebigen sandbox.credentials.files-Eintrag mit "mode": "deny" auflisten, können nur verwaltete Einstellungen filesystem.disabled setzen, daher können Entwickler von Administratoren bereitgestellte Filesystem-Einschränkungen nicht ausschalten. Ob ein mask-Eintrag den Schlüssel fixiert, hängt davon ab, wie er sich auflöst; die Tabelle unter Welche Einstellungen können es deaktivieren behandelt die vier Fälle.

Repository-Einstellungen bei einer vom Administrator erforderlichen Sandbox

Die Sandbox ist vom Administrator erforderlich, solange eine dieser Einstellungen wirksam ist:

allowUnsandboxedCommands ist in verwalteten Einstellungen auf false gesetzt, oder mit dem --settings-Flag, sofern verwaltete Einstellungen es nicht auf true setzen
allowManagedDomainsOnly ist in verwalteten Einstellungen auf true gesetzt

Diese Einstellungen schalten die Sandbox nicht ein, setzen Sie daher auch enabled.

Solange die Sandbox vom Administrator erforderlich ist, übernimmt Claude Code die Einstellungen, die sie lockern, nur aus verwalteten Einstellungen, dem --settings-Flag und der ~/.claude/settings.json jedes Entwicklers. Diese Einstellungen in der .claude/settings.json und .claude/settings.local.json eines Repositorys ignoriert es:

Repository-Einstellung	Was Claude Code ignoriert
`excludedCommands`, `ignoreViolations`, `network.allowedDomains`, `network.allowUnixSockets`, `network.allowMachLookup`, `network.httpProxyPort`, `network.socksProxyPort`	Jeden Eintrag
`filesystem.allowWrite`, `Edit(...)`-Allow-Regeln, `permissions.additionalDirectories`	Den Schreibzugriff, den jeder Eintrag Befehlen in der Sandbox gewährt. Claudes Datei-Tools befolgen weiterhin die `Edit(...)`-Regeln und zusätzlichen Verzeichnisse
`WebFetch(domain:...)`-Allow-Regeln	Den Host, den jede Regel zur Sandbox-Allowlist hinzufügt. Das WebFetch-Tool befolgt die Regel weiterhin
`enableWeakerNestedSandbox`, `enableWeakerNetworkIsolation`, `network.allowAllUnixSockets`, `network.allowLocalBinding`	`true`. Ein `false` gilt weiterhin
`enabled`, `failIfUnavailable`	`false`, wenn die `~/.claude/settings.json` des Entwicklers `true` setzt
`filesystem.allowRead`	Einen Eintrag an oder unterhalb eines Pfads, dessen Lesen verwaltete Einstellungen, `--settings` oder Benutzereinstellungen verweigern, oder ein Glob, der einen solchen treffen könnte

Diese Einstellungen gelten weiterhin, solange die Sandbox vom Administrator erforderlich ist:

In den Dateien eines Repositorys: Deny-Einträge und der Wert von autoAllowBashIfSandboxed. Setzen Sie den Schlüssel in verwalteten Einstellungen, um zu verhindern, dass ein Repository ihn ändert
In den eigenen Einstellungen eines Entwicklers: Die Einstellungen aus der Tabelle gelten weiterhin aus ~/.claude/settings.json oder --settings, sofern keine nur verwaltete Sperre wie allowManagedDomainsOnly sie abdeckt. Die meisten davon, etwa excludedCommands und filesystem.allowWrite, haben keine nur verwaltete Sperre

Die Konfiguration unter Erzwingen Sie Sandboxing mit verwalteten Einstellungen macht die Sandbox vom Administrator erforderlich. Fügen Sie die excludedCommands-, allowWrite- und Socket-Einträge, die Ihre genehmigten Tools benötigen, zu verwalteten Einstellungen hinzu, da ein Repository sie nicht bereitstellen kann.

Erfordert Claude Code v2.1.285 oder höher. Von v2.1.282 bis v2.1.284 führten dieselben Einstellungen dazu, dass Claude Code die excludedCommands-Einträge eines Repositorys ignorierte.

Sperren, die ohne eine vom Administrator erforderliche Sandbox gelten

Einige Einstellungen führen dazu, dass Claude Code die Repository-Schlüssel ignoriert, die eine Einschränkung direkt überschreiben, selbst wenn die Sandbox nicht vom Administrator erforderlich ist. Jede davon hat diese Wirkung nur, wenn Sie sie in einer Datei setzen, die in ihrer Zeile genannt ist, und die anderen Sandbox-Einstellungen des Repositorys gelten weiterhin. Erfordert Claude Code v2.1.285 oder höher.

Einstellung	Wo Sie sie setzen	Was Claude Code in den Einstellungen eines Repositorys ignoriert
`network.deniedDomains` oder eine `WebFetch(domain:...)`-Deny-Regel	Verwaltete Einstellungen, `--settings`	`httpProxyPort` und `socksProxyPort`
`network.strictAllowlist`	Verwaltete Einstellungen, `--settings`, Benutzereinstellungen	Die Proxy-Ports, `allowedDomains` und `WebFetch(domain:...)`-Allow-Regeln
`filesystem.denyRead`, eine `Read(...)`-Deny-Regel oder ein `credentials.files`-Eintrag	Verwaltete Einstellungen, `--settings`	Einen `allowRead`-, `allowWrite`-, `Edit(...)`-Allow- oder `additionalDirectories`-Eintrag an oder unterhalb eines Pfads, dessen Lesen verwaltete Einstellungen, `--settings` oder Benutzereinstellungen verweigern, oder ein Glob, der einen solchen treffen könnte

Diese Sperren ändern, was Befehle in der Sandbox erreichen können. Das WebFetch-Tool und Claudes Datei-Tools befolgen weiterhin die Regeln und zusätzlichen Verzeichnisse eines Repositorys.

Benutzerdefinierte Proxy-Konfiguration

Um Sandbox-Datenverkehr mit Ihren eigenen Tools zu inspizieren, zu filtern oder zu protokollieren, ersetzen Sie den integrierten Sandbox-Proxy durch einen Proxy, den Sie auf demselben Rechner betreiben.

Um Sandbox-Datenverkehr stattdessen durch einen Unternehmens-Proxy an anderer Stelle in Ihrem Netzwerk zu leiten, setzen Sie HTTPS_PROXY, wie es der Eintrag Unternehmens-Proxy unter Netzwerkisolation beschreibt. Auf diese Weise gilt die Allowlist von Claude Code weiterhin.

Um Befehle in der Sandbox an Ihren Proxy zu leiten, setzen Sie die localhost-Ports, auf denen er lauscht, in Sandbox-Einstellungen:

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

Wenn Sie einen Port setzen und außerdem HTTPS_PROXY oder HTTP_PROXY setzen, leitet Claude Code das, was Befehle in der Sandbox an Ihren Proxy senden, nicht an den Proxy weiter, den diese Variablen nennen. Um einen Unternehmens-Proxy zu erreichen, konfigurieren Sie Ihren eigenen Proxy so, dass er an diesen weiterleitet.

Welche Dateien einen Port setzen können, hängt von Ihren anderen Sandbox-Einstellungen ab:

allowManagedDomainsOnly ist aktiviert: nur verwaltete Einstellungen
Die Sandbox ist vom Administrator erforderlich, oder eine engere Netzwerksperre gilt: verwaltete Einstellungen, --settings und Benutzereinstellungen
Andernfalls: jede Einstellungsdatei

Claude Code ignoriert einen Port, der an anderer Stelle gesetzt ist. Vor v2.1.285 konnte jede Einstellungsdatei einen Port setzen.

Fehlerbehebung

Einige Befehle schlagen in der Sandbox fehl, obwohl sie außerhalb funktionieren. Die folgende Liste enthält kurze Lösungen. Fehler, die eine längere Erklärung erfordern, haben jeweils eine eigene Überschrift.

Wenn die Sandbox Ihrer Organisation vom Administrator vorgeschrieben ist, ignoriert Claude Code die in diesen Lösungen genannten Einstellungen in den Einstellungsdateien eines Projekts. Speichern Sie sie daher in ~/.claude/settings.json, wo sie in jedem Projekt gelten. Wenn eine Lösung trotzdem keine Wirkung zeigt, setzen die verwalteten Einstellungen Ihrer Organisation möglicherweise diesen Schlüssel.

Eine Lösung, die ein excludedCommands-Muster hinzufügt, nimmt die Befehle, auf die das Muster zutrifft, aus der Sandbox heraus. Siehe was ein ausgeschlossener Befehl tun kann.

Befehle schlagen mit einem host-not-allowed-Fehler fehl: Viele CLI-Tools müssen bestimmte Hosts erreichen. Genehmigen Sie den Host, wenn Sie gefragt werden, oder fügen Sie ihn zu allowedDomains hinzu. Wenn Ihre Organisation die Allowlist mit allowManagedDomainsOnly sperrt, erscheint keine Abfrage; bitten Sie in diesem Fall Ihren Administrator, den Host hinzuzufügen.
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 bei der TLS-Verifizierung auf macOS fehl: Tools wie gh, gcloud und terraform können unter Seatbelt bei der TLS-Verifizierung fehlschlagen. Fügen Sie für jedes Tool ein Muster wie gh * zu excludedCommands hinzu. Das Tool läuft dann mit Ihrem vollen Zugriff und seinen gespeicherten Anmeldedaten. Wenn Sie httpProxyPort mit einem MITM-Proxy und einer benutzerdefinierten CA verwenden, setzen Sie stattdessen enableWeakerNetworkIsolation auf true.
open, osascript oder browserbasierte Authentifizierungsabläufe 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 hebt die Isolation der Codeausführung auf, da in der Sandbox ausgeführte Befehle dann ohne Benutzerabfrage andere Anwendungen außerhalb der Sandbox starten und AppleScript-Befehle an laufende Anwendungen senden können, vorbehaltlich der macOS-Abfrage zur Automatisierungszustimmung (TCC). Alternativ können Sie ein Muster wie open * zu excludedCommands hinzufügen. Jeder open-Aufruf durchläuft dann den Berechtigungsablauf, und open kann jede Datei oder App starten, auch eine, die Claude geschrieben hat.
docker-Befehle schlagen fehl: docker ist nicht kompatibel mit der Sandbox. Nehmen Sie die benötigten docker-Befehle mit einem excludedCommands-Muster wie docker compose * aus der Sandbox heraus. Dieser Abschnitt erklärt, was ein ausgeschlossener docker-Befehl erreichen kann. Ein engeres Muster nimmt weniger Befehle aus der Sandbox heraus.
pbcopy, xclip oder wl-copy aktualisiert die Zwischenablage nicht: Diese Zwischenablage-Dienstprogramme können aus der Sandbox heraus die Systemzwischenablage möglicherweise nicht erreichen, in welchem Fall der Text, der an sie weitergeleitet wird, nicht ankommt.

Um Claudes Ausgabe in Ihre Zwischenablage zu kopieren, bitten Sie Claude, sie in seiner Antwort auszugeben, und führen Sie dann /copy aus. /copy schreibt aus dem Claude Code-Prozess in die Zwischenablage, nicht aus einem in der Sandbox ausgeführten Befehl.

Wenn Claude Text an eines dieser Tools weiterleitet, nimmt das Hinzufügen des Tools zu excludedCommands diesen Aufruf nicht von sich aus aus der Sandbox heraus.
Ein git-Befehl schlägt mit unable to unlink old fehl: git merge, git checkout und ähnliche Befehle schlagen auf diese Weise fehl, wenn sie eine Datei ersetzen müssen, in die die Sandbox Schreibvorgänge verweigert, unabhängig davon, ob sich diese Datei unter einem geschützten Pfad wie .claude/skills befindet, unter einem Ihrer denyWrite-Einträge oder außerhalb der Verzeichnisse, in die die Sandbox Befehle überhaupt schreiben lässt. Unter Linux und WSL2 endet der Fehler mit Read-only file system.

Nach dem Fehler kann Claude anbieten, den Befehl außerhalb der Sandbox erneut auszuführen; genehmigen Sie diesen Wiederholungsversuch, oder führen Sie den git-Befehl selbst in einem anderen Terminal aus. Wenn Sie allowUnsandboxedCommands auf false gesetzt haben, kann Claude den Wiederholungsversuch nicht anbieten, also führen Sie den Befehl selbst aus.
Bubblewrap startet in einem Container nicht: In einem unprivilegierten Container kann bubblewrap kein neues /proc-Dateisystem einhängen, daher schlagen in der Sandbox ausgeführte Befehle mit einem bwrap-Fehler wie Can't mount proc on /newroot/proc: Operation not permitted fehl. Setzen Sie enableWeakerNestedSandbox auf true, damit die innere Sandbox stattdessen das vorhandene /proc des Containers per Bind-Mount einbindet. Verwenden Sie diese Einstellung nur, wenn der äußere Container bereits die Isolationsgrenze bietet, die Sie benötigen, da sie in der Sandbox ausgeführten Befehlen Prozessinformationen zugänglich macht, die ein neu eingehängtes /proc verbergen würde.
Schreibgeschützte 0-Byte-Dateien erscheinen in .claude-Einstellungspfaden, und „Ja, und nicht mehr fragen" wird nicht gespeichert: Unter Linux und WSL2 setzt die Sandbox eine Schreibsperre für eine noch nicht existierende Datei durch, indem sie dort einen schreibgeschützten 0-Byte-Platzhalter erstellt, während ein Befehl in der Sandbox ausgeführt wird. Die Sandbox entfernt den Platzhalter danach. Wenn eine Sitzung vor dieser Bereinigung beendet wird, beispielsweise durch SIGKILL, bleiben die Platzhalter bestehen. Spätere Sitzungen binden sie bei jedem Start erneut schreibgeschützt ein, daher schlägt ein Schreibvorgang in die Einstellungen, etwa das Speichern einer Berechtigungswahl, dort fehl, wo einer vorhanden ist.

Führen Sie claude doctor aus, um die verbleibenden Platzhalter-Dateien aufzulisten. Die Warnung Stale sandbox mask files left by a killed session nennt bis zu drei davon und zählt den Rest. Löschen Sie jede Datei mit rm, während keine andere Claude Code-Sitzung in diesem Projekt ausgeführt wird. Vor v2.1.257 ließ Claude Code dieselben Platzhalter ohne Kennzeichnung zurück.
--dangerously-skip-permissions schlägt als root fehl: Dieses Flag wird blockiert, wenn es als root oder über sudo unter Linux und macOS ausgeführt wird, da root-Zugriff in Kombination mit fehlenden Berechtigungsabfragen jede Datei und jeden Dienst auf dem System ändern kann. Die Überprüfung wird in einer erkannten Sandbox automatisch übersprungen. Um autonom in einem Container zu laufen, verwenden Sie die Dev-Container-Konfiguration, die Claude Code als Nicht-Root-Benutzer ausführt.

`git` über SSH schlägt bei aktivierter Sandbox fehl

Unter macOS schlagen git fetch, git pull und git push gegen ein SSH-Remote in der Sandbox fehl, selbst wenn der Host zugelassen ist. Unter Linux und WSL2 funktionieren sie, sobald der Host zugelassen ist. Claude Code tunnelt die SSH-Verbindung von git durch den Sandbox-Proxy, und der macOS-Tunnel kann sich nicht bei diesem Proxy authentifizieren.

Prüfen Sie unter Linux und WSL2 Folgendes, wenn die Verbindung weiterhin fehlschlägt:

Der Host ist auf Port 22 zugelassen: Ein allowedDomains-Eintrag ohne Port, etwa "git.example.com", deckt dies ab
Ihr Unternehmensproxy lässt Port 22 zu: Wenn Ihr Netzwerk einen Upstream-Proxy erfordert, läuft auch der Tunnel darüber
Der Schlüssel ist als Datei lesbar: Die Sandbox kann den ssh-agent-Socket blockieren, und ein denyRead- oder credentials-Eintrag für ~/.ssh verbirgt Ihre Schlüsseldateien

Stellen Sie unter macOS das Remote auf HTTPS um, wofür HTTPS-Anmeldedaten wie ein Personal Access Token erforderlich sind:

git remote set-url origin https://git.example.com/example-org/example-repo.git

Wenn Sie das SSH-Remote beibehalten müssen, nehmen Sie die Netzwerkbefehle von git mit excludedCommands aus der Sandbox heraus:

{
  "sandbox": {
    "excludedCommands": ["git fetch *", "git pull *", "git push *"]
  }
}

Diese Einträge treffen auf git push origin main zu. Ein Aufruf, der ein cd hinzufügt, git -C verwendet oder eine Befehlssubstitution enthält, bleibt in der Sandbox. Die ausgeschlossenen git-Befehle können jeden Host erreichen, nicht nur die in allowedDomains.

Einfaches ssh, scp und rsync über SSH schlagen aus dem Grund fehl, den der Eintrag zu Datenbank-Clients nennt.

Ein Datenbank-Client oder ein anderes Nicht-HTTP-Tool erreicht einen zugelassenen Host nicht

Ein Tool, das die Proxy-Umgebungsvariablen ignoriert, kann sich aus der Sandbox heraus nicht verbinden, nicht einmal mit einem Host in allowedDomains. Ein in der Sandbox ausgeführter Befehl hat keinen direkten Weg ins Netzwerk, daher schlägt ein Tool fehl, das seine eigene Verbindung öffnet. Die meisten Datenbanktreiber, einfaches ssh und Tools, die UDP verwenden, verhalten sich so.

Der Fehler sieht wie ein Netzwerk- oder Namensauflösungsfehler aus:

macOS: Operation not permitted oder ein Namensauflösungsfehler wie Could not resolve host
Linux und WSL2: Network is unreachable oder ein Namensauflösungsfehler wie Temporary failure in name resolution

Ein Tool, das den Proxy verwendet, schlägt anders fehl, wenn sein Host nicht zugelassen ist. Sie erhalten eine Netzwerkabfrage, oder das Tool erhält eine 403-Antwort vom Proxy.

Damit sich das Tool verbinden kann, führen Sie den Befehl, der es benötigt, mit excludedCommands außerhalb der Sandbox aus. Dieses Beispiel schließt ein Skript aus und fügt eine Ask-Regel hinzu, sodass Sie jede Ausführung genehmigen:

{
  "sandbox": {
    "excludedCommands": ["python scripts/load_orders.py *"]
  },
  "permissions": {
    "ask": ["Bash(python scripts/load_orders.py *)"]
  }
}

Das Skript läuft mit Ihrem vollen Zugriff, und Claude kann ein Skript bearbeiten, das sich in Ihrem Arbeitsverzeichnis befindet. Prüfen Sie es daher, wenn die Abfrage erscheint.

Ein Befehl erreicht einen Server auf localhost nicht

Standardmäßig kann sich ein in der Sandbox ausgeführter Befehl nicht direkt mit einem Server verbinden, der auf Ihrem Rechner außerhalb der Sandbox läuft, etwa einem Dev-Server oder einer Datenbank in einem Container. Was Sie ändern können, hängt von Ihrer Plattform ab:

macOS: Setzen Sie network.allowLocalBinding auf true. In der Sandbox ausgeführte Befehle können dann auf Netzwerkports lauschen und sich mit jedem Port auf localhost verbinden, was jeden anderen dort lauschenden Dienst einschließt. Ein localhost-Dienst, der keine Authentifizierung erfordert, etwa ein Debugger, kann dann für den Befehl außerhalb der Sandbox handeln, und ein Befehl, der auf einer Nicht-Loopback-Adresse lauscht, nimmt Verbindungen von anderen Rechnern an
Linux und WSL2: Das localhost eines in der Sandbox ausgeführten Befehls ist privat für diesen Befehl. Der Befehl kann auf einem Port lauschen und Server erreichen, die er selbst gestartet hat. Eine direkte Verbindung zu localhost oder 127.0.0.1 erreicht keine Server auf dem Host, und allowLocalBinding hat keine Wirkung. Führen Sie den Befehl, der den Server des Hosts benötigt, mit excludedCommands außerhalb der Sandbox aus, wo er keinen Dateisystem- oder Netzwerkbeschränkungen unterliegt. Für Verbindungen, die über den Sandbox-Proxy laufen, siehe Hostnamen, die zu lokalen Adressen aufgelöst werden

Dieses Beispiel aktiviert die Einstellung für macOS:

{
  "sandbox": {
    "network": {
      "allowLocalBinding": true
    }
  }
}

Ein allowedDomains-Eintrag für localhost gilt für Verbindungen, die über den Proxy laufen, und ändert daher keine direkte Verbindung. Claude Code setzt NO_PROXY für in der Sandbox ausgeführte Befehle, damit sie sich direkt statt über den Proxy mit localhost verbinden. Der Eintrag macht außerdem jeden Port auf dem localhost Ihres Rechners für einen Befehl zugänglich, der den Proxy tatsächlich verwendet. Für einen Entwicklungs-Hostnamen, der auf 127.0.0.1 zeigt, siehe Ein zugelassener Hostname wird mit resolved to a loopback address abgelehnt.

Ein zugelassener Hostname wird mit `resolved to a loopback address` abgelehnt

Der Sandbox-Proxy lehnt einen zugelassenen Hostnamen ab, der zu einer lokalen Adresse aufgelöst wird. Das betrifft Entwicklungsnamen wie myapp.test, die auf 127.0.0.1 zeigen. Der Befehl erhält eine 403-Antwort, deren Response-Body die Art der Adresse nennt, etwa Connection to myapp.test blocked: resolved to a loopback address.

Fügen Sie die IP-Adresse, zu der der Name aufgelöst wird, zusammen mit dem Hostnamen zu allowedDomains hinzu, jeweils mit dem Port, auf dem Ihr Server lauscht:

{
  "sandbox": {
    "network": {
      "allowedDomains": ["myapp.test:3000", "127.0.0.1:3000"]
    }
  }
}

Ein IP-Adress-Eintrag ohne Port ermöglicht in der Sandbox ausgeführten Befehlen, jeden Dienst zu erreichen, der auf dieser Adresse lauscht.

Vor v2.1.284 verband sich der Proxy mit der Adresse, zu der ein zugelassener Hostname aufgelöst wurde, ganz gleich, welche es war.

`/sandbox` schlägt mit `Sandbox settings are overridden by a higher-priority configuration` fehl

/sandbox gibt Error: Sandbox settings are overridden by a higher-priority configuration and cannot be changed locally. aus, statt sein Panel zu öffnen, wenn eine höhere Einstellungsebene sandbox.enabled, sandbox.autoAllowBashIfSandboxed oder sandbox.allowUnsandboxedCommands setzt. Das Panel speichert Ihre Auswahl in .claude/settings.local.json, und ein dort gespeicherter Wert kann diese Ebenen nicht überschreiben.

Verwaltete Einstellungen und --settings haben Vorrang vor lokalen Einstellungen. Um zu sehen, welche davon diese Sitzung geladen hat, führen Sie /status aus und lesen Sie die Zeile Setting sources:

Command line arguments: Wenn Sie Claude Code mit --settings gestartet haben, prüfen Sie, ob die übergebene Datei oder das übergebene JSON einen dieser Schlüssel setzt. Falls ja, ändern Sie den Wert dort, oder starten Sie Claude Code erneut ohne diese Schlüssel.
Enterprise managed settings: Die verwalteten Einstellungen Ihrer Organisation sind geladen. Wenn sie einen dieser Schlüssel setzen, können Sie diesen Schlüssel weder über /sandbox noch über eine von Ihnen kontrollierte Einstellungsdatei ändern. Wenden Sie sich in diesem Fall an Ihren Administrator.

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: Die Sandbox schränkt ein, mit welchen Domains Prozesse sich verbinden können. Standardmäßig beendet oder inspiziert der integrierte Proxy TLS auf ausgehenden Datenverkehr nicht, daher werden die Inhalte verschlüsselter Verbindungen nicht untersucht. Die experimentelle Einstellung network.tlsTerminate beendet TLS am Proxy für mask-Anmeldedaten-Substitution, fügt aber keine Inhaltsfilterung hinzu. 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 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-Berechtigungseskalation: Übermäßig breite Dateisystem-Schreibberechtigungen 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. 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: In der Sandbox ausgeführte Befehle können andere Anwendungen ohne Sandbox und ohne Rückfrage beim Benutzer starten und können AppleScript-Befehle an laufende Anwendungen senden, vorbehaltlich der macOS-Zustimmungsabfrage für Automatisierung pro App (TCC). Es wird nur von Benutzer-, verwalteten oder CLI-Einstellungen berücksichtigt. Projekteinstellungen können es nicht aktivieren.

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 Shell-Befehle und deren untergeordnete Prozesse. Was außerhalb der Sandbox ausgeführt wird listet die Tools und Hilfsprozesse auf, die sie nicht abdeckt. Computer-Nutzung und Subagenten verhalten sich in Bezug auf die Sandbox wie folgt:

Computer-Nutzung: Wenn Claude Apps öffnet und Ihren Bildschirm steuert, läuft es auf Ihrem tatsächlichen Desktop, anstatt in einer isolierten Umgebung. Berechtigungsabfragen pro App kontrollieren jede Anwendung. Siehe Computer-Nutzung in der CLI oder Computer-Nutzung auf Desktop.
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.
Mods: Ein Mod ist ein Plugin, das seinen eigenen Code innerhalb von Claude Code ausführt, und ein Prozess, den ein Mod startet, läuft außerhalb der Sandbox. Siehe Was ein Mod erreichen kann.

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
Alle Einstellungen: Jeder Einstellungsschlüssel
CLI-Referenz: Befehlszeilenoptionen

sandboxing.md +577 −239

2> Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt2> Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt

3> Use this file to discover all available pages before exploring further.3> Use this file to discover all available pages before exploring further.

4 4

~~5# Konfigurieren Sie das Sandboxed-Bash-Tool~~5# Das Bash-Tool in der Sandbox konfigurieren

6 6

~~7> Erfahren Sie, wie das Sandboxed-Bash-Tool von Claude Code Dateisystem- und Netzwerkisolation für sicherere und autonomere Agent-Ausführung bietet.~~7> Beschränken Sie mit der integrierten Sandbox, auf welche Dateien und Netzwerk-Hosts die Shell-Befehle von Claude Code zugreifen können. Aktivieren Sie sie, legen Sie die Grenze fest und beheben Sie, was dadurch nicht mehr funktioniert.

8 8

9Die 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-, PowerShell- oder Monitor-Befehl und seine Kindprozesse.9Die Bash-Sandbox ist eine Grenze, die das Betriebssystem um die Shell-Befehle durchsetzt, die Claude auf Ihrem Rechner ausführt. Sie legen fest, auf welche Dateien und Netzwerkdomänen diese Befehle zugreifen können, und die Beschränkungen gelten für Bash-, PowerShell- und Monitor-Befehle sowie für die Prozesse, die diese starten. Da das Betriebssystem die Beschränkungen während der Ausführung eines Befehls anwendet, kann Claude Code [Befehle in der Sandbox ausführen, ohne Sie zu fragen](#sandbox-modes), ob Sie jeden einzelnen genehmigen.

11Die Sandbox umfasst nur Shell-Befehle. Die Datei-Tools von Claude, MCP-Server und Hooks [laufen außerhalb davon](#what-runs-outside-the-sandbox).

13Die Sandbox läuft unter macOS, Linux und WSL2. Unter nativem Windows führt Claude Code Befehle ohne Sandbox aus. Um die Sandbox auf einem Windows-Rechner zu verwenden, führen Sie Claude Code innerhalb einer WSL2-Distribution aus.

10 14

11<Note>15<Note>

12 Um andere Isolationsansätze wie Dev-Container, benutzerdefinierte Container und virtuelle Maschinen zu vergleichen, siehe [Sandbox-Umgebungen](/docs/de/sandbox-environments). Um Genehmigungseingaben für Tools außer Bash zu reduzieren, siehe [Genehmigungsmodi](/docs/de/permission-modes).16 Diese Seite behandelt die Sandbox um Shell-Befehle auf Ihrem eigenen Rechner. Andere Seiten behandeln verwandte Fragen:

18 * Wie eine Cloud-Sitzung isoliert wird, erfahren Sie unter [Sicherheit und Isolation](/docs/de/claude-code-on-the-web#security-and-isolation)

19 * Um andere Isolationsansätze wie Dev-Container, benutzerdefinierte Container und virtuelle Maschinen zu vergleichen, siehe [Sandbox-Umgebungen](/docs/de/sandbox-environments)

20 * Um Berechtigungsabfragen für andere Tools als Bash zu reduzieren, siehe [Berechtigungsmodi](/docs/de/permission-modes)

13</Note>21</Note>

14 22

23<h2 id="what-the-sandbox-restricts">

24 Was die Sandbox einschränkt

25</h2>

27Solange die Sandbox aktiviert ist, starten die Shell-Befehle, die Claude ausführt, innerhalb ihrer Grenzen, ebenso wie die Prozesse, die diese Befehle starten. Die Sandbox ist standardmäßig deaktiviert. Um sie zu aktivieren, führen Sie `/sandbox` in einer Sitzung aus, wie unter [Erste Schritte](#get-started) gezeigt, oder setzen Sie [`sandbox.enabled`](/docs/de/settings-reference#sandbox-enabled) in einer [Einstellungsdatei](/docs/de/settings) wie `~/.claude/settings.json` auf `true`.

29Die Tabelle zeigt, worauf ein in der Sandbox ausgeführter Befehl standardmäßig zugreifen kann, und welche Einstellungen den jeweiligen Standard ändern.

31| Zugriff | Standard | Ändern mit |

32| :- | :- | :- |

33| Schreiben | Das Arbeitsverzeichnis, ein benutzerspezifisches temporäres Verzeichnis und [von Ihnen hinzugefügte Verzeichnisse](/docs/de/permissions#additional-directories-grant-file-access-not-configuration). [Geschützte Pfade](#protected-paths) bleiben für Schreibzugriffe gesperrt | [`filesystem.allowWrite`](/docs/de/settings-reference#sandbox-filesystem-allowwrite), [`filesystem.denyWrite`](/docs/de/settings-reference#sandbox-filesystem-denywrite) |

34| Lesen | Der Großteil des Rechners, einschließlich Dateien mit Anmeldedaten wie `~/.ssh` und `~/.aws/credentials` | [`filesystem.denyRead`](/docs/de/settings-reference#sandbox-filesystem-denyread), [`credentials`](#protect-credentials) |

35| Netzwerk | Keine direkte Verbindung nach außen. Verbindungen laufen über einen Proxy auf Ihrem Rechner, der jeden Host mit Ihren erlaubten Domains abgleicht, die zunächst leer sind. Ihr Berechtigungsmodus entscheidet, [was mit anderen Hosts geschieht](#hosts-outside-your-allowed-domains) | [`network.allowedDomains`](/docs/de/settings-reference#sandbox-network-alloweddomains), [`network.deniedDomains`](/docs/de/settings-reference#sandbox-network-denieddomains) |

36| Umgebungsvariablen | Von Claude Code übernommen, einschließlich aller Secrets in dessen Umgebung | [`credentials`](#protect-credentials), [`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`](/docs/de/env-vars) |

38Claude Code baut die Sandbox auf dem Open-Source-Paket [`@anthropic-ai/sandbox-runtime`](https://github.com/anthropics/sandbox-runtime) auf.

40<h3 id="what-runs-outside-the-sandbox">

41 Was außerhalb der Sandbox läuft

42</h3>

44Die Sandbox umschließt Shell-Befehle. Diese Tools und Prozesse laufen außerhalb davon:

46* **Integrierte Datei- und Web-Tools**: Tools wie Read, Edit, Write, WebFetch und WebSearch folgen stattdessen [Berechtigungsregeln](/docs/de/permissions). Ein `denyRead`-Eintrag hält das Read-Tool nicht auf, und `allowedDomains` schränkt WebFetch nicht ein

47* **Andere Prozesse, die Claude Code startet**: Befehls-[Hooks](/docs/de/hooks), lokale [MCP-Server](/docs/de/mcp), [Plugin-Monitore](/docs/de/plugins/components#monitors), [LSP-Server](/docs/de/tools-reference#lsp-tool-behavior) und Hilfsbefehle wie Ihr [Statuszeilen](/docs/de/statusline)-Befehl und `apiKeyHelper` laufen mit Ihrem vollen Zugriff

49Einige Shell-Befehle laufen je nach Ihren Einstellungen ebenfalls außerhalb der Sandbox:

51* **Befehle, die Sie selbst eingeben**: Ein Befehl, den Sie an der [`!`-Eingabeaufforderung im Shell-Modus](/docs/de/interactive-mode#shell-mode-with-prefix) eingeben, läuft in den meisten Sitzungen ohne Sandbox. Unter [Strikter Sandbox-Modus](#turn-off-the-retry-with-strict-sandbox-mode) sind die Sitzungen aufgeführt, in denen ein von Ihnen eingegebener Befehl in der Sandbox läuft

52* **Ausgenommene Befehle**: Befehle, die mit [`excludedCommands`](#run-commands-outside-the-sandbox-with-excludedcommands) übereinstimmen, laufen ohne Sandbox

53* **Wiederholungsversuche ohne Sandbox**: Claude kann [darum bitten, einen Befehl ohne Sandbox auszuführen](#the-unsandboxed-retry-escape-hatch), in der Regel nachdem er in der Sandbox fehlgeschlagen ist

55Um die Tools, Prozesse und Befehle aus diesem Abschnitt hinter eine gemeinsame Grenze zu stellen, führen Sie den Claude-Code-Prozess selbst in einem [Container, einer virtuellen Maschine oder der Sandbox-Runtime](/docs/de/sandbox-environments) aus.

15<h2 id="get-started">57<h2 id="get-started">

16 Erste Schritte58 Erste Schritte

17</h2>59</h2>

18 60

~~19Die 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.~~61Die Sandbox ist in Claude Code integriert. Was Sie installieren müssen, hängt von Ihrer Plattform ab:

20 62

21Auf 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](#set-up-linux-and-wsl2) behandelt werden. Selbst wenn Sie diese noch nicht installiert haben, können Sie mit `/sandbox` beginnen, da sein Panel anzeigt, ob etwas fehlt.63* **macOS**: Das Sandboxing verwendet das integrierte Seatbelt-Framework, sodass Sie direkt mit den Schritten beginnen können

64* **Linux und WSL2**: Die Sandbox benötigt `bubblewrap` und `socat`, wie unter [Linux und WSL2 einrichten](#set-up-linux-and-wsl2) beschrieben. Auch wenn Sie diese noch nicht installiert haben, können Sie mit `/sandbox` beginnen, da dessen Panel anzeigt, ob etwas fehlt

22 65

23<Steps>66<Steps>

~~24 <Step title="Führen Sie /sandbox aus">~~67 <Step title="/sandbox ausführen">

25 Starten Sie eine Claude Code-Sitzung und führen Sie den Befehl `/sandbox` aus:68 Starten Sie eine Claude Code-Sitzung und führen Sie den Befehl `/sandbox` aus:

26 69

27 ```text theme={null}70 ```text theme={null}

28 /sandbox71 /sandbox

29 ```72 ```

30 73

~~31 Dies öffnet das Sandbox-Panel mit drei Registerkarten sowie einer Registerkarte „Dependencies" unter Linux, wenn der optionale Seccomp-Filter fehlt:~~74 Dadurch wird das Sandbox-Panel mit drei Tabs geöffnet, unter Linux zusätzlich mit einem Tab „Dependencies“, wenn der optionale seccomp-Filter fehlt:

32 75

~~33 * **Mode**: Wählen Sie, wie Sandbox-Befehle genehmigt werden, behandelt im nächsten Schritt~~76 * **Mode**: Legen Sie fest, wie Befehle in der Sandbox genehmigt werden; dies wird im nächsten Schritt beschrieben

34 * **Overrides**: Wählen Sie, ob Befehle, die unter der Sandbox fehlschlagen, auf unsandboxed ausweichen können. Dies ist die Einstellung [`allowUnsandboxedCommands`](/docs/de/settings-reference#sandbox-allowunsandboxedcommands)77 * **Overrides**: Legen Sie fest, ob Befehle, die in der Sandbox fehlschlagen, ersatzweise außerhalb der Sandbox ausgeführt werden dürfen. Dies ist die Einstellung [`allowUnsandboxedCommands`](/docs/de/settings-reference#sandbox-allowunsandboxedcommands)

35 * **Config**: Zeigen Sie die aufgelösten Sandbox-Einstellungen an78 * **Config**: Zeigen Sie die aufgelösten Sandbox-Einstellungen an

36 79

37 Wenn das Panel nur eine Registerkarte „Dependencies" anzeigt, fehlt ein erforderliches Paket. Installieren Sie es wie in [Linux und WSL2 einrichten](#set-up-linux-and-wsl2) beschrieben, starten Sie Claude Code neu und führen Sie `/sandbox` erneut aus.80 Wenn das Panel nur einen Tab „Dependencies“ anzeigt, fehlt ein erforderliches Paket. Installieren Sie es wie unter [Linux und WSL2 einrichten](#set-up-linux-and-wsl2) beschrieben, starten Sie Claude Code neu und führen Sie `/sandbox` erneut aus.

38 </Step>81 </Step>

39 82

~~40 <Step title="Wählen Sie einen Modus">~~83 <Step title="Einen Modus wählen">

41 Wählen Sie auf der Registerkarte „Mode" Auto-Allow oder reguläre Genehmigungen. Auto-Allow führt Sandbox-Befehle ohne Eingabeaufforderung aus, und reguläre Genehmigungen behalten die regulären Genehmigungseingaben bei, auch wenn Befehle in der Sandbox ausgeführt werden. Siehe [Sandbox-Modi](#sandbox-modes) für die Befehle, die im Auto-Allow-Modus immer noch eingeben.84 Wählen Sie im Tab „Mode“ entweder Auto-Allow oder reguläre Berechtigungen. Auto-Allow führt Befehle in der Sandbox ohne Nachfrage aus, während reguläre Berechtigungen die üblichen Berechtigungsabfragen beibehält, auch wenn Befehle in der Sandbox ausgeführt werden. Unter [Sandbox-Modi](#sandbox-modes) erfahren Sie, bei welchen Befehlen im Auto-Allow-Modus dennoch nachgefragt wird.

42 </Step>85 </Step>

43 86

~~44 <Step title="Führen Sie einen Bash-Befehl aus">~~87 <Step title="Einen Bash-Befehl ausführen">

45 Bitten Sie Claude, einen Befehl auszuführen, z. B. einen Build oder eine Test-Suite. Standardmäßig können Befehle in der Sandbox in das Arbeitsverzeichnis, ein [Temp-Verzeichnis pro Benutzer](/docs/de/env-vars) und alle [Verzeichnisse schreiben, die Sie hinzugefügt haben](/docs/de/permissions#additional-directories-grant-file-access-not-configuration) mit `--add-dir`, `/add-dir` oder `permissions.additionalDirectories`.88 Bitten Sie Claude, einen Befehl auszuführen, etwa einen Build oder eine Testsuite. Standardmäßig können Befehle innerhalb der Sandbox in das Arbeitsverzeichnis, ein [benutzerspezifisches temporäres Verzeichnis](/docs/de/env-vars) und alle [Verzeichnisse schreiben, die Sie](/docs/de/permissions#additional-directories-grant-file-access-not-configuration) mit `--add-dir`, `/add-dir` oder `permissions.additionalDirectories` hinzugefügt haben.

46 89

47 Wenn ein Befehl zum ersten Mal eine neue Netzwerk-Domain benötigt, fordert Claude Code zur Genehmigung auf; im [Auto-Modus](/docs/de/permission-modes#eliminate-prompts-with-auto-mode) benennt Claude stattdessen die Hosts, die ein Befehl benötigt, [im Befehl selbst](#per-command-allowed-domains-in-auto-mode) für den Klassifizierer zur Überprüfung damit.90 Wenn ein Befehl zum ersten Mal eine neue Netzwerkdomain benötigt, bittet Claude Code um Genehmigung; im [Auto-Modus](/docs/de/permission-modes#eliminate-prompts-with-auto-mode) gibt Claude stattdessen die Hosts, die ein Befehl benötigt, [direkt am Befehl](#per-command-allowed-domains-in-auto-mode) an, damit der Klassifikator sie zusammen mit ihm prüft.

48 91

49 Befehle, die nicht in der Sandbox ausgeführt werden können, fallen auf den regulären Genehmigungsfluss zurück. Claude Code betitelt ihre Genehmigungseingabe mit „Bash-Befehl (unsandboxed)" statt „Bash-Befehl", damit Sie erkennen können, welche Befehle außerhalb der Sandbox ausgeführt wurden. Um diese Grenzen zu erweitern oder zu verengen, siehe [Sandboxing konfigurieren](#configure-sandboxing).92 Wie Sie erweitern oder einschränken, was die Sandbox zulässt, erfahren Sie unter [Sandboxing konfigurieren](#configure-sandboxing).

50 93

~~51 Wenn Sandbox-Befehle in einem Container mit `Operation not permitted` fehlschlagen, siehe den Bubblewrap-Eintrag unter [Fehlerbehebung](#troubleshooting).~~94 Wenn Befehle in der Sandbox innerhalb eines Containers mit `Operation not permitted` fehlschlagen, lesen Sie den Bubblewrap-Eintrag unter [Fehlerbehebung](#troubleshooting).

52 </Step>95 </Step>

53</Steps>96</Steps>

54 97

55Wenn Sie einen Modus im Panel auswählen, speichert Claude Code ihn in den lokalen Einstellungen Ihres Projekts unter `.claude/settings.local.json`, die für das aktuelle Projekt gelten. Claude Code fügt diese Datei zu Ihrer globalen Gitignore hinzu, wenn es dort eine Einstellung speichert. Um die Sandbox in allen Ihren Projekten zu aktivieren, setzen Sie [`sandbox.enabled`](/docs/de/settings-reference#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](#enforce-sandboxing-with-managed-settings).98Wenn Sie im Panel einen Modus auswählen, speichert Claude Code ihn in den lokalen Einstellungen Ihres Projekts unter `.claude/settings.local.json`, die für das aktuelle Projekt gelten. Claude Code fügt diese Datei Ihrer globalen gitignore hinzu, wenn es dort eine Einstellung speichert. Um die Sandbox für alle Ihre Projekte zu aktivieren, setzen Sie [`sandbox.enabled`](/docs/de/settings-reference#sandbox-enabled) in Ihren Benutzereinstellungen unter `~/.claude/settings.json` auf `true`. Um das Sandboxing für alle Entwickler einer Organisation durchzusetzen, verwenden Sie [verwaltete Einstellungen](#enforce-sandboxing-with-managed-settings).

56 99

57Um die Sandbox für eine Sitzung zu ändern, ohne in eine Einstellungsdatei zu schreiben, starten Sie Claude Code mit [`--settings`](/docs/de/settings#change-a-setting-for-one-session). Beispielsweise startet dieser Befehl eine Sandbox-Sitzung, in der Claude einen blockierten Befehl nicht außerhalb der Sandbox erneut versuchen kann:100Um die Sandbox für eine einzelne Sitzung zu ändern, ohne in eine Einstellungsdatei zu schreiben, starten Sie Claude Code mit [`--settings`](/docs/de/settings#change-a-setting-for-one-session). Dieser Befehl startet beispielsweise eine Sitzung mit Sandbox, in der Claude einen blockierten Befehl nicht außerhalb der Sandbox erneut versuchen kann:

58 101

59```bash theme={null}102```bash theme={null}

60claude --settings '{"sandbox": {"enabled": true, "allowUnsandboxedCommands": false}}'103claude --settings '{"sandbox": {"enabled": true, "allowUnsandboxedCommands": false}}'

61```104```

62 105

63<Warning>106<Warning>

64 Standardmäßig zeigt Claude Code eine Warnung an und führt Befehle ohne Sandboxing aus, wenn die Sandbox nicht gestartet werden kann, da Abhängigkeiten fehlen oder die Plattform nicht unterstützt wird. Um dies stattdessen zu einem Hard Failure zu machen, setzen Sie [`sandbox.failIfUnavailable`](/docs/de/settings-reference#sandbox-failifunavailable) auf `true`. Dies ist für verwaltete Bereitstellungen vorgesehen, die Sandboxing als Sicherheits-Gate erfordern.107 Wenn die Sandbox nicht starten kann, weil eine Abhängigkeit fehlt oder die Plattform nicht unterstützt wird, führt Claude Code Befehle standardmäßig ohne Sandboxing aus. Damit Claude Code stattdessen beim Start beendet wird, setzen Sie [`sandbox.failIfUnavailable`](/docs/de/settings-reference#sandbox-failifunavailable) auf `true`. Verwaltete Bereitstellungen, die Sandboxing als Sicherheitsvoraussetzung verlangen, können diese Einstellung verwenden.

65</Warning>108</Warning>

66 109

110<h3 id="confirm-commands-run-inside-the-sandbox">

111 Prüfen, ob Befehle in der Sandbox ausgeführt werden

112</h3>

113

114Um zu prüfen, ob die Sandbox funktioniert, bitten Sie Claude, jede Zeile der Tabelle auszuführen. Was Sie an der [`!`-Eingabeaufforderung](#what-runs-outside-the-sandbox) eingeben, wird in der Regel außerhalb der Sandbox ausgeführt, daher testet es die Sandbox nicht, wenn Sie eine Zeile selbst eingeben.

115

116| Befehl | Ergebnis innerhalb der Sandbox |

117| :- | :- |

118| `touch ~/sandbox-probe` | Schlägt unter macOS mit `Operation not permitted` fehl, unter Linux und WSL2 mit `Read-only file system` |

119| `curl --noproxy '*' https://example.com` | Schlägt mit `Could not resolve host` fehl, da der Befehl keine Route am Sandbox-Proxy vorbei hat |

120

121Wenn Claude anbietet, einen fehlgeschlagenen Befehl außerhalb der Sandbox erneut zu versuchen, lehnen Sie den Wiederholungsversuch ab. Wenn `touch` erfolgreich ist und Ihr Home-Verzeichnis nicht zu den Verzeichnissen gehört, in die Befehle in der Sandbox schreiben dürfen, löschen Sie `~/sandbox-probe`. Führen Sie dann `/sandbox` aus, um zu prüfen, ob die Sandbox aktiviert ist und ihre Abhängigkeiten installiert sind.

122

67<h3 id="set-up-linux-and-wsl2">123<h3 id="set-up-linux-and-wsl2">

68 Linux und WSL2 einrichten124 Linux und WSL2 einrichten

69</h3>125</h3>

70 126

~~71Auf Linux und WSL2 basiert die Sandbox auf zwei Paketen:~~127Unter Linux und WSL2 benötigt die Sandbox diese Pakete:

72 128

~~73* [`bubblewrap`](https://github.com/containers/bubblewrap): das unprivilegierte Sandboxing-Tool, das Dateisystem-Isolation erzwingt~~129* [`bubblewrap`](https://github.com/containers/bubblewrap): das unprivilegierte Sandboxing-Tool, das die Dateisystemisolation durchsetzt

~~74* [`socat`](http://www.dest-unreach.org/socat/): das Relay, das verwendet wird, um Netzwerk-Datenverkehr durch den Sandbox-Proxy zu leiten~~130* [`socat`](http://www.dest-unreach.org/socat/): das Relay, über das der Netzwerkverkehr durch den Sandbox-Proxy geleitet wird

75 131

~~76Installieren Sie diese mit dem Paketmanager Ihrer Distribution:~~132Installieren Sie sie mit dem Paketmanager Ihrer Distribution:

77 133

78<Tabs>134<Tabs>

79 <Tab title="Ubuntu/Debian">135 <Tab title="Ubuntu/Debian">

89 </Tab>145 </Tab>

90</Tabs>146</Tabs>

91 147

92Wenn eine Abhängigkeit fehlt, listet die Registerkarte „Dependencies" in `/sandbox` auf, welche von `ripgrep`, `bubblewrap`, `socat` und dem Seccomp-Filter Ihre Plattform nicht hat. Wenn Sie die Registerkarte nach der Installation und dem Neustart von Claude Code nicht sehen, sind alle Abhängigkeiten vorhanden.148Wenn eine Abhängigkeit fehlt, listet der Tab „Dependencies“ in `/sandbox` auf, welche von `ripgrep`, `bubblewrap`, `socat` und dem seccomp-Filter auf Ihrer Plattform fehlen. Wenn Sie den Tab nach der Installation und einem Neustart von Claude Code nicht sehen, sind alle Abhängigkeiten vorhanden.

93 149

94Ripgrep 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.150Ripgrep ist in der nativen Claude Code-Binärdatei enthalten. Der seccomp-Filter ist optional und ergänzt das Blockieren von Unix-Domain-Sockets. Installieren Sie ihn mit `npm install -g @anthropic-ai/sandbox-runtime`, falls er fehlt.

95 151

96Wenn eine erforderliche Abhängigkeit fehlt, ist die Registerkarte „Dependencies" die einzige angezeigte Registerkarte, bis Sie sie installieren. Wenn nur der optionale Seccomp-Filter fehlt, wird die Registerkarte „Dependencies" neben den anderen Registerkarten angezeigt. Die Abhängigkeitsprüfung läuft beim Start, daher starten Sie Claude Code nach der Installation von Paketen neu, damit `/sandbox` diese erkennt.152Wenn eine erforderliche Abhängigkeit fehlt, ist der Tab „Dependencies“ der einzige angezeigte Tab, bis Sie sie installieren. Wenn nur der optionale seccomp-Filter fehlt, erscheint der Tab „Dependencies“ neben den anderen Tabs. Die Abhängigkeitsprüfung läuft beim Start, starten Sie Claude Code daher nach der Installation von Paketen neu, damit `/sandbox` sie erkennt.

97 153

98<AccordionGroup>154<AccordionGroup>

~~99 <Accordion title="Ubuntu 24.04 und später: Erlauben Sie bubblewrap, Benutzer-Namespaces zu erstellen">~~155 <Accordion title="Ubuntu 24.04 und neuer: bubblewrap das Erstellen von User Namespaces erlauben">

100 Auf Ubuntu 24.04 und später verhindert die Standard-AppArmor-Richtlinie, dass bubblewrap die Benutzer-Namespaces erstellt, die es für die Isolation benötigt.156 Unter Ubuntu 24.04 und neuer verhindert die standardmäßige AppArmor-Richtlinie, dass bubblewrap die User Namespaces erstellt, die es für die Isolation benötigt.

101 157

102 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 Befehl `0` zurückgibt, überspringen Sie diesen Schritt. Wenn er einen `No such file or directory`-Fehler ausgibt, existiert der Schlüssel nicht und Sie können diesen Schritt überspringen. Wenn er `1` zurückgibt, fügen Sie ein AppArmor-Profil hinzu, das `bwrap` diese Fähigkeit gewährt:158 Um zu prüfen, ob Ihre Umgebung diese Einschränkung durchsetzt, auch innerhalb von WSL2, führen Sie `sysctl kernel.apparmor_restrict_unprivileged_userns` aus. Wenn der Befehl `0` zurückgibt, überspringen Sie diesen Schritt. Wenn er einen `No such file or directory`-Fehler ausgibt, existiert der Schlüssel nicht, und Sie können diesen Schritt überspringen. Wenn er `1` zurückgibt, fügen Sie ein AppArmor-Profil hinzu, das `bwrap` diese Fähigkeit gewährt:

103 159

104 ```bash theme={null}160 ```bash theme={null}

105 sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'161 sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'

113 EOF169 EOF

114 ```170 ```

115 171

116 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:172 Das Profil gilt nur für `bwrap` selbst, nicht für die Befehle, die es innerhalb der Sandbox ausführt. Laden Sie AppArmor neu, um es anzuwenden:

117 173

118 ```bash theme={null}174 ```bash theme={null}

119 sudo systemctl reload apparmor175 sudo systemctl reload apparmor

120 ```176 ```

121 </Accordion>177 </Accordion>

122 178

123 <Accordion title="WSL2-Hinweise">179 <Accordion title="Hinweise zu WSL2">

124 Überprüfen Sie Ihre WSL-Version mit `wsl -l -v` aus PowerShell. Wenn Sie `Sandboxing requires WSL2` sehen, läuft Ihre Distribution auf WSL1. Aktualisieren Sie sie auf WSL2 oder führen Sie Claude Code ohne Sandboxing aus.180 Prüfen Sie Ihre WSL-Version mit `wsl -l -v` in PowerShell. Wenn Sie `Sandboxing requires WSL2` sehen, läuft Ihre Distribution unter WSL1. Aktualisieren Sie sie auf WSL2 oder führen Sie Claude Code ohne Sandboxing aus.

125 181

126 Auf WSL2 übergibt WSL den Start einer Windows-Binärdatei wie `cmd.exe`, `powershell.exe` oder etwas unter `/mnt/c/` über einen Unix-Socket an den Windows-Host, daher folgt, ob ein Sandbox-Befehl einen starten kann, den [Unix-Socket-Einstellungen](/docs/de/settings-reference#sandbox-network-allowunixsockets) der Sandbox: Der optionale Seccomp-Filter muss installiert sein, um den Socket überhaupt zu blockieren. Um diese Starts zu erlauben, setzen Sie `allowAllUnixSockets`; um sie vollständig aus der Sandbox zu halten, fügen Sie den Befehl zu [`excludedCommands`](/docs/de/settings-reference#sandbox-excludedcommands) hinzu.182 Unter WSL2 übergibt WSL den Start einer Windows-Binärdatei wie `cmd.exe`, `powershell.exe` oder von allem unter `/mnt/c/` über einen Unix-Socket an den Windows-Host. Ob ein Befehl in der Sandbox eine solche Datei starten kann, richtet sich daher nach den [Unix-Socket-Einstellungen](/docs/de/settings-reference#sandbox-network-allowunixsockets) der Sandbox: Der optionale seccomp-Filter muss installiert sein, damit der Socket überhaupt blockiert wird. Um diese Starts zu erlauben, setzen Sie `allowAllUnixSockets`, wodurch jeder Unix-Socket für Befehle in der Sandbox geöffnet wird.

127 </Accordion>183 </Accordion>

128</AccordionGroup>184</AccordionGroup>

129 185

131 Sandbox-Modi187 Sandbox-Modi

132</h3>188</h3>

133 189

134Claude Code bietet zwei Sandbox-Modi. In beiden 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.190Claude Code bietet zwei Sandbox-Modi. In beiden setzt die Sandbox dieselben Dateisystem- und Netzwerkeinschränkungen durch; der Unterschied besteht nur darin, ob Befehle in der Sandbox automatisch genehmigt werden oder eine ausdrückliche Berechtigung erfordern.

135 191

136<h4 id="auto-allow-mode">192<h4 id="auto-allow-mode">

137 Auto-Allow-Modus193 Auto-Allow-Modus

138</h4>194</h4>

139 195

140Wenn ein Befehl in der Sandbox ausgeführt werden kann, führt Claude Code ihn in der Sandbox aus und genehmigt ihn automatisch, ohne Ihre Genehmigung zu fragen. 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](/docs/de/permissions) überprüft und jeden Befehl, den diese Regeln nicht bereits zulassen, mit einer Eingabeaufforderung im Manual-Modus blockiert.196Claude Code genehmigt einen Befehl automatisch und ohne Nachfrage, wenn er innerhalb der Sandbox ausgeführt wird. Ein Befehl durchläuft den regulären [Berechtigungsablauf](/docs/de/permissions), wenn er außerhalb der Sandbox ausgeführt wird, weil er auf [`excludedCommands`](#run-commands-outside-the-sandbox-with-excludedcommands) passt oder weil Claude [ihn ohne Sandbox erneut versucht](#the-unsandboxed-retry-escape-hatch).

197

198Ein Befehl in der Sandbox, der eine Verbindung zu einem Host herstellt, den Sie nicht erlaubt haben, bleibt in der Sandbox. Unter [Hosts außerhalb Ihrer erlaubten Domains](#hosts-outside-your-allowed-domains) erfahren Sie, wer entscheidet, ob die Verbindung zustande kommt.

141 199

142Selbst im Auto-Allow-Modus gelten folgende Punkte:200Auch im Auto-Allow-Modus gilt weiterhin Folgendes:

143 201

144* Explizite [Deny-Regeln](/docs/de/permissions) werden immer respektiert202* Ausdrückliche [Verweigerungsregeln](/docs/de/permissions) werden immer beachtet

145* `rm`- oder `rmdir`-Befehle, die auf einen [kritischen Pfad](/docs/de/permission-modes#critical-paths) abzielen, durchlaufen immer noch den regulären Genehmigungsfluss203* `rm`- oder `rmdir`-Befehle, die auf einen [kritischen Pfad](/docs/de/permission-modes#critical-paths) zielen, durchlaufen weiterhin den regulären Berechtigungsablauf

146* Inhaltsgebundene [Ask-Regeln](/docs/de/permissions) wie `Bash(git push *)` erzwingen immer noch eine Eingabeaufforderung, auch für Sandbox-Befehle204* Inhaltsbezogene [Nachfrageregeln](/docs/de/permissions) wie `Bash(git push *)` erzwingen weiterhin eine Nachfrage, auch für Befehle in der Sandbox

147* 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. Im [Plan-Modus](/docs/de/permission-modes#analyze-before-you-edit-with-plan-mode) wird die Regel nicht übersprungen: Sie fordert auch für Sandbox-Befehle auf, einschließlich schreibgeschützter. Vor v2.1.212 galt das Überspringen auch im Plan-Modus205* Eine einfache `Bash`-Nachfrageregel oder die gleichwertige Form `Bash(*)` wird für Befehle, die in der Sandbox ausgeführt werden, übersprungen; sie gilt weiterhin für Befehle, die auf den regulären Berechtigungsablauf zurückfallen. Im [Plan-Modus](/docs/de/permission-modes#analyze-before-you-edit-with-plan-mode) wird die Regel nicht übersprungen: Sie fragt auch bei Befehlen in der Sandbox nach, einschließlich nur lesender Befehle. Vor v2.1.212 galt das Überspringen auch im Plan-Modus

148 206

149<Info>207<Info>

150 Der Auto-Allow-Modus funktioniert unabhängig von Ihrer Genehmigungsmodus-Einstellung, mit drei Ausnahmen: [Plan-Modus](/docs/de/permission-modes#analyze-before-you-edit-with-plan-mode), ein Auto-Modus-Befehl, der [pro-Befehl zulässige Domains](#per-command-allowed-domains-in-auto-mode) trägt, und [serverseitige Klassifizierer-Überprüfung](/docs/de/permission-modes#how-the-classifier-evaluates-actions) von Sandbox-Befehlen im Auto-Modus. Selbst wenn Sie sich nicht im „Bearbeitungen akzeptieren"-Modus befinden, werden Sandbox-Bash-Befehle automatisch ausgeführt, wenn Auto-Allow aktiviert ist. Dies bedeutet, dass Bash-Befehle, die Dateien innerhalb der Sandbox-Grenzen ändern, ohne Eingabeaufforderung ausgeführt werden, auch im Manual-Modus, wo die Datei-Bearbeitungs-Tools eine Eingabeaufforderung erfordern würden.208 Der Auto-Allow-Modus funktioniert unabhängig von Ihrer Einstellung für den Berechtigungsmodus, mit drei Ausnahmen: dem [Plan-Modus](/docs/de/permission-modes#analyze-before-you-edit-with-plan-mode), einem Befehl im Auto-Modus mit [befehlsspezifisch erlaubten Domains](#per-command-allowed-domains-in-auto-mode) und der [serverseitigen Prüfung durch den Klassifikator](/docs/de/permission-modes#how-the-classifier-evaluates-actions) für Befehle in der Sandbox im Auto-Modus. Auch wenn Sie sich nicht im „accept edits“-Modus befinden, werden Bash-Befehle in der Sandbox automatisch ausgeführt, wenn Auto-Allow aktiviert ist. Das bedeutet, dass Bash-Befehle, die Dateien innerhalb der Sandbox-Grenzen ändern, ohne Nachfrage ausgeführt werden, selbst im Manual-Modus, in dem die Tools zur Dateibearbeitung nachfragen würden.

151 209

152 Im Plan-Modus erweitert Auto-Allow die Genehmigungen nicht; siehe [Plan-Modus](/docs/de/permission-modes#analyze-before-you-edit-with-plan-mode) für die Verwaltung von Befehlen durch Claude Code während der Planung. Vor v2.1.212 führte Auto-Allow Sandbox-Befehle auch im Plan-Modus ohne Eingabeaufforderung aus.210 Im Plan-Modus erweitert Auto-Allow die Genehmigungen nicht; unter [Plan-Modus](/docs/de/permission-modes#analyze-before-you-edit-with-plan-mode) erfahren Sie, wie Claude Code Befehle während der Planung kontrolliert. Vor v2.1.212 führte Auto-Allow Befehle in der Sandbox auch im Plan-Modus ohne Nachfrage aus.

153</Info>211</Info>

154 212

155<h4 id="regular-permissions-mode">213<h4 id="regular-permissions-mode">

156 Regulärer Genehmigungsmodus214 Modus für reguläre Berechtigungen

157</h4>215</h4>

158 216

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

160 218

161<h4 id="the-unsandboxed-retry-escape-hatch">219<h4 id="the-unsandboxed-retry-escape-hatch">

162 Die Fluchtluke für unsandboxed-Wiederversuche220 Der Ausweg über den Wiederholungsversuch ohne Sandbox

163</h4>221</h4>

164 222

165Einige 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. Claude Code meldet Sandbox-Verstöße im Ergebnis des blockierten Befehls und nennt den Pfad oder Host, den die Sandbox verweigert hat, damit Claude sieht, was die Sandbox blockiert hat. Anstatt die Aufgabe fehlschlagen zu lassen oder Sie zu zwingen, Sandboxing auszuschalten, enthält Claude Code eine Fluchtluke: Claude analysiert den Verstoß und kann den Befehl mit dem Parameter `dangerouslyDisableSandbox` erneut versuchen.223Der Wiederholungsversuch ohne Sandbox ist ein Ausweg für Befehle, die innerhalb der Sandbox fehlschlagen, etwa Tools, die nicht mit ihr kompatibel sind. Wenn die Sandbox eine Netzwerkverbindung blockiert, nennt Claude Code den abgelehnten Host im Ergebnis des Befehls, sodass Claude sieht, was blockiert wurde. Claude analysiert den Fehler und versucht den Befehl möglicherweise mit dem Parameter `dangerouslyDisableSandbox` erneut.

166 224

167Der erneut versuchte Befehl läuft außerhalb der Sandbox, daher durchläuft er den regulären Genehmigungsfluss. Im Manual-Modus erhalten Sie eine Bestätigungseingabe. Im [Auto-Modus](/docs/de/permission-modes#eliminate-prompts-with-auto-mode) bewertet der Klassifizierer den zugrunde liegenden Befehl. Während [`permissions.blockReadsOutsideWorkingDirectories`](/docs/de/settings-reference#permissions-blockreadsoutsideworkingdirectories) aktiviert ist, fordert ein Wiederversuch, der Genehmigung benötigt, um außerhalb der Sandbox ausgeführt zu werden, Sie stattdessen auf. Um bei jedem unsandboxed-Wiederversuch auch im Auto-Modus aufgefordert zu werden, fügen Sie eine [Ask-Regel](/docs/de/permissions#match-by-input-parameter) für `Bash(dangerouslyDisableSandbox:true)` hinzu.225Der erneut versuchte Befehl wird ohne Sandbox ausgeführt. In einer interaktiven Terminal-Sitzung hängt es von Ihrem Berechtigungsmodus ab, wer ihn genehmigt:

168 226

169Sie können diese Fluchtluke deaktivieren, indem Sie `"allowUnsandboxedCommands": false` in Ihren [Sandbox-Einstellungen](/docs/de/settings-reference#sandbox-settings) setzen. Wenn die Fluchtluke deaktiviert ist, ignoriert Claude Code den Parameter `dangerouslyDisableSandbox`, und jeder Befehl, den Claude ausführt, muss in der Sandbox ausgeführt werden, es sei denn, Sie haben ihn in `excludedCommands` aufgelistet. Die Registerkarte `/sandbox` **Overrides** zeigt diese Einstellung als **Strict sandbox mode** an.227* **`bypassPermissions`-Modus**: Der Wiederholungsversuch wird ohne Nachfrage ausgeführt

228* **Manual-Modus und `acceptEdits`-Modus**: Sie erhalten eine Berechtigungsabfrage mit dem Titel „Bash command (unsandboxed)“

229* **[Auto-Modus](/docs/de/permission-modes#eliminate-prompts-with-auto-mode)**: Ein separates Klassifikator-Modell bewertet den zugrunde liegenden Befehl

230* **`dontAsk`-Modus**: Claude Code lehnt den Wiederholungsversuch ab

231* **Plan-Modus**: Siehe [wie Claude Code Befehle während der Planung kontrolliert](/docs/de/permission-modes#analyze-before-you-edit-with-plan-mode)

170 232

171Der Strict-Sandbox-Modus gilt für die Befehle, die Claude ausführt. Befehle, die Sie selbst an der [`!` Shell-Modus-Eingabeaufforderung](/docs/de/interactive-mode#shell-mode-with-prefix) eingeben, laufen außerhalb der Sandbox, es sei denn, die Sitzung ist eine dieser:233Diese Regeln und Einstellungen ändern, wer den Wiederholungsversuch genehmigt:

234

235* **Eine passende Erlaubnisregel**: Wenn eine Erlaubnisregel wie `Bash(curl *)` auf den Befehl passt, genehmigt sie auch den Wiederholungsversuch, sodass der Befehl ohne Nachfrage außerhalb der Sandbox ausgeführt wird

236* **Eine Nachfrageregel für den Parameter**: Fügen Sie eine [Nachfrageregel](/docs/de/permissions#match-by-input-parameter) für `Bash(dangerouslyDisableSandbox:true)` hinzu, damit bei Bash-Wiederholungsversuchen nachgefragt wird. Sie erhalten die Nachfrage auch im Auto-Modus und im `bypassPermissions`-Modus, und die Regel hat Vorrang vor einer passenden Erlaubnisregel

237* **[`permissions.blockReadsOutsideWorkingDirectories`](/docs/de/settings-reference#permissions-blockreadsoutsideworkingdirectories)**: Unter [Aktionen, die kein Modus automatisch genehmigt](/docs/de/permission-modes#actions-no-mode-auto-approves) erfahren Sie, bei welchen Wiederholungsversuchen nachgefragt wird, solange diese Einstellung aktiv ist

238

239<h4 id="turn-off-the-retry-with-strict-sandbox-mode">

240 Den Wiederholungsversuch mit dem strikten Sandbox-Modus deaktivieren

241</h4>

172 242

173* **Eine [Hintergrund-Sitzung](/docs/de/agent-view)**: Der Strict-Sandbox-Modus deckt auch Shell-Modus-Befehle ab243Sie können den Wiederholungsversuch ohne Sandbox deaktivieren, indem Sie in Ihren [Sandbox-Einstellungen](/docs/de/settings-reference#sandbox-settings) `"allowUnsandboxedCommands": false` setzen. Bei deaktiviertem Wiederholungsversuch ignoriert Claude Code den Parameter `dangerouslyDisableSandbox`. Solange die Sandbox läuft, werden die Befehle, die Claude ausführt, dann in der Sandbox ausgeführt, sofern sie nicht auf einen `excludedCommands`-Eintrag passen. Damit Claude Code keine Befehle ohne Sandbox ausführt, wenn die Sandbox nicht starten kann, setzen Sie zusätzlich [`failIfUnavailable`](/docs/de/settings-reference#sandbox-failifunavailable). Der Tab **Overrides** in `/sandbox` zeigt diese Einstellung als **Strict sandbox mode** an.

174* **Eine Linux-Sitzung mit [`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`](/docs/de/env-vars#variables) gesetzt**: Jeder Befehl wird in der Sandbox ausgeführt, einschließlich Shell-Modus-Befehle

175 244

176Vor v2.1.260 sandboxte der Strict-Sandbox-Modus Shell-Modus-Befehle in jeder Sitzung.245Ein `false` in Ihren Benutzereinstellungen, in `--settings` oder in verwalteten Einstellungen bleibt bestehen, auch wenn die Einstellungen eines Projekts `true` setzen. Ein `false` in Ihren Benutzereinstellungen macht die Sandbox nicht administratorpflichtig, sodass die übrigen Sandbox-Einstellungen eines Projekts weiterhin gelten. Vor v2.1.285 überschrieb ein `true` eines Projekts ein `false` in Ihren Benutzereinstellungen.

246

247Wenn Sie oder Ihr Administrator den Wiederholungsversuch in verwalteten Einstellungen oder mit dem Flag `--settings` deaktivieren, wird die Sandbox administratorpflichtig. Claude Code ignoriert dann die Einstellungen in den Dateien eines Repositorys, die die Sandbox lockern, einschließlich `excludedCommands`-Einträgen. Unter [Repository-Einstellungen bei einer administratorpflichtigen Sandbox](#repository-settings-under-an-admin-required-sandbox) sind sie aufgeführt.

248

249Der strikte Sandbox-Modus gilt für die Befehle, die Claude ausführt. Befehle, die Sie selbst an der Eingabeaufforderung des [`!`-Shell-Modus](/docs/de/interactive-mode#shell-mode-with-prefix) eingeben, werden außerhalb der Sandbox ausgeführt, es sei denn, die Sitzung ist eine der folgenden:

250

251* **Eine [Hintergrundsitzung](/docs/de/agent-view)**: Der strikte Sandbox-Modus umfasst auch Befehle im Shell-Modus

252* **Eine Linux-Sitzung, in der [`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`](/docs/de/env-vars#variables) gesetzt ist**: Jeder Befehl wird in der Sandbox ausgeführt, einschließlich Befehlen im Shell-Modus

253

254Vor v2.1.260 führte der strikte Sandbox-Modus Befehle im Shell-Modus in jeder Sitzung in der Sandbox aus.

177 255

178<h4 id="temporary-directories">256<h4 id="temporary-directories">

179 Temporäre Verzeichnisse257 Temporäre Verzeichnisse

180</h4>258</h4>

181 259

182Ein Temp-Verzeichnis pro Benutzer ist standardmäßig in der Sandbox beschreibbar, zusammen mit dem Arbeitsverzeichnis. Sofern Sie nicht [Dateisystem-Isolation deaktivieren](#disable-filesystem-isolation), setzt Claude Code `$TMPDIR` auf dieses Verzeichnis für Sandbox-Befehle, sodass Tools, die temporäre Dateien schreiben, ohne zusätzliche Konfiguration funktionieren.260Ein benutzerspezifisches temporäres Verzeichnis ist innerhalb der Sandbox standardmäßig beschreibbar, zusätzlich zum Arbeitsverzeichnis. Sofern Sie die [Dateisystemisolation nicht deaktivieren](#disable-filesystem-isolation), setzt Claude Code `$TMPDIR` für Befehle in der Sandbox auf dieses Verzeichnis, sodass Tools, die temporäre Dateien schreiben, ohne zusätzliche Konfiguration funktionieren.

183 261

184Unsandboxed-Befehle erben Ihr Shell-`$TMPDIR`, wenn es gesetzt ist, daher lösen Sandbox- und Unsandboxed-Befehle `$TMPDIR` in verschiedene Verzeichnisse auf, während Dateisystem-Isolation aktiviert ist. Wenn Ihre Shell `$TMPDIR` nicht gesetzt oder leer lässt, erhält ein Unsandboxed-Befehl, der auf `$TMPDIR` verweist, Ihre [`CLAUDE_CODE_TMPDIR`](/docs/de/env-vars)-Überschreibung oder das Temp-Verzeichnis des Betriebssystems, wenn Sie keine gesetzt haben oder die Überschreibung ein langer Pfad ist, damit die Variable nicht zu einer leeren Zeichenkette expandiert. Um temporäre Dateien zwischen den beiden zu übergeben, schreiben Sie sie stattdessen unter das Arbeitsverzeichnis.262Befehle außerhalb der Sandbox übernehmen das `$TMPDIR` Ihrer Shell, sofern es gesetzt ist. Solange die Dateisystemisolation aktiv ist, lösen Befehle innerhalb und außerhalb der Sandbox `$TMPDIR` daher in unterschiedliche Verzeichnisse auf. Wenn Ihre Shell `$TMPDIR` nicht setzt oder leer lässt, erhält ein Befehl außerhalb der Sandbox, der auf `$TMPDIR` verweist, Ihre Überschreibung [`CLAUDE_CODE_TMPDIR`](/docs/de/env-vars) oder das temporäre Verzeichnis des Betriebssystems, wenn Sie keine festgelegt haben oder die Überschreibung ein langer Pfad ist, sodass die Variable nicht zu einer leeren Zeichenfolge expandiert wird. Um temporäre Dateien zwischen beiden auszutauschen, schreiben Sie sie stattdessen unterhalb des Arbeitsverzeichnisses.

185 263

186<h2 id="configure-sandboxing">264<h2 id="configure-sandboxing">

187 Sandboxing konfigurieren265 Sandboxing konfigurieren

188</h2>266</h2>

189 267

190Passen Sie das Sandbox-Verhalten durch Ihre `settings.json`-Datei an. Siehe [Einstellungen](/docs/de/settings-reference#sandbox-settings) für die vollständige Konfigurationsreferenz.268Passen Sie das Verhalten der Sandbox über Ihre `settings.json`-Datei an. Die vollständige Konfigurationsreferenz finden Sie unter [Einstellungen](/docs/de/settings-reference#sandbox-settings).

191 269

192Standardmäßig können Sandbox-Befehle in das aktuelle Arbeitsverzeichnis, das Sitzungs-Temp-Verzeichnis und alle [Verzeichnisse schreiben, die Sie hinzugefügt haben](/docs/de/permissions#additional-directories-grant-file-access-not-configuration) mit `--add-dir`, `/add-dir` oder `permissions.additionalDirectories`. 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:270Standardmäßig können in der Sandbox ausgeführte Befehle in das aktuelle Arbeitsverzeichnis, das benutzerspezifische temporäre Verzeichnis und alle [Verzeichnisse schreiben, die Sie](/docs/de/permissions#additional-directories-grant-file-access-not-configuration) mit `--add-dir`, `/add-dir` oder `permissions.additionalDirectories` hinzugefügt haben. Wenn Unterprozessbefehle wie `kubectl`, `terraform` oder `npm` außerhalb dieser Verzeichnisse schreiben müssen, verwenden Sie `sandbox.filesystem.allowWrite`, um Zugriff auf bestimmte Pfade zu gewähren:

193 271

194```json theme={null}272```json theme={null}

195{273{

202}280}

203```281```

204 282

205Diese 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.283Diese Pfade werden auf Betriebssystemebene durchgesetzt, sodass alle in der Sandbox ausgeführten Befehle einschließlich ihrer Kindprozesse sie beachten. Dies ist der empfohlene Ansatz, wenn ein Tool Schreibzugriff auf einen bestimmten Ort benötigt, anstatt das Tool mit `excludedCommands` vollständig von der Sandbox auszunehmen.

206 284

207Wenn Sie das gleiche Dateisystem-Array in mehreren [Einstellungs-Scopes](/docs/de/settings#settings-precedence) definieren, führt Claude Code diese zusammen und kombiniert Pfade aus jedem Scope, anstatt das Array eines Scopes durch das eines anderen zu ersetzen.285Wenn Sie dasselbe Dateisystem-Array in mehreren [Einstellungs-Geltungsbereichen](/docs/de/settings#settings-precedence) definieren, führt Claude Code diese zusammen und kombiniert die Pfade aus jedem Geltungsbereich, anstatt das Array eines Geltungsbereichs durch das eines anderen zu ersetzen.

208 286

209Wenn Sie eine Quelle mit [`--setting-sources`](/docs/de/cli-reference) in der CLI oder [`settingSources`](/docs/de/agent-sdk/claude-code-features#control-filesystem-settings-with-settingsources) im Agent SDK ausschließen, ignoriert Claude Code ihre `sandbox.filesystem`-Einträge, ihre `Edit`-Genehmigungsregeln und ihre `Read`-Ablehnungsregeln beim Aufbau der Sandbox-Konfiguration. Erfordert Claude Code v2.1.246 oder später.287Wenn Sie eine Quelle mit [`--setting-sources`](/docs/de/cli-reference) in der CLI oder mit [`settingSources`](/docs/de/agent-sdk/claude-code-features#control-filesystem-settings-with-settingsources) im Agent SDK ausschließen, ignoriert Claude Code beim Erstellen der Sandbox-Konfiguration deren `sandbox.filesystem`-Einträge, deren `Edit`-Berechtigungsregeln und deren `Read`-deny-Regeln. Erfordert Claude Code v2.1.246 oder höher.

210 288

211Wenn Sie diese Dateisystem-Listen während einer Sitzung bearbeiten, [wendet Claude Code die Änderung auf die laufende Sitzung an](/docs/de/settings#when-edits-take-effect), daher wird der nächste Sandbox-Befehl unter den neuen Pfaden ausgeführt.289Wenn Sie diese Dateisystemlisten während einer Sitzung bearbeiten, [wendet Claude Code die Änderung auf die laufende Sitzung an](/docs/de/settings#when-edits-take-effect), sodass der nächste in der Sandbox ausgeführte Befehl mit den neuen Pfaden läuft.

212 290

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

214 292

216| :- | :- | :- |294| :- | :- | :- |

217| `/` | Absoluter Pfad vom Dateisystem-Root | `/tmp/build` bleibt `/tmp/build` |295| `/` | Absoluter Pfad ab dem Dateisystem-Stammverzeichnis | `/tmp/build` bleibt `/tmp/build` |

218| `~/` | Relativ zum Home-Verzeichnis | `~/.kube` wird zu `$HOME/.kube` |296| `~/` | Relativ zum Home-Verzeichnis | `~/.kube` wird zu `$HOME/.kube` |

219| `./` oder kein Präfix | Relativ zum Projekt-Root für Projekt-Einstellungen oder zu `~/.claude` für Benutzer-Einstellungen | `./output` in `.claude/settings.json` wird zu `<project-root>/output` |297| `./` oder kein Präfix | Relativ zum Projektstammverzeichnis bei Projekteinstellungen oder zu `~/.claude` bei Benutzereinstellungen | `./output` in `.claude/settings.json` wird zu `<project-root>/output` aufgelöst |

220 298

221Diese Syntax unterscheidet sich von [Read- und Edit-Genehmigungsregeln](/docs/de/permissions#read-and-edit), die `//path` für absolut und `/path` für projekt-relativ verwenden. Sandbox-Dateisystem-Pfade verwenden Standard-Konventionen: `/tmp/build` ist absolut. Wie Claude Code einen nachgestellten Schrägstrich oder einen Platzhalter in diesen Pfaden behandelt, siehe [Sandbox-Pfad-Präfixe](/docs/de/settings-reference#sandbox-path-prefixes).299Diese Syntax unterscheidet sich von den [Berechtigungsregeln für Read und Edit](/docs/de/permissions#read-and-edit), die `//path` für absolute und `/path` für projektrelative Pfade verwenden. Dateisystempfade der Sandbox folgen den üblichen Konventionen: `/tmp/build` ist absolut. Wie Claude Code einen abschließenden Schrägstrich oder einen Platzhalter in diesen Pfaden behandelt, erfahren Sie unter [Sandbox-Pfadpräfixe](/docs/de/settings-reference#sandbox-path-prefixes).

222 300

223Sie 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. Wenn sich Lesevorgänge überlappen, gewinnt der spezifischere Pfad:301Sie können Schreib- oder Lesezugriff auch mit `sandbox.filesystem.denyWrite` und `sandbox.filesystem.denyRead` verweigern und bestimmte Pfade innerhalb eines gesperrten Bereichs mit `sandbox.filesystem.allowRead` wieder freigeben. Wenn sich Leseregeln überschneiden, gilt die Regel mit dem engeren Pfad:

224 302

225| Beispielregeln | Ergebnis |303| Beispielregeln | Ergebnis |

226| :- | :- |304| :- | :- |

227| `"denyRead": ["~/"]` mit `"allowRead": ["~/projects"]` | `~/projects` ist lesbar und der Rest des Home-Verzeichnisses bleibt blockiert. Die engere Zulassung öffnet diesen Teil der blockierten Region erneut |305| `"denyRead": ["~/"]` mit `"allowRead": ["~/projects"]` | `~/projects` ist lesbar, und der Rest des Home-Verzeichnisses bleibt gesperrt. Die engere allow-Regel öffnet diesen Teil des gesperrten Bereichs wieder |

228| `"allowRead": ["~/"]` mit `"denyRead": ["~/.env"]` | `~/.env` bleibt blockiert und der Rest des Home-Verzeichnisses ist lesbar. Eine genaue Blockierung gilt innerhalb einer breiteren Zulassung, daher kann eine breite Zulassung ein Geheimnis nicht stillschweigend erneut offenlegen |306| `"allowRead": ["~/"]` mit `"denyRead": ["~/.env"]` | `~/.env` bleibt gesperrt, und der Rest des Home-Verzeichnisses ist lesbar. Die deny-Regel gilt auch innerhalb einer weiter gefassten allow-Regel, sodass eine breite allow-Regel ein Geheimnis nicht unbemerkt wieder freilegen kann |

229| `"allowRead": ["~/"]` mit `"denyRead": ["~/**/.env"]` | Jede `.env` unter dem Home-Verzeichnis bleibt blockiert und der Rest ist lesbar. Ein [Platzhalter-Deny](/docs/de/settings-reference#sandbox-path-prefixes) gilt innerhalb einer breiteren Zulassung genauso wie ein genauer Pfad |307| `"allowRead": ["~/"]` mit `"denyRead": ["~/**/.env"]` | Jede `.env` unterhalb des Home-Verzeichnisses bleibt gesperrt, und der Rest ist lesbar. Eine [deny-Regel mit Platzhalter](/docs/de/settings-reference#sandbox-path-prefixes) gilt innerhalb einer weiter gefassten allow-Regel genauso wie ein exakter Pfad |

230 308

231Das 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 zum Projekt-Root aufgelöst wird, wenn die Konfiguration in Projekt-Einstellungen lebt:309Das folgende Beispiel sperrt das Lesen aus dem gesamten Home-Verzeichnis, erlaubt aber weiterhin das Lesen aus dem aktuellen Projekt. Legen Sie es in der `.claude/settings.json` Ihres Projekts ab, da der relative Pfad `.` nur dann zum Projektstammverzeichnis aufgelöst wird, wenn sich die Konfiguration in den Projekteinstellungen befindet:

232 310

233```json theme={null}311```json theme={null}

234{312{

242}320}

243```321```

244 322

245Wenn 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.323Würden Sie dieselbe Konfiguration in `~/.claude/settings.json` ablegen, würde `.` stattdessen zu `~/.claude` aufgelöst, und Projektdateien blieben durch die `denyRead`-Regel gesperrt.

324

325Um Befehlen in der Sandbox den Lesezugriff auf Home-Verzeichnisse und eingebundene Volumes zu verweigern und die Arbeitsverzeichnisse dennoch lesbar zu halten, setzen Sie [`permissions.blockReadsOutsideWorkingDirectories`](/docs/de/settings-reference#permissions-blockreadsoutsideworkingdirectories), anstatt Pfadregeln zu schreiben.

326

327<h3 id="run-commands-outside-the-sandbox-with-excludedcommands">

328 Befehle mit `excludedCommands` außerhalb der Sandbox ausführen

329</h3>

330

331Tragen Sie ein Befehlsmuster in [`sandbox.excludedCommands`](/docs/de/settings-reference#sandbox-excludedcommands) ein, um passende Befehle außerhalb der Sandbox auszuführen, also ohne Dateisystembeschränkungen und ohne Netzwerk-Proxy. Verwenden Sie dies für ein Tool, das innerhalb der Sandbox nicht funktioniert und dem Sie Ihren vollen Zugriff anvertrauen. Ein Tool, das nur ein weiteres Verzeichnis oder einen weiteren Host benötigt, funktioniert möglicherweise mit `allowWrite` oder `allowedDomains`, wodurch der Befehl in der Sandbox bleibt.

332

333Dieses Beispiel nimmt `docker compose`-Befehle aus der Sandbox heraus. Speichern Sie es in `~/.claude/settings.json`, um es auf alle Ihre Projekte anzuwenden:

334

335```json theme={null}

336{

337 "sandbox": {

338 "enabled": true,

339 "excludedCommands": ["docker compose *"]

340 }

341}

342```

343

344Claude Code prüft Ihre Einträge bei jedem Bash- und Monitor-Aufruf. Ein Aufruf ist die gesamte Befehlszeile, die Claude sendet, und kann mehrere Befehle verketten. Die folgenden Regeln entscheiden, ob ein Aufruf die Sandbox verlässt:

345

346* **Beenden Sie das Muster mit ` *`**: Einträge verwenden dieselbe Syntax wie eine `Bash(...)`-[Berechtigungsregel](/docs/de/permissions#permission-rule-syntax), bei der ein Muster ohne Platzhalter eine exakte Übereinstimmung ist. `docker` passt nur auf `docker` ohne Argumente. `docker *` passt auf `docker` mit oder ohne Argumente

347* **Jeder Befehl im Aufruf muss passen**: `npm ci && docker compose build` bleibt in der Sandbox, sofern kein anderer Eintrag `npm ci` abdeckt

348* **Claude Code gleicht den Text des Aufrufs ab**: Ein Skript oder `make`-Target, das intern `docker` aufruft, passt nicht, ebenso wenig `/usr/local/bin/docker`

349* **Manche Aufrufe bleiben in der Sandbox**: Eine Umleitung in eine Datei, ein `cd` oder eine Befehlssubstitution wie `$(...)` hält den gesamten Aufruf in der Sandbox. Der [Referenzeintrag](/docs/de/settings-reference#sandbox-excludedcommands) listet weitere Aufrufe auf, die in der Sandbox bleiben

350* **Wo Sie den Eintrag speichern, kann eine Rolle spielen**: Solange die Sandbox [vom Administrator vorgeschrieben](#repository-settings-under-an-admin-required-sandbox) ist, ignoriert Claude Code Einträge in `.claude/settings.json` und `.claude/settings.local.json`

351

352Ein ausgenommener Befehl durchläuft den regulären Berechtigungsablauf:

353

354* [Nur lesende Befehle](/docs/de/permissions#read-only-commands) und Befehle, die Ihre allow-Regeln abdecken, werden ohne Nachfrage ausgeführt

355* Im Auto-Modus prüft der Klassifikator andere ausgenommene Befehle

356* Im `bypassPermissions`-Modus wird ein ausgenommener Befehl ohne Nachfrage ausgeführt, sofern keine ask-Regel auf ihn passt

246 357

247Um Sandbox-Befehlen Lesezugriff auf Home-Verzeichnisse und eingebundene Volumes zu verweigern und gleichzeitig die Arbeitsverzeichnisse lesbar zu halten, setzen Sie stattdessen [`permissions.blockReadsOutsideWorkingDirectories`](/docs/de/settings-reference#permissions-blockreadsoutsideworkingdirectories).358Um zu bestätigen, dass ein Eintrag passt, wechseln Sie in den Manual-Modus und bitten Claude, einen passenden Befehl auszuführen, der etwas verändert, etwa `docker compose up -d`. Die Berechtigungsabfrage trägt den Titel „Bash command (unsandboxed)“.

359

360<Warning>

361 Ein ausgenommener Befehl wird mit Ihrem vollen Zugriff ausgeführt. Ein breiter Eintrag wie `docker *` deckt alles ab, was dieses Tool tun kann. Wenn Sie ein Muster schreiben, das einen Interpreter, ein Skript in Ihrem Arbeitsverzeichnis oder ein Tool abdeckt, das auf eine Datei dort zugreift, wie es `docker compose` mit seiner Compose-Datei tut, kann Claude diese Datei schreiben und sie anschließend außerhalb der Sandbox ausführen. Ein engeres Muster lässt weniger übrig, das Claude außerhalb der Sandbox ausführen kann.

362</Warning>

248 363

249<h3 id="disable-filesystem-isolation">364<h3 id="disable-filesystem-isolation">

250 Dateisystem-Isolation deaktivieren365 Dateisystem-Isolation deaktivieren

251</h3>366</h3>

252 367

253Setzen Sie `sandbox.filesystem.disabled` auf `true`, um die Dateisystem-Isolation zu überspringen und gleichzeitig die Netzwerk-Isolation beizubehalten. Das folgende Beispiel deaktiviert die Dateisystem-Isolation und behält eine Zulassungsliste von Netzwerk-Domains:368Setzen Sie `sandbox.filesystem.disabled` auf `true`, um die Dateisystem-Isolation zu überspringen und die Netzwerk-Isolation beizubehalten. Das folgende Beispiel schaltet die Dateisystem-Isolation aus und behält eine Allowlist von Netzwerkdomains bei:

254 369

255```json theme={null}370```json theme={null}

256{371{

266}381}

267```382```

268 383

269Die Sandbox hat zwei unabhängige Schichten: [Dateisystem-Isolation](#filesystem-isolation) steuert, welche Pfade Sandbox-Befehle lesen und schreiben können, und [Netzwerk-Isolation](#network-isolation) steuert, welche Domains sie erreichen können. Mit der Dateisystem-Schicht aus erhalten Sandbox-Befehle unbegrenzten Lese- und Schreibzugriff auf das Host-Dateisystem, während ihr Netzwerk-Ausgang auf Ihre zulässigen Domains beschränkt bleibt. Schalten Sie die Schicht aus, wenn Sie Sandboxing verwenden, um zu steuern, wo Befehle sich verbinden, anstatt was sie schreiben.384Die Sandbox besteht aus zwei unabhängigen Ebenen: Die [Dateisystem-Isolation](#filesystem-isolation) steuert, welche Pfade Befehle in der Sandbox lesen und schreiben können, und die [Netzwerk-Isolation](#network-isolation) steuert, welche Domains sie erreichen können. Ist die Dateisystemebene ausgeschaltet, erhalten Befehle in der Sandbox uneingeschränkten Lese- und Schreibzugriff auf das Dateisystem des Hosts, während ihr ausgehender Netzwerkverkehr auf Ihre erlaubten Domains beschränkt bleibt. Schalten Sie die Ebene aus, wenn Sie die Sandbox verwenden, um zu steuern, wohin Befehle sich verbinden, und nicht, was sie schreiben.

270 385

271Die Einstellung ist standardmäßig deaktiviert und gilt auf den Plattformen, auf denen die Sandbox ausgeführt wird: macOS, Linux und WSL2. Erfordert Claude Code v2.1.216 oder später.386Die Einstellung ist standardmäßig deaktiviert und gilt auf den Plattformen, auf denen die Sandbox läuft: macOS, Linux und WSL2. Erfordert Claude Code v2.1.216 oder höher.

272 387

273<Warning>388<Warning>

274 Mit deaktivierter Dateisystem-Isolation und automatisch zulässigen Befehlen kann ein Sandbox-Befehl Dateien schreiben, die später Befehle ausführen oder lesen, wie Shell-Startdateien, ausführbare Dateien auf `$PATH` oder `~/.claude/settings.json`, und diese verwenden, um seinen eigenen Zugriff beim nächsten Durchlauf zu erweitern. Setzen Sie `filesystem.disabled` auf `true` nur für Workloads, denen Sie vertrauen, dass sie ihren eigenen Zugriff nicht eskalieren. Das Sperren von Netzwerk-Domains mit [`allowManagedDomainsOnly`](#keep-developers-from-widening-the-policy) verengt das Risiko, entfernt es aber nicht, da diese Sperre nur auf Befehle gilt, die in der Sandbox ausgeführt werden.389 Bei ausgeschalteter Dateisystem-Isolation und automatisch erlaubten Befehlen kann ein Befehl in der Sandbox Dateien schreiben, die spätere Befehle ausführen oder lesen, etwa Shell-Startdateien, ausführbare Dateien im `$PATH` oder `~/.claude/settings.json`, und diese nutzen, um beim nächsten Durchlauf seinen eigenen Zugriff zu erweitern. Setzen Sie `filesystem.disabled` nur dann auf `true`, wenn Sie den Workloads vertrauen, ihren eigenen Zugriff nicht auszuweiten. Das Sperren von Netzwerkdomains mit [`allowManagedDomainsOnly`](#keep-developers-from-widening-the-policy) verringert das Risiko, beseitigt es aber nicht, da diese Sperre nur für Befehle gilt, die innerhalb der Sandbox ausgeführt werden.

275</Warning>390</Warning>

276 391

277<h4 id="which-settings-can-disable-it">392<h4 id="which-settings-can-disable-it">

278 Welche Einstellungen können es deaktivieren393 Welche Einstellungen sie deaktivieren können

279</h4>394</h4>

280 395

281Da das Ausschalten der Dateisystem-Isolation erweitert, was Sandbox-Befehle tun können, berücksichtigt Claude Code `filesystem.disabled` nur aus diesen Einstellungsquellen:396Da das Ausschalten der Dateisystem-Isolation erweitert, was Befehle in der Sandbox tun können, berücksichtigt Claude Code `filesystem.disabled` nur aus diesen Einstellungsquellen:

282 397

283* Benutzer-Einstellungen, verwaltete Einstellungen und das `--settings` CLI-Flag können es setzen. Projekt-Einstellungen in `.claude/settings.json` und `.claude/settings.local.json` können nicht, daher kann ein ausgechecktes Projekt die Dateisystem-Isolation nicht ausschalten.398* Benutzereinstellungen, verwaltete Einstellungen und das CLI-Flag `--settings` können sie setzen. Projekteinstellungen in `.claude/settings.json` und `.claude/settings.local.json` können das nicht, sodass ein ausgechecktes Projekt die Dateisystem-Isolation nicht ausschalten kann.

284* Wenn verwaltete Einstellungen `sandbox.filesystem` überhaupt konfigurieren oder einen beliebigen `sandbox.credentials.files`-Eintrag mit `"mode": "deny"` auflisten, können nur verwaltete Einstellungen den Schlüssel setzen. Dies hält vom Administrator bereitgestellte Dateisystem-Einschränkungen in Kraft; um eine solche Bereitstellung zu lockern, setzen Sie `"disabled": true` in verwalteten Einstellungen.399* Wenn verwaltete Einstellungen `sandbox.filesystem` überhaupt konfigurieren oder einen `sandbox.credentials.files`-Eintrag mit `"mode": "deny"` enthalten, können nur verwaltete Einstellungen den Schlüssel setzen. So bleiben vom Administrator bereitgestellte Dateisystembeschränkungen in Kraft; um eine solche Bereitstellung zu lockern, setzen Sie `"disabled": true` in den verwalteten Einstellungen.

285* Wenn [`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`](/docs/de/env-vars) gesetzt ist, ignoriert Claude Code `filesystem.disabled` aus jeder Quelle, einschließlich verwalteter Einstellungen, und lässt die Dateisystem-Isolation eingeschaltet.400* Wenn [`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`](/docs/de/env-vars) gesetzt ist, ignoriert Claude Code `filesystem.disabled` aus jeder Quelle, einschließlich der verwalteten Einstellungen, und lässt die Dateisystem-Isolation eingeschaltet.

286 401

287Ob ein verwalteter `credentials.files`-Eintrag `filesystem.disabled` anheftet und den Schlüssel auf verwaltete Einstellungen sperrt, damit Entwickler die Dateisystem-Isolation nicht ausschalten können, hängt vom `mode` des Eintrags und davon ab, was mit dem Eintrag beim Start der Sandbox geschieht:402Ob ein verwalteter `credentials.files`-Eintrag `filesystem.disabled` festlegt, also den Schlüssel auf verwaltete Einstellungen beschränkt, sodass Entwickler die Dateisystem-Isolation nicht ausschalten können, hängt vom `mode` des Eintrags ab und davon, was mit dem Eintrag beim Start der Sandbox geschieht:

288 403

290| - | - | - |405| - | - | - |

291| `"mode": "deny"` | Ja | Nichts: der Lesblock ist Teil der Dateisystem-Schicht |406| `"mode": "deny"` | Ja | Nichts: Die Lesesperre ist Teil der Dateisystemebene |

292| `"mode": "mask"`, angewendet als Maske | Nein | Maskierung selbst: die [Sentinel-Kopie und der Proxy](#mask-credential-files) auf Linux und WSL2, die Sandbox-eigenen Lesevorgänge auf macOS |407| `"mode": "mask"`, als Maske angewendet | Nein | Die Maskierung selbst: die [Sentinel-Kopie und der Proxy](#mask-credential-files) unter Linux und WSL2, die eigenen Leseregeln der Sandbox unter macOS |

293| `"mode": "mask"`, [auf `deny` zurückgefallen](#mask-credential-files) beim Setup | Nein | Nichts, wie `deny`. Führen Sie einen Pfad auf, der nicht maskiert werden kann, wie ein Verzeichnis, als expliziten `deny`-Eintrag auf, der den Schlüssel anheftet |408| `"mode": "mask"`, beim Einrichten [auf `deny` zurückgefallen](#mask-credential-files) | Nein | Nichts, wie bei `deny`. Tragen Sie einen Pfad, der nicht maskiert werden kann, etwa ein Verzeichnis, als expliziten `deny`-Eintrag ein, der den Schlüssel festlegt |

294| `"mode": "mask"`, [durch Validierung zu `deny` herabgestuft](/docs/de/managed-settings#invalid-entries-in-managed-settings) | Ja, wie ein expliziter `deny` | Nichts, wie `deny` |409| `"mode": "mask"`, [durch die Validierung zu `deny` herabgestuft](/docs/de/managed-settings#invalid-entries-in-managed-settings) | Ja, wie ein expliziter `deny`-Eintrag | Nichts, wie bei `deny` |

295 410

296Ein Fallback tritt auf, wenn die Sandbox startet, nachdem Claude Code die Einstellungen bereits gelesen hat, auf denen die Anheftungsprüfung läuft, daher heftet ein zurückgefallener Eintrag niemals an. Validierung schreibt einen ungültigen Eintrag zu `deny` um, während Einstellungen geladen werden, daher heftet ein herabgestufter Eintrag wie einer an, den Sie als `deny` geschrieben haben.411Ein Fallback erfolgt beim Start der Sandbox, nachdem Claude Code die Einstellungen, auf denen die Prüfung der Festlegung basiert, bereits gelesen hat. Ein zurückgefallener Eintrag legt den Schlüssel daher nie fest. Die Validierung schreibt einen ungültigen Eintrag beim Laden der Einstellungen in `deny` um, sodass ein herabgestufter Eintrag den Schlüssel genauso festlegt wie einer, den Sie als `deny` geschrieben haben.

297 412

298<h4 id="what-changes-when-filesystem-isolation-is-off">413<h4 id="what-changes-when-filesystem-isolation-is-off">

299 Was ändert sich, wenn Dateisystem-Isolation aus ist414 Was sich bei ausgeschalteter Dateisystem-Isolation ändert

300</h4>415</h4>

301 416

302Setzen von `filesystem.disabled` hebt die Schutzmaßnahmen auf, die die Dateisystem-Schicht selbst durchsetzt. Schutzmaßnahmen, die andere Schichten durchsetzen, bleiben angewendet:417Das Setzen von `filesystem.disabled` hebt die Schutzmaßnahmen auf, die die Dateisystemebene selbst durchsetzt. Schutzmaßnahmen, die andere Ebenen durchsetzen, gelten weiterhin:

303 418

304| Schutz | Mit deaktivierter Dateisystem-Isolation |419| Schutzmaßnahme | Bei ausgeschalteter Dateisystem-Isolation |

305| - | - |420| - | - |

306| `filesystem.denyRead` und [`credentials.files`](#protect-credentials) `deny` Lesevorgänge blockieren | Nicht durchgesetzt. Die Dateisystem-Schicht wendet beide an |421| `filesystem.denyRead` und `deny`-Lesesperren aus [`credentials.files`](#protect-credentials) | Nicht durchgesetzt. Die Dateisystemebene wendet beide an |

307| `credentials.envVars` `deny` und `mask` Einträge | Durchgesetzt. Umgebungsvariablen-Scrubbing ist unabhängig von der Dateisystem-Schicht |422| `deny`- und `mask`-Einträge in `credentials.envVars` | Durchgesetzt. Das Bereinigen von Umgebungsvariablen ist unabhängig von der Dateisystemebene |

308| [`credentials.files` `mask` Einträge](#mask-credential-files) angewendet als Masken | Durchgesetzt: Maskierung ist unabhängig von der Dateisystem-Schicht. Ein Eintrag, der [auf `deny` zurückgefallen ist](#mask-credential-files), wird nicht durchgesetzt, wie jeder `deny`-Eintrag |423| [`mask`-Einträge in `credentials.files`](#mask-credential-files), die als Masken angewendet werden | Durchgesetzt: Die Maskierung ist unabhängig von der Dateisystemebene. Ein Eintrag, der [auf `deny` zurückgefallen](#mask-credential-files) ist, wird wie jeder `deny`-Eintrag nicht durchgesetzt |

309 424

310Zwei weitere Dinge ändern sich:425Zwei weitere Dinge ändern sich:

311 426

312* Sandbox-Befehle erben `$TMPDIR` Ihrer Shell anstelle des Sitzungs-Temp-Verzeichnisses, da jedes Temp-Verzeichnis beschreibbar ist und Claude Code Befehle nicht mehr zum Sitzungs-Temp-Verzeichnis umleitet.427* Befehle in der Sandbox übernehmen das `$TMPDIR` Ihrer Shell anstelle des benutzerspezifischen temporären Verzeichnisses, da jedes temporäre Verzeichnis beschreibbar ist und Claude Code Befehle nicht mehr auf das benutzerspezifische umleitet.

313 428

314 Auf Linux ist die Variable oft in der übergeordneten Shell nicht gesetzt. Das Bash-Tool-Leitfaden teilt Claude mit, Scratch-Verzeichnisse mit `mktemp -d` zu erstellen, anstatt sich auf `$TMPDIR` zu verlassen.429 Unter Linux ist die Variable in der übergeordneten Shell oft nicht gesetzt. Die Hinweise des Bash-Tools weisen Claude an, temporäre Arbeitsverzeichnisse mit `mktemp -d` zu erstellen, anstatt sich auf `$TMPDIR` zu verlassen.

315* [`autoAllowBashIfSandboxed`](/docs/de/settings-reference#sandbox-autoallowbashifsandboxed) hat immer noch den Standard `true`, daher laufen Sandbox-Befehle ohne Eingabeaufforderungen. Setzen Sie es auf `false`, um Eingabeaufforderungen für Sandbox-Befehle zu erhalten.430* [`autoAllowBashIfSandboxed`](/docs/de/settings-reference#sandbox-autoallowbashifsandboxed) ist weiterhin standardmäßig `true`, sodass Befehle in der Sandbox weiterhin ohne Nachfrage ausgeführt werden. Setzen Sie den Wert auf `false`, um bei Befehlen in der Sandbox nachfragen zu lassen.

316 431

317<h3 id="protect-credentials">432<h3 id="protect-credentials">

318 Anmeldedaten schützen433 Anmeldedaten schützen

319</h3>434</h3>

320 435

321Die Einstellung `sandbox.credentials` deklariert Anmeldedatendateien und Umgebungsvariablen, um sie vor Sandbox-Befehlen zu schützen. Jeder Eintrag benennt einen Dateipfad oder eine Umgebungsvariable und einen `mode`. Der dedizierte `credentials`-Block hält Anmeldedatenregeln zusammen und getrennt von allgemeinen Dateisystem-Regeln.436Die Einstellung `sandbox.credentials` legt Dateien mit Anmeldedaten und Umgebungsvariablen fest, die vor Befehlen in der Sandbox geschützt werden sollen. Jeder Eintrag benennt einen Dateipfad oder eine Umgebungsvariable sowie einen `mode`. Der eigene `credentials`-Block hält Regeln für Anmeldedaten zusammen und getrennt von allgemeinen Dateisystemregeln.

322 437

323Für Einträge mit `"mode": "deny"` werden Dateipfade für Lesevorgänge in der Sandbox blockiert, die gleiche Einschränkung, die `filesystem.denyRead` anwendet, und Umgebungsvariablen werden vor jedem Sandbox-Befehl deaktiviert. Der Dateischutz ist Teil der Dateisystem-Schicht, daher gilt er nicht, wenn Sie [Dateisystem-Isolation deaktivieren](#disable-filesystem-isolation); der Umgebungsvariablen-Schutz gilt immer noch.438Bei Einträgen mit `"mode": "deny"` wird für Dateipfade das Lesen innerhalb der Sandbox verweigert, dieselbe Einschränkung, die `filesystem.denyRead` anwendet, und Umgebungsvariablen werden vor jedem Befehl in der Sandbox entfernt. Der Dateischutz ist Teil der Dateisystemebene und gilt daher nicht, wenn Sie die [Dateisystem-Isolation deaktivieren](#disable-filesystem-isolation); der Schutz der Umgebungsvariablen gilt weiterhin.

324 439

325Das folgende Beispiel blockiert Lesevorgänge der AWS-Anmeldedatendatei und des SSH-Verzeichnisses und entfernt `GITHUB_TOKEN` und `NPM_TOKEN` aus der Umgebung von Sandbox-Befehlen:440Das folgende Beispiel sperrt das Lesen der AWS-Anmeldedatendatei und des SSH-Verzeichnisses und entfernt `GITHUB_TOKEN` und `NPM_TOKEN` aus der Umgebung von Befehlen in der Sandbox:

326 441

327```json theme={null}442```json theme={null}

328{443{

342}457}

343```458```

344 459

345Umgebungsvariablen-Einträge und Datei-Einträge akzeptieren auch `"mode": "mask"`, das unter [Anmeldedaten maskieren](#mask-credentials) beschrieben wird.460Einträge für Umgebungsvariablen und Dateien akzeptieren auch `"mode": "mask"`, beschrieben unter [Anmeldedaten maskieren](#mask-credentials).

346 461

347Dateipfade folgen den gleichen [Präfix-Regeln](/docs/de/settings-reference#sandbox-path-prefixes) wie `sandbox.filesystem.*`-Einstellungen.462Dateipfade folgen denselben [Präfixregeln](/docs/de/settings-reference#sandbox-path-prefixes) wie die `sandbox.filesystem.*`-Einstellungen.

348 463

349Claude Code führt die `deny`-Einträge aus jedem [Einstellungs-Scope](/docs/de/settings#settings-precedence) zusammen, den die Sitzung lädt. Ein `deny`-Eintrag engt den Zugriff nur ein, daher kann jeder Scope einen hinzufügen, aber keiner kann einen entfernen, den ein anderer Scope hinzugefügt hat.464Claude Code führt die `deny`-Einträge aus jedem [Einstellungs-Geltungsbereich](/docs/de/settings#settings-precedence) zusammen, den die Sitzung lädt. Ein `deny`-Eintrag schränkt den Zugriff immer nur ein, daher kann jeder Geltungsbereich einen hinzufügen, aber kein Geltungsbereich kann einen entfernen, den ein anderer hinzugefügt hat.

350 465

351Wenn Sie [eine Einstellungsquelle ausschließen](#configure-sandboxing):466Wenn Sie [eine Einstellungsquelle ausschließen](#configure-sandboxing):

352 467

353* **Projekt- oder lokale Einstellungen**: Claude Code wendet keine ihrer `credentials`-Einträge an. Erfordert Claude Code v2.1.246 oder später.468* **Projekt- oder lokale Einstellungen**: Claude Code wendet keinen ihrer `credentials`-Einträge an. Erfordert Claude Code v2.1.246 oder höher.

354* **Benutzer-Einstellungen**: Claude Code wendet immer noch die `deny`-Einträge in `~/.claude/settings.json` an und behält ihre [Datei-`mask`-Einträge](#mask-credential-files) als Einschränkungen, aber verwirft ihre [Umgebungsvariablen-`mask`-Einträge](#mask-environment-variables).469* **Benutzereinstellungen**: Claude Code wendet die `deny`-Einträge in `~/.claude/settings.json` weiterhin an und behält deren [`mask`-Einträge für Dateien](#mask-credential-files) als Einschränkungen bei, verwirft aber deren [`mask`-Einträge für Umgebungsvariablen](#mask-environment-variables).

355 470

356Es gibt keine integrierte Anmeldedaten-Ablehnungsliste, daher werden nur die Dateien und Variablen, die Sie auflisten, eingeschränkt.471Es gibt keine integrierte Denylist für Anmeldedaten, daher sind nur die Dateien und Variablen eingeschränkt, die Sie auflisten.

357 472

358`sandbox.credentials` betrifft nur Sandbox-Bash-Befehle. Um Anmeldedaten aus allen Subprozessen unabhängig von Sandboxing zu entfernen, setzen Sie [`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`](/docs/de/env-vars).473`sandbox.credentials` wirkt sich nur auf Bash-Befehle in der Sandbox aus. Um Anmeldedaten unabhängig vom Sandboxing aus allen Unterprozessen zu entfernen, setzen Sie [`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`](/docs/de/env-vars).

359 474

360<h3 id="mask-credentials">475<h3 id="mask-credentials">

361 Anmeldedaten maskieren476 Anmeldedaten maskieren

362</h3>477</h3>

363 478

364Maskierung geht weiter als ein `deny`-Eintrag unter [Anmeldedaten schützen](#protect-credentials). Anstatt eine Anmeldedaten zu blockieren, zeigt Claude Code Sandbox-Befehlen einen Platzhalter, den Sentinel, und der [Sandbox-Proxy](#network-isolation) tauscht den echten Wert bei ausgehenden Anfragen an Hosts aus, die Sie zulassen. Für Dateien ist die Substitution Linux- und WSL2-Verhalten; [macOS blockiert die Datei stattdessen](#mask-credential-files).479Die Maskierung geht weiter als ein `deny`-Eintrag unter [Anmeldedaten schützen](#protect-credentials). Anstatt Anmeldedaten zu sperren, zeigt Claude Code Befehlen in der Sandbox einen Platzhalter, den Sentinel, und der [Sandbox-Proxy](#network-isolation) setzt bei ausgehenden Anfragen an von Ihnen erlaubte Hosts den echten Wert ein. Bei Dateien ist die Ersetzung ein Verhalten unter Linux und WSL2; [macOS sperrt die Datei stattdessen](#mask-credential-files).

365 480

366<h4 id="mask-environment-variables">481<h4 id="mask-environment-variables">

367 Umgebungsvariablen maskieren482 Umgebungsvariablen maskieren

368</h4>483</h4>

369 484

370`"mode": "mask"` schützt eine Anmeldedaten, während die Tools, die sich damit authentifizieren, funktionieren. `deny` entfernt die Variable vollständig, was auch Tools bricht, die sie benötigen, wie `gh` oder `npm`. Erfordert Claude Code v2.1.199 oder später.485`"mode": "mask"` schützt Anmeldedaten und sorgt dafür, dass die Tools, die sich damit authentifizieren, weiterhin funktionieren. `deny` entfernt die Variable vollständig, wodurch auch Tools nicht mehr funktionieren, die sie benötigen, etwa `gh` oder `npm`. Erfordert Claude Code v2.1.199 oder höher.

371 486

372Mit `mask` sieht der Sandbox-Befehl einen pro-Sitzungs-Sentinel-Wert anstelle des echten. Jeder `mask`-Eintrag kann `injectHosts` auflisten, die Hosts, an die der echte Wert erreichen darf. Wenn eine Anfrage die Sandbox für einen von ihnen verlässt, ersetzt der [Sandbox-Proxy](#network-isolation) den Sentinel durch den echten Wert. Der Befehl und alles, das er protokolliert, hält niemals die echte Anmeldedaten, aber seine Anfragen authentifizieren sich immer noch.487Mit `mask` sieht der Befehl in der Sandbox einen sitzungsspezifischen Sentinel-Wert anstelle des echten Werts. Jeder `mask`-Eintrag kann `injectHosts` auflisten, die Hosts, die der echte Wert erreichen darf. Wenn eine Anfrage die Sandbox in Richtung eines dieser Hosts verlässt, ersetzt der [Sandbox-Proxy](#network-isolation) den Sentinel durch den echten Wert. Der Befehl und alles, was er protokolliert, enthalten nie die echten Anmeldedaten, aber seine Anfragen werden dennoch authentifiziert.

373 488

374Der Proxy ersetzt die Anmeldedaten in Anfrageinhalten, daher muss er diese sehen. Setzen Sie [`network.tlsTerminate`](/docs/de/settings-reference#sandbox-network-tlsterminate), damit der Proxy TLS selbst beendet.489Der Proxy ersetzt die Anmeldedaten innerhalb des Anfrageinhalts und muss diesen daher sehen können. Setzen Sie [`network.tlsTerminate`](/docs/de/settings-reference#sandbox-network-tlsterminate), damit der Proxy TLS selbst terminiert.

375 490

376Ohne ihn schlägt die Maskierung geschlossen fehl: Der Befehl sieht immer noch nur den Sentinel, aber der Sentinel erreicht den Server unverändert und die Authentifizierung schlägt fehl. Claude Code meldet diese Fehlkonfiguration beim Start.491Ohne diese Einstellung schlägt die Maskierung fehl, ohne etwas preiszugeben: Der Befehl sieht weiterhin nur den Sentinel, aber der Sentinel erreicht den Server unverändert, und die Authentifizierung schlägt fehl. Claude Code meldet diese Fehlkonfiguration beim Start.

377 492

378Die Substitution deckt Header und Anfragekörper ab. Anfragen, die sich mit einer Signatur authentifizieren, die von der Anmeldedaten abgeleitet ist, anstatt der Anmeldedaten selbst, benötigen eine Neusignierung beim Proxy; [AWS-Anfragen erneut signieren](#re-sign-aws-requests) behandelt, wie das für AWS funktioniert.493Die Ersetzung umfasst Header und Anfrage-Bodys. Anfragen, die sich mit einer aus den Anmeldedaten abgeleiteten Signatur statt mit den Anmeldedaten selbst authentifizieren, müssen am Proxy neu signiert werden; [AWS-Anfragen neu signieren](#re-sign-aws-requests) beschreibt, wie das bei AWS funktioniert.

379 494

380Der Proxy injiziert nur auf Verbindungen, die die [Domain-Zulassungsliste](#network-isolation) zulässt, daher muss jedes `injectHosts`-Ziel auch über `network.allowedDomains` erreichbar sein.495Der Proxy fügt Anmeldedaten nur bei Verbindungen ein, die die [Domain-Allowlist](#network-isolation) zulässt. Jedes `injectHosts`-Ziel muss daher auch über `network.allowedDomains` erreichbar sein.

381 496

382Das folgende Beispiel maskiert zwei Token. `GH_TOKEN` wird nur bei Anfragen an `api.github.com` ersetzt, während `NPM_TOKEN` keine `injectHosts` hat und bei Anfragen an jeden Host in `network.allowedDomains` ersetzt wird.497Das folgende Beispiel maskiert zwei Token. `GH_TOKEN` wird nur bei Anfragen an `api.github.com` ersetzt, während `NPM_TOKEN` keine `injectHosts` hat und bei Anfragen an jeden Host in `network.allowedDomains` ersetzt wird.

383 498

401 516

402<span id="ipv6-destinations-in-injecthosts" />Schreiben Sie ein IPv6-Ziel in den beiden Listen unterschiedlich, da jede Liste ihren eigenen Matcher hat:517<span id="ipv6-destinations-in-injecthosts" />Schreiben Sie ein IPv6-Ziel in den beiden Listen unterschiedlich, da jede Liste ihren eigenen Matcher hat:

403 518

404* **`network.allowedDomains`**: die [geklammerte Form, die Domain-Listen verwenden](#ipv6-addresses-in-domain-lists), wie `"[::1]"`. Der Proxy prüft diese Liste, um die Verbindung zuzulassen.519* **`network.allowedDomains`**: die [in Domainlisten verwendete Form mit eckigen Klammern](#ipv6-addresses-in-domain-lists), etwa `"[::1]"`. Der Proxy prüft diese Liste, um die Verbindung zuzulassen.

405* **`injectHosts`**: die bloße Adresse in ihrer kanonischen komprimierten Form, wie `"::1"` oder `"2001:db8::1"`. Der Proxy gleicht jeden Eintrag gegen die bloße Zieladresse der Verbindung ab und ignoriert Ports, daher passt eine geklammerte, Zone-ID- oder anders komprimierte Schreibweise niemals und der Proxy injiziert die Anmeldedaten dort niemals.520* **`injectHosts`**: die reine Adresse in ihrer kanonischen komprimierten Form, etwa `"::1"` oder `"2001:db8::1"`. Der Proxy gleicht jeden Eintrag mit der reinen Zieladresse der Verbindung ab und ignoriert dabei Ports. Eine Schreibweise mit eckigen Klammern, Zonen-ID oder anderer Komprimierung passt daher nie, und der Proxy fügt die Anmeldedaten dort nie ein.

406 521

407`claude doctor` kennzeichnet `injectHosts`-Einträge, die niemals passen können, mit der Warnung `Sandbox credential injectHosts entries can never match their destination`. Diese Prüfung erfordert Claude Code v2.1.229 oder später.522`claude doctor` kennzeichnet `injectHosts`-Einträge, die nie passen können, mit der Warnung `Sandbox credential injectHosts entries can never match their destination`. Diese Prüfung erfordert Claude Code v2.1.229 oder höher.

408 523

409Im Gegensatz zu `deny` autorisiert die Maskierung den Proxy, Ihre echte Anmeldedaten an die aufgelisteten Hosts zu senden, daher wird sie nur von Einstellungen berücksichtigt, die Sie oder Ihr Administrator kontrollieren: Benutzer-Einstellungen, verwaltete Einstellungen und das `--settings` CLI-Flag. Claude Code ignoriert `mask`-Einträge in der `.claude/settings.json` oder `.claude/settings.local.json` eines Repositorys. In diesen Dateien ignoriert es auch `network.tlsTerminate` und [`credentials.allowPlaintextInject`](/docs/de/settings-reference#sandbox-credentials-allowplaintextinject), die Einstellung, die dem Proxy erlaubt, Anmeldedaten in unverschlüsselte Anfragen zu injizieren. Wenn Sie [Benutzer-Einstellungen ausschließen](#configure-sandboxing), verwirft Claude Code die Umgebungsvariablen-`mask`-Einträge in `~/.claude/settings.json` auch.524Anders als `deny` autorisiert die Maskierung den Proxy, Ihre echten Anmeldedaten an die aufgelisteten Hosts zu senden. Claude Code berücksichtigt sie daher nur aus Einstellungen, die Sie oder Ihr Administrator kontrollieren: Benutzereinstellungen, verwaltete Einstellungen und das CLI-Flag `--settings`. Claude Code ignoriert `mask`-Einträge in der `.claude/settings.json` oder `.claude/settings.local.json` eines Repositorys. In diesen Dateien ignoriert es auch `network.tlsTerminate` und [`credentials.allowPlaintextInject`](/docs/de/settings-reference#sandbox-credentials-allowplaintextinject), die Einstellung, mit der der Proxy Anmeldedaten in unverschlüsselte Anfragen einfügen darf. Wenn Sie [Benutzereinstellungen ausschließen](#configure-sandboxing), verwirft Claude Code auch die `mask`-Einträge für Umgebungsvariablen in `~/.claude/settings.json`.

410 525

411Wenn Ihr Administrator `mask`-Einträge, `network.tlsTerminate` oder `credentials.allowPlaintextInject` über server-verwaltete Einstellungen bereitstellt, zählen sie als [Einstellungen, die Genehmigung benötigen](/docs/de/server-managed-settings#security-approval-dialogs).526Wenn Ihr Administrator `mask`-Einträge, `network.tlsTerminate` oder `credentials.allowPlaintextInject` über serververwaltete Einstellungen bereitstellt, zählen diese zu den [Einstellungen, die eine Genehmigung erfordern](/docs/de/server-managed-settings#security-approval-dialogs).

412 527

413Wenn die gleiche Variable mit `deny` in einem beliebigen Scope aufgelistet ist, hat `deny` Vorrang.528Wenn dieselbe Variable in einem beliebigen Geltungsbereich mit `deny` aufgeführt ist, hat `deny` Vorrang.

414 529

415Die Maskierung ersetzt standardmäßig den gesamten Wert der Variablen, was sich für einen bloßen Token eignet. Optionale Eintragsfelder, die Claude Code v2.1.224 oder später erfordern, behandeln Werte mit Struktur:530Die Maskierung ersetzt standardmäßig den gesamten Wert der Variable, was für ein einfaches Token geeignet ist. Optionale Eintragsfelder, die Claude Code v2.1.224 oder höher erfordern, verarbeiten strukturierte Werte:

416 531

417* `extract`: ein regulärer Ausdruck, den Claude Code über den Wert anwendet und nur den Text ersetzt, der von Gruppe 1 jedes Treffers erfasst wird, daher funktioniert ein Tool, das den Wert analysiert, wie eine `DATABASE_URL`-Verbindungszeichenfolge, immer noch in der Sandbox. Das Muster muss mindestens eine erfassende Gruppe enthalten.532* `extract`: ein regulärer Ausdruck, den Claude Code auf den gesamten Wert anwendet, wobei nur der von Gruppe 1 jeder Übereinstimmung erfasste Text ersetzt wird. So funktioniert ein Tool, das den Wert parst, etwa bei einem `DATABASE_URL`-Verbindungsstring, auch innerhalb der Sandbox weiter. Das Muster muss mindestens eine Erfassungsgruppe enthalten.

418* `onExtractNoMatch` steuert, was geschieht, wenn das Muster nichts trifft:533* `onExtractNoMatch` steuert, was passiert, wenn das Muster auf nichts passt:

419 * `warn`, der Standard, warnt und übergibt die Variable unmasked534 * `warn`, der Standard, gibt eine Warnung aus und reicht die Variable unmaskiert durch

420 * `deny` deaktiviert die Variable in der Sandbox535 * `deny` entfernt die Variable innerhalb der Sandbox

421 * `error` stoppt das Sandbox-Setup, bis Sie die Konfiguration beheben536 * `error` stoppt die Einrichtung der Sandbox, bis Sie die Konfiguration korrigieren

422* `decode: "jwt"`: für eine Variable, die ein JSON Web Token (JWT) hält. Claude Code überprüft, dass der Wert ein JWT ist, und ersetzt ihn durch ein strukturell gültiges gefälschtes Token, daher funktioniert Code in der Sandbox, der das Token dekodiert, weiterhin. Fügen Sie `maskClaims` hinzu, um nur die aufgelisteten Top-Level-Payload-Ansprüche einzeln zu maskieren, anstatt das gesamte Token zu ersetzen; die anderen Ansprüche bleiben lesbar. Wenn der Wert nicht als JWT überprüft wird oder kein aufgelisteter Anspruch passt, übergibt Claude Code die Variable unmasked mit einer Warnung. `decode` kann nicht mit `extract` kombiniert werden.537* `decode: "jwt"`: für eine Variable, die ein JSON Web Token (JWT) enthält. Claude Code prüft, ob der Wert ein JWT ist, und ersetzt ihn durch ein strukturell gültiges gefälschtes Token, sodass Code innerhalb der Sandbox, der das Token dekodiert, weiterhin funktioniert. Fügen Sie `maskClaims` hinzu, um Claims der obersten Ebene der Payload aufzulisten, die einzeln maskiert werden sollen, anstatt das gesamte Token zu ersetzen; die übrigen Claims bleiben lesbar. Wenn sich der Wert nicht als JWT verifizieren lässt oder kein aufgeführter Claim passt, reicht Claude Code die Variable mit einer Warnung unmaskiert durch. `decode` kann nicht mit `extract` kombiniert werden.

423 538

424Siehe die [`credentials.envVars[]`-Zeilen in der Einstellungsreferenz](/docs/de/settings-reference#sandbox-settings) für die vollständige Feldliste.539Die vollständige Feldliste finden Sie in den [Zeilen zu `credentials.envVars[]` in der Einstellungsreferenz](/docs/de/settings-reference#sandbox-settings).

425 540

426<h4 id="re-sign-aws-requests">541<h4 id="re-sign-aws-requests">

427 AWS-Anfragen erneut signieren542 AWS-Anfragen neu signieren

428</h4>543</h4>

429 544

430AWS-Anfragen tragen SigV4-Signaturen über die Anfrageinhalte, daher maskieren Sie `AWS_ACCESS_KEY_ID` und `AWS_SECRET_ACCESS_KEY` zusammen. Der Proxy erkennt eine SigV4-Anfrage durch den Sentinel des Zugangsschlüssels und signiert sie erneut, nachdem er die echten Werte ersetzt hat. Das Maskieren des Geheimnisses allein hinterlässt Anfragen, die mit dem Platzhalter signiert sind, den der Proxy nicht erkennen kann, daher schlagen sie bei AWS fehl; Claude Code warnt in diesem Fall beim Start, aber nicht, wenn nur die Zugangsschlüssel-ID maskiert ist. Eine erkannte Anfrage, die der Proxy nicht erneut signieren kann, wie eine, der der `x-amz-date`-Header fehlt, schlägt mit einem Proxy-Fehler fehl, anstatt den Server mit einer fehlerhaften Signatur zu erreichen.545AWS-Anfragen tragen SigV4-Signaturen über den Anfrageinhalt. Maskieren Sie daher `AWS_ACCESS_KEY_ID` und `AWS_SECRET_ACCESS_KEY` gemeinsam. Der Proxy erkennt eine SigV4-Anfrage am Sentinel des Zugriffsschlüssels und signiert sie neu, nachdem er die echten Werte eingesetzt hat. Wird nur der geheime Schlüssel maskiert, bleiben Anfragen mit dem Platzhalter signiert, den der Proxy nicht erkennen kann, sodass sie bei AWS fehlschlagen; Claude Code warnt in diesem Fall beim Start, jedoch nicht, wenn nur die Zugriffsschlüssel-ID maskiert ist. Eine erkannte Anfrage, die der Proxy nicht neu signieren kann, etwa eine ohne `x-amz-date`-Header, schlägt mit einem Proxy-Fehler fehl, anstatt den Server mit einer fehlerhaften Signatur zu erreichen.

431 546

432Claude Code verknüpft die konventionellen `AWS_ACCESS_KEY_ID`-, `AWS_SECRET_ACCESS_KEY`- und `AWS_SESSION_TOKEN`-Variablen automatisch zu einer Anmeldedaten, wenn Sie ihre gesamten Werte maskieren. Wenn Ihre AWS-Anmeldedaten in Variablen mit anderen Namen lebt, gruppieren Sie sie selbst mit [`credentials.awsPairs`](/docs/de/settings-reference#sandbox-credentials-awspairs), das Claude Code v2.1.224 oder später erfordert. Dieses Beispiel fügt die Paarung zu einer Konfiguration hinzu, die bereits `MY_KEY_ID`, `MY_SECRET_KEY` und `MY_SESSION_TOKEN` ganz-Wert maskiert, wie in der [Maskierungskonfiguration oben](#mask-environment-variables):547Claude Code verknüpft die üblichen Variablen `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` und `AWS_SESSION_TOKEN` automatisch zu einem Satz Anmeldedaten, wenn Sie deren gesamte Werte maskieren. Wenn Ihre AWS-Anmeldedaten in Variablen mit anderen Namen liegen, gruppieren Sie diese selbst mit [`credentials.awsPairs`](/docs/de/settings-reference#sandbox-credentials-awspairs), was Claude Code v2.1.224 oder höher erfordert. Dieses Beispiel fügt die Zuordnung einer Konfiguration hinzu, die `MY_KEY_ID`, `MY_SECRET_KEY` und `MY_SESSION_TOKEN` bereits vollständig maskiert, wie in der [obigen Maskierungskonfiguration](#mask-environment-variables):

433 548

434```json theme={null}549```json theme={null}

435{550{

449 564

450Jeder Eintrag folgt diesen Regeln:565Jeder Eintrag folgt diesen Regeln:

451 566

452* `accessKeyIdVar` und `secretAccessKeyVar` benennen die maskierten `envVars`-Einträge, die die Zugangsschlüssel-ID und den geheimen Schlüssel halten. Das optionale `sessionTokenVar` benennt den Eintrag, der das Sitzungs-Token für temporäre Anmeldedaten hält; wenn gesetzt, sendet der Proxy das echte Token als `x-amz-security-token` bei erneut signierten Anfragen.567* `accessKeyIdVar` und `secretAccessKeyVar` benennen die maskierten `envVars`-Einträge, die die Zugriffsschlüssel-ID und den geheimen Schlüssel enthalten. Das optionale `sessionTokenVar` benennt den Eintrag mit dem Sitzungstoken für temporäre Anmeldedaten; wenn es gesetzt ist, sendet der Proxy bei neu signierten Anfragen das echte Token als `x-amz-security-token`.

453* Jede benannte Variable muss ein `mask`-Eintrag sein, der ihren gesamten Wert maskiert, ohne `extract` oder `decode`.568* Jede benannte Variable muss ein `mask`-Eintrag sein, der ihren gesamten Wert maskiert, ohne `extract` oder `decode`.

454* Der Proxy signiert Anfragen auf den Hosts erneut, die in der Zugangsschlüssel-ID-Eintrags-`injectHosts` aufgelistet sind.569* Der Proxy signiert Anfragen an die Hosts neu, die in den `injectHosts` des Eintrags für die Zugriffsschlüssel-ID aufgeführt sind.

455* Das Benennen einer der konventionellen Variablen in einem Paar ersetzt die automatische Paarung.570* Wird eine der üblichen Variablen in einem Paar benannt, ersetzt dies die automatische Zuordnung.

456 571

457Wie `mask`-Einträge wird `awsPairs` nur von Benutzer-Einstellungen, verwalteten Einstellungen und dem `--settings` CLI-Flag berücksichtigt.572Wie `mask`-Einträge wird `awsPairs` nur aus Benutzereinstellungen, verwalteten Einstellungen und dem CLI-Flag `--settings` berücksichtigt.

458 573

459Drei AWS-Anfrage-Formen tragen Signaturen, die der Proxy nicht neu berechnen kann. Wenn eine solche Anfrage mit einem Platzhalter eines maskierten Paares signiert ist, schlägt der Proxy sie fehl, anstatt eine fehlerhafte Signatur weiterzuleiten; Anfragen, die mit unmaskierten Anmeldedaten signiert sind, sind niemals betroffen. Die Einstellung [`credentials.sigv4`](/docs/de/settings-reference#sandbox-credentials-sigv4), die Claude Code v2.1.224 oder später erfordert, lockert dies pro Form: Das Setzen des Schlüssels einer Form auf `passthrough` leitet die Anfrage mit ihrer Platzhalter-abgeleiteten Signatur weiter, daher erhält das aufrufende Tool die eigene Ablehnungsantwort von AWS anstelle eines Proxy-Fehlers. Wie `awsPairs` wird `sigv4` nur von Benutzer-Einstellungen, verwalteten Einstellungen und dem `--settings` CLI-Flag berücksichtigt.574Drei Formen von AWS-Anfragen tragen Signaturen, die der Proxy nicht neu berechnen kann. Wenn eine solche Anfrage mit dem Platzhalter eines maskierten Paars signiert ist, lässt der Proxy sie fehlschlagen, anstatt eine fehlerhafte Signatur weiterzuleiten; Anfragen, die mit unmaskierten Anmeldedaten signiert sind, sind nie betroffen. Die Einstellung [`credentials.sigv4`](/docs/de/settings-reference#sandbox-credentials-sigv4), die Claude Code v2.1.224 oder höher erfordert, lockert dies je Form: Wird der Schlüssel einer Form auf `passthrough` gesetzt, wird die Anfrage mit ihrer vom Platzhalter abgeleiteten Signatur weitergeleitet, sodass das aufrufende Tool die Ablehnungsantwort von AWS selbst statt eines Proxy-Fehlers erhält. Wie `awsPairs` wird `sigv4` nur aus Benutzereinstellungen, verwalteten Einstellungen und dem CLI-Flag `--settings` berücksichtigt.

460 575

462| :- | :- | :- |577| :- | :- | :- |

463| aws-chunked Streaming-Uploads | `streaming` | Pro-Chunk-Signaturen verketten sich von der Seed-Signatur, daher würde eine Neusignierung das Rewriting des Körpers erfordern |578| aws-chunked-Streaming-Uploads | `streaming` | Die Signaturen pro Chunk bauen auf der Ausgangssignatur auf, sodass ein Neusignieren das Umschreiben des Bodys erfordern würde |

466 581

467<h4 id="mask-credential-files">582<h4 id="mask-credential-files">

468 Anmeldedatendateien maskieren583 Dateien mit Anmeldedaten maskieren

469</h4>584</h4>

470 585

471Datei-Einträge akzeptieren auch `"mode": "mask"`, das Claude Code v2.1.221 oder später erfordert. Was ein Sandbox-Befehl sieht, hängt von der Plattform ab:586Dateieinträge akzeptieren ebenfalls `"mode": "mask"`, was Claude Code v2.1.221 oder höher erfordert. Was ein Befehl in der Sandbox sieht, hängt von der Plattform ab:

472 587

473* **Linux und WSL2**: Sandbox-Befehle lesen eine Sentinel-Kopie der Datei, einen Platzhalter, dessen Geheimnis durch einen Platzhalter-Wert ersetzt ist, und der [Sandbox-Proxy](#network-isolation) ersetzt den echten Wert bei Ausgang.588* **Linux und WSL2**: Befehle in der Sandbox lesen eine Sentinel-Kopie der Datei, einen Ersatz, dessen Geheimnis durch einen Platzhalterwert ersetzt ist, und der [Sandbox-Proxy](#network-isolation) setzt beim ausgehenden Verkehr den echten Wert ein.

474* **macOS**: Sandbox-Befehle können die aufgelistete Datei überhaupt nicht lesen. Claude Code erstellt keine Sentinel-Kopie und ersetzt nichts bei Ausgang, daher funktionieren Tools, die sich mit der Datei authentifizieren, nicht in der Sandbox, der gleiche Effekt wie `deny`. Im Gegensatz zu einem `deny`-Eintrag gilt der Lesblock auch, wenn Sie [Dateisystem-Isolation deaktivieren](#disable-filesystem-isolation).589* **macOS**: Befehle in der Sandbox können die aufgeführte Datei überhaupt nicht lesen. Claude Code erstellt keine Sentinel-Kopie und ersetzt beim ausgehenden Verkehr nichts, sodass Tools, die sich mit der Datei authentifizieren, innerhalb der Sandbox nicht funktionieren, mit derselben Wirkung wie `deny`. Anders als bei einem `deny`-Eintrag bleibt die Lesesperre auch dann bestehen, wenn Sie die [Dateisystem-Isolation deaktivieren](#disable-filesystem-isolation).

475 590

476Auf jeder Plattform wendet Claude Code die [`network.tlsTerminate`](/docs/de/settings-reference#sandbox-network-tlsterminate)-Anforderung und `injectHosts` genauso an wie für [maskierte Umgebungsvariablen](#mask-environment-variables), und ignoriert Repository-Einstellungen genauso. Wenn Sie [Benutzer-Einstellungen ausschließen](#configure-sandboxing), behält Claude Code die Datei-`mask`-Einträge in `~/.claude/settings.json` als Einschränkungen, aber die Einträge autorisieren den Proxy nicht mehr, den echten Wert zu ersetzen.591Auf jeder Plattform wendet Claude Code die Anforderung [`network.tlsTerminate`](/docs/de/settings-reference#sandbox-network-tlsterminate) und `injectHosts` genauso an wie bei [maskierten Umgebungsvariablen](#mask-environment-variables) und ignoriert Repository-Einstellungen auf dieselbe Weise. Wenn Sie [Benutzereinstellungen ausschließen](#configure-sandboxing), behält Claude Code die `mask`-Einträge für Dateien in `~/.claude/settings.json` als Einschränkungen bei, aber die Einträge autorisieren den Proxy nicht mehr, den echten Wert einzusetzen.

477 592

478Das folgende Beispiel maskiert ein GitHub-Token, das in `~/.config/gh/hosts.yml` gespeichert ist; das `extract`-Muster, das unten behandelt wird, teilt Claude Code mit, welcher Teil der Datei das Geheimnis ist. Auf Linux und WSL2 erhalten Sandbox-Befehle, die die Datei lesen, einen Sentinel anstelle des Tokens, und der Proxy ersetzt das echte Token bei Anfragen an `api.github.com`:593Das folgende Beispiel maskiert ein GitHub-Token, das in `~/.config/gh/hosts.yml` gespeichert ist; das weiter unten beschriebene `extract`-Muster teilt Claude Code mit, welcher Teil der Datei das Geheimnis ist. Unter Linux und WSL2 erhalten Befehle in der Sandbox, die die Datei lesen, einen Sentinel anstelle des Tokens, und der Proxy setzt bei Anfragen an `api.github.com` das echte Token ein:

479 594

480```json theme={null}595```json theme={null}

481{596{

499}614}

500```615```

501 616

502Um zu bestätigen, dass die Maske aktiv ist, bitten Sie Claude, `cat ~/.config/gh/hosts.yml` in einem Sandbox-Befehl auszuführen: Auf Linux und WSL2 zeigt die Ausgabe einen Sentinel-Wert anstelle des Tokens, und auf macOS schlägt der Lesevorgang stattdessen fehl.617Um zu bestätigen, dass die Maske aktiv ist, bitten Sie Claude, `cat ~/.config/gh/hosts.yml` in einem Befehl in der Sandbox auszuführen: Unter Linux und WSL2 zeigt die Ausgabe einen Sentinel-Wert anstelle des Tokens, und unter macOS schlägt das Lesen stattdessen fehl.

503 618

504Auf Linux und WSL2 ist das `extract`-Muster das, was den Rest von `hosts.yml` lesbar hält. Claude Code wendet den regulären Ausdruck über die gesamte Datei an und ersetzt nur den Text, der von Gruppe 1 jedes Treffers erfasst wird, daher analysiert `gh` immer noch seine Konfiguration und nur das Token ist ein Platzhalter. Verwenden Sie `extract` für jede strukturierte Datei, die Tools analysieren, wie `.netrc`, JSON oder YAML; das Muster muss mindestens eine erfassende Gruppe enthalten. Ohne `extract` ersetzt Claude Code den gesamten Dateiinhalt durch einen Sentinel-Wert, was sich für eine Datei eignet, die ein einzelnes bloßes Geheimnis und nichts anderes hält.619Unter Linux und WSL2 sorgt das `extract`-Muster dafür, dass der Rest von `hosts.yml` lesbar bleibt. Claude Code wendet den regulären Ausdruck auf die gesamte Datei an und ersetzt nur den von Gruppe 1 jeder Übereinstimmung erfassten Text, sodass `gh` seine Konfiguration weiterhin parst und nur das Token ein Platzhalter ist. Verwenden Sie `extract` für jede strukturierte Datei, die Tools parsen, etwa `.netrc`, JSON oder YAML; das Muster muss mindestens eine Erfassungsgruppe enthalten. Ohne `extract` ersetzt Claude Code den gesamten Dateiinhalt durch einen einzigen Sentinel-Wert, was für eine Datei geeignet ist, die nur ein einzelnes Geheimnis und sonst nichts enthält.

505 620

506Für eine Datei, die ein JSON Web Token (JWT) hält, setzen Sie `decode: "jwt"` anstelle von oder zusammen mit `extract`. `decode` erfordert Claude Code v2.1.224 oder später. Claude Code findet JWT-Kandidaten mit einem eingebauten Muster oder mit Ihrem `extract`-Muster, wenn gesetzt, überprüft jeden Kandidaten, dass er ein JWT ist, und ersetzt ihn durch ein strukturell gültiges gefälschtes Token, daher funktioniert Code, der das Token in der Sandbox dekodiert, weiterhin. Fügen Sie `maskClaims` hinzu, um nur die benannten Top-Level-Payload-Ansprüche in jedem überprüften Token zu maskieren und die anderen Ansprüche lesbar zu lassen. Wenn kein Kandidat überprüft wird oder kein benannter Anspruch passt, regelt das Feld `onExtractNoMatch` unten das Ergebnis, wie es auch für ein Muster tut, das nichts trifft.621Für eine Datei, die ein JSON Web Token (JWT) enthält, setzen Sie `decode: "jwt"` anstelle von oder zusammen mit `extract`. `decode` erfordert Claude Code v2.1.224 oder höher. Claude Code findet JWT-Kandidaten mit einem integrierten Muster oder, falls gesetzt, mit Ihrem `extract`-Muster, prüft, ob jeder Kandidat ein JWT ist, und ersetzt ihn durch ein strukturell gültiges gefälschtes Token, sodass Code, der das Token innerhalb der Sandbox dekodiert, weiterhin funktioniert. Fügen Sie `maskClaims` hinzu, um nur die benannten Claims der obersten Ebene der Payload innerhalb jedes verifizierten Tokens zu maskieren und die übrigen Claims lesbar zu lassen. Wenn sich kein Kandidat verifizieren lässt oder kein benannter Claim passt, bestimmt das unten beschriebene Feld `onExtractNoMatch` das Ergebnis, genauso wie bei einem Muster, das auf nichts passt.

507 622

508Zwei optionale Felder verfeinern, wie Matching sich verhält. Beide gelten nur, wenn `mode` `mask` ist und `extract` oder `decode` gesetzt ist. Auf macOS wendet Claude Code `mask`-Einträge als `deny` an, bevor das Muster läuft, wann immer Dateisystem-Isolation an ist, daher gelten diese Felder und die No-Match-Ergebnisse unten dort nur, wenn [Dateisystem-Isolation aus ist](#disable-filesystem-isolation):623Zwei optionale Felder verfeinern das Abgleichverhalten. Beide gelten nur, wenn `mode` auf `mask` steht und `extract` oder `decode` gesetzt ist. Unter macOS wendet Claude Code `mask`-Einträge bei eingeschalteter Dateisystem-Isolation als `deny` an, bevor das Muster ausgeführt wird. Diese Felder und die unten beschriebenen Ergebnisse bei fehlender Übereinstimmung wirken dort daher nur, wenn die [Dateisystem-Isolation ausgeschaltet ist](#disable-filesystem-isolation):

509 624

510* `onExtractNoMatch` steuert, was geschieht, wenn Matching nichts zu maskieren in der Datei findet:625* `onExtractNoMatch` steuert, was passiert, wenn der Abgleich in der Datei nichts zum Maskieren findet:

511 626

512 * `warn`, der Standard, warnt und überspringt den Eintrag, daher können Sandbox-Befehle die echte Datei unmasked lesen. Der Standard eignet sich für Anmeldedaten, die legitim abwesend sein können; wenn das Geheimnis möglicherweise vorhanden ist, aber das Muster es möglicherweise verpasst, verwenden Sie `deny`627 * `warn`, der Standard, gibt eine Warnung aus und überspringt den Eintrag, sodass Befehle in der Sandbox die echte Datei unmaskiert lesen können. Der Standard eignet sich für Anmeldedaten, die berechtigterweise fehlen können; wenn das Geheimnis vorhanden sein könnte, das Muster es aber möglicherweise verfehlt, verwenden Sie `deny`

513 * `deny` macht die Datei stattdessen unlesbar628 * `deny` macht die Datei stattdessen unlesbar

514 * `error` stoppt das Sandbox-Setup, bis Sie die Konfiguration beheben629 * `error` stoppt die Einrichtung der Sandbox, bis Sie die Konfiguration korrigieren

515 630

516 Claude Code behandelt `deny` als `error`, wann immer der Lesblock nicht durchgesetzt würde: wenn Sie [Dateisystem-Isolation deaktivieren](#disable-filesystem-isolation), und wenn ein `filesystem.allowRead`-Eintrag aus einer beliebigen Einstellungsquelle den Dateipfad erneut öffnet.631 Claude Code behandelt `deny` als `error`, wann immer die Lesesperre nicht durchgesetzt würde: wenn Sie die [Dateisystem-Isolation deaktivieren](#disable-filesystem-isolation) und wenn ein `filesystem.allowRead`-Eintrag den Pfad der Datei wieder freigibt.

517* `maskDuplicates` ersetzt auch wörtliche Kopien jedes maskierten Anmeldedaten-Wertes, eine `extract`-Erfassung oder ein `decode`-überprüftes Token, das außerhalb der abgestimmten Spannweiten gefunden wird, für ein Geheimnis, das wiederholt wird, wo Matching nicht reicht. Es gleicht rohe Teilzeichenfolgen ab, daher würde ein kurzer oder häufiger Wert überall ersetzt, wo er erscheint; reservieren Sie es für lange, hochentropische Geheimnisse. Standard: false.632* `maskDuplicates` ersetzt zusätzlich wörtliche Kopien jedes maskierten Anmeldedatenwerts, also einer `extract`-Erfassung oder eines durch `decode` verifizierten Tokens, die außerhalb der abgeglichenen Bereiche gefunden werden, für ein Geheimnis, das an Stellen wiederholt wird, die der Abgleich nicht erreicht. Es gleicht rohe Teilstrings ab, sodass ein kurzer oder häufiger Wert überall ersetzt würde, wo er vorkommt; verwenden Sie es daher nur für lange Geheimnisse mit hoher Entropie. Standard: false.

518 633

519`mask` gilt für eine einzelne Datei, daher führen Sie jede Anmeldedatendatei einzeln auf. Claude Code fällt auf `deny` zurück für einen `mask`-Eintrag, den es nicht sicher maskieren kann: einen Verzeichnispfad, ein Glob-Muster, eine Datei größer als 8 MiB oder eine Datei, die kein UTF-8-Text ist. Schreiben Sie Verzeichnisse stattdessen als explizite `deny`-Einträge; die Tabelle unter [Welche Einstellungen können es deaktivieren](#which-settings-can-disable-it) behandelt, ob jede Form `filesystem.disabled` anheftet und wie sie sich mit Dateisystem-Isolation aus verhält.634`mask` gilt für eine einzelne Datei, listen Sie daher jede Datei mit Anmeldedaten einzeln auf. Claude Code fällt bei einem `mask`-Eintrag, den es nicht sicher maskieren kann, auf `deny` zurück: bei einem Verzeichnispfad, einem Glob-Muster, einer Datei größer als 8 MiB oder einer Datei, die kein UTF-8-Text ist. Tragen Sie Verzeichnisse stattdessen als explizite `deny`-Einträge ein; die Tabelle unter [Welche Einstellungen sie deaktivieren können](#which-settings-can-disable-it) beschreibt, ob jede Form `filesystem.disabled` festlegt und wie sie sich bei ausgeschalteter Dateisystem-Isolation verhält.

520 635

521<h2 id="how-sandboxing-works">636<h2 id="how-sandboxing-works">

522 Wie Sandboxing funktioniert637 Wie Sandboxing funktioniert

523</h2>638</h2>

524 639

525<h3 id="filesystem-isolation">640<h3 id="filesystem-isolation">

526 Dateisystem-Isolation641 Dateisystemisolation

527</h3>642</h3>

528 643

529Das Sandboxed-Bash-Tool beschränkt den Dateisystem-Zugriff auf spezifische Verzeichnisse:644Das in einer Sandbox ausgeführte Bash-Tool beschränkt den Dateisystemzugriff auf bestimmte Verzeichnisse:

530 645

531* **Standard-Schreibverhalten**: Lese- und Schreibzugriff auf das aktuelle Arbeitsverzeichnis und seine Unterverzeichnisse, alle Verzeichnisse, die Sie mit `--add-dir`, `/add-dir` oder [`permissions.additionalDirectories`](/docs/de/settings-reference#permissions-additionaldirectories) hinzugefügt haben, plus das benutzerabhängige Temp-Verzeichnis, auf das `$TMPDIR` verweist646* **Standardverhalten beim Schreiben**: Lese- und Schreibzugriff auf das aktuelle Arbeitsverzeichnis und seine Unterverzeichnisse, auf alle Verzeichnisse, die Sie mit `--add-dir`, `/add-dir` oder [`permissions.additionalDirectories`](/docs/de/settings-reference#permissions-additionaldirectories) hinzugefügt haben, sowie auf das benutzerspezifische temporäre Verzeichnis, auf das `$TMPDIR` verweist

532* **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. Verwenden Sie [`sandbox.credentials`](#protect-credentials), um Lesezugriffe auf diese Dateien zu blockieren und geheime Umgebungsvariablen zu deaktivieren, oder fügen Sie die Pfade zu `denyRead` hinzu.647* **Standardverhalten beim Lesen**: Lesezugriff auf den gesamten Computer, mit Ausnahme bestimmter gesperrter Verzeichnisse. Diese Standardeinstellung erlaubt weiterhin das Lesen von Dateien mit Anmeldedaten, daher sollten Sie [Anmeldedaten schützen](#protect-credentials), die Befehle nicht lesen sollen.

533* **Blockierter Lesezugriff**: Mit [`permissions.blockReadsOutsideWorkingDirectories`](/docs/de/settings-reference#permissions-blockreadsoutsideworkingdirectories) aktiviert, verlieren Sandbox-Befehle auch Lesezugriff auf Ihr Home-Verzeichnis und die anderen Verzeichnisse, die Benutzerdateien enthalten, außer den Pfaden, die [Sandboxed commands under the block](/docs/de/settings-reference#sandboxed-commands-under-the-block) auflistet. Dieser Abschnitt sagt auch, wann dieser Teil des Blocks nicht gilt.648* **Lesesperre**: Wenn [`permissions.blockReadsOutsideWorkingDirectories`](/docs/de/settings-reference#permissions-blockreadsoutsideworkingdirectories) aktiviert ist, verlieren in der Sandbox ausgeführte Befehle außerdem den Lesezugriff auf Ihr Home-Verzeichnis und die anderen Verzeichnisse, die Benutzerdateien enthalten, mit Ausnahme der Pfade, die unter [Befehle in der Sandbox unter der Sperre](/docs/de/settings-reference#sandboxed-commands-under-the-block) aufgeführt sind. Dieser Abschnitt beschreibt auch, wann dieser Teil der Sperre nicht gilt.

534* **Blockierter Zugriff**: Kann Dateien außerhalb des Arbeitsverzeichnisses, hinzugefügter Verzeichnisse und des benutzerabhängigen Temp-Verzeichnisses nicht ohne explizite Genehmigung ändern, einschließlich Shell-Konfigurationsdateien wie `~/.bashrc` und System-Binärdateien in `/bin/`649* **Git-Worktrees**: Wenn das Arbeitsverzeichnis ein [verknüpfter Git-Worktree](/docs/de/worktrees) ist, erlaubt die Sandbox auch Schreibvorgänge im gemeinsamen `.git`-Verzeichnis des Haupt-Repositorys, damit Befehle wie `git commit` Refs und den Index aktualisieren können. Schreibvorgänge in `hooks/` und `config` innerhalb dieses Verzeichnisses bleiben gesperrt.

535* **Git Worktrees**: Wenn das Arbeitsverzeichnis ein [verknüpftes Git Worktree](/docs/de/worktrees) 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.

536* **Konfigurierbar**: Definieren Sie benutzerdefinierte zulässige und blockierte Pfade durch Einstellungen

537 650

538Um die Dateisystem-Isolation vollständig zu überspringen und dabei die Netzwerk-Isolation beizubehalten, setzen Sie [`sandbox.filesystem.disabled`](#disable-filesystem-isolation).651Um die Dateisystemisolation vollständig zu überspringen und gleichzeitig die Netzwerkisolation beizubehalten, setzen Sie [`sandbox.filesystem.disabled`](#disable-filesystem-isolation).

539 652

540<h3 id="protected-paths">653<h3 id="protected-paths">

541 Geschützte Pfade654 Geschützte Pfade

542</h3>655</h3>

543 656

544Innerhalb der Verzeichnisse, in die Sandbox-Befehle schreiben können, blockiert die Sandbox immer noch Schreibzugriffe auf die Dateien, aus denen Claude Code Konfiguration und Code lädt. Ein Befehl, der diese Dateien bearbeiten könnte, könnte sich selbst Berechtigungen gewähren oder einen Hook oder MCP-Server hinzufügen, den Claude Code außerhalb der Sandbox ausführt. Das Berechtigungssystem hat seine eigenen [geschützten Pfade](/docs/de/permission-modes#protected-paths), die steuern, was Claude Code genehmigt, bevor ein Tool ausgeführt wird; die Liste der Sandbox gilt für einen Befehl, der bereits ausgeführt wird. Sie umfasst vier Gruppen von Pfaden:657Innerhalb der Verzeichnisse, in die in der Sandbox ausgeführte Befehle schreiben dürfen, verweigert die Sandbox weiterhin Schreibvorgänge in die Dateien, aus denen Claude Code Konfiguration und Code lädt. Ein Befehl, der diese Dateien bearbeiten könnte, könnte sich selbst Berechtigungen erteilen oder einen Hook oder MCP-Server hinzufügen, den Claude Code außerhalb der Sandbox ausführt. Das Berechtigungssystem hat eigene [geschützte Pfade](/docs/de/permission-modes#protected-paths), die steuern, was Claude Code genehmigt, bevor ein Tool ausgeführt wird; die Liste der Sandbox gilt für einen Befehl, der bereits läuft. Sie umfasst vier Gruppen von Pfaden:

545 658

546* **In Ihrem Arbeitsverzeichnis und den Verzeichnissen darüber**: die `.claude`-Einstellungsdateien, die Verzeichnisse `.claude/skills`, `.claude/agents`, `.claude/commands` und `.claude/hooks`, `.mcp.json` und die Dateien, die Claude Code selbst ausführt, wie `.claude/workflows` und `.claude/scheduled_tasks.json`659* **In Ihrem Arbeitsverzeichnis und den darüberliegenden Verzeichnissen**: die `.claude`-Einstellungsdateien, die Verzeichnisse `.claude/skills`, `.claude/agents`, `.claude/commands` und `.claude/hooks`, `.mcp.json` sowie die Dateien, die Claude Code selbstständig ausführt, etwa `.claude/workflows` und `.claude/scheduled_tasks.json`

547* **Nur in Ihrem Arbeitsverzeichnis**: Shell-Startdateien wie `.bashrc` und `.zshrc`, `.gitconfig`, die Verzeichnisse `.vscode` und `.idea` sowie `hooks` und `config` innerhalb von `.git`660* **Nur in Ihrem Arbeitsverzeichnis**: Shell-Startdateien wie `.bashrc` und `.zshrc`, `.gitconfig`, die Verzeichnisse `.vscode` und `.idea` sowie `hooks` und `config` innerhalb von `.git`

548* **Dateien, die Ihr Arbeitsverzeichnis in ein Bare-Git-Repository umwandeln würden**: `HEAD`, `objects` und `refs` auf der obersten Ebene, plus `config` und `hooks` dort, wenn ein `HEAD` neben ihnen sitzt. Eine Datei namens `config` wird auch ohne `HEAD` blockiert. Unter Linux und WSL2 löscht die Sandbox eine `HEAD`-Datei oder ein `objects`- oder `refs`-Verzeichnis auf der obersten Ebene, das während der Ausführung eines Sandbox-Befehls erscheint661* **Dateien, die Ihr Arbeitsverzeichnis in ein Bare-Git-Repository verwandeln würden**: `HEAD`, `objects` und `refs` auf oberster Ebene sowie dort vorhandene `config`- und `hooks`-Einträge, wenn daneben ein `HEAD` liegt. Eine Datei namens `config` wird auch ohne `HEAD` gesperrt. Unter Linux und WSL2 löscht die Sandbox eine `HEAD`-Datei bzw. ein `objects`- oder `refs`-Verzeichnis auf oberster Ebene, das erscheint, während ein Befehl in der Sandbox läuft

549* **In `~/.claude` oder dem Verzeichnis, auf das `CLAUDE_CONFIG_DIR` verweist**: die meisten seiner Inhalte, plus `~/.claude.json` und der Anmeldedaten-Speicher `.credentials.json`662* **In `~/.claude` oder dem Verzeichnis, auf das `CLAUDE_CONFIG_DIR` verweist**: der Großteil des Inhalts sowie `~/.claude.json` und der Anmeldedatenspeicher `.credentials.json`

550 663

551Wenn ein Symlink während der Sitzung auf dem Pfad einer geschützten Einstellungsdatei erscheint, blockiert die Sandbox auch Schreibzugriffe auf die Datei, auf die er verweist, ab dem nächsten Befehl.664Wenn während der Sitzung ein Symlink am Pfad einer geschützten Einstellungsdatei erscheint, verweigert die Sandbox ab dem nächsten Befehl auch Schreibvorgänge in die Datei, auf die er verweist.

552 665

553Es gibt keine Möglichkeit, einen dieser Pfade auszunehmen: Ein `allowWrite`-Eintrag oder eine `Edit`-Erlaubnisregel, die den Pfad abdeckt, hebt den Schutz nicht auf. Die einzige Möglichkeit, den Schutz auszuschalten, ist [`filesystem.disabled`](#disable-filesystem-isolation), was die Dateisystem-Isolation für jeden Pfad ausschaltet. Um die meisten dieser Pfade für Ihren Computer aufgelöst zu sehen, führen Sie `/sandbox` aus und öffnen Sie die Registerkarte **Config**, die sie unter **Denied within allowed** auflistet, gemischt mit Ihren eigenen `denyWrite`-Einträgen.666Es gibt keine Möglichkeit, einen dieser Pfade auszunehmen: Ein `allowWrite`-Eintrag oder eine `Edit`-allow-Regel, die den Pfad abdeckt, hebt den Schutz nicht auf. Die einzige Möglichkeit, den Schutz auszuschalten, ist [`filesystem.disabled`](#disable-filesystem-isolation), wodurch die Dateisystemisolation für alle Pfade ausgeschaltet wird. Um die meisten dieser Pfade für Ihren Rechner aufgelöst zu sehen, führen Sie `/sandbox` aus und öffnen Sie den Tab **Config**, der sie unter **Denied within allowed** zusammen mit Ihren eigenen `denyWrite`-Einträgen auflistet.

554 667

555Wenn `git merge` oder `git checkout` mit `unable to unlink old` auf einem dieser Pfade fehlschlägt, siehe [Troubleshooting](#troubleshooting).668Wenn `git merge` oder `git checkout` bei einem dieser Pfade mit `unable to unlink old` fehlschlägt, lesen Sie [Fehlerbehebung](#troubleshooting).

556 669

557<h3 id="network-isolation">670<h3 id="network-isolation">

558 Netzwerk-Isolation671 Netzwerkisolation

559</h3>672</h3>

560 673

561Der Netzwerkzugriff wird durch einen Proxy-Server gesteuert, der außerhalb der Sandbox läuft:674Ein in der Sandbox ausgeführter Befehl hat keinen direkten Zugang zum Netzwerk:

675

676* **Linux und WSL2**: Der Befehl läuft in einem separaten Netzwerk-Namespace, der keine Verbindung zu Ihrem Netzwerk hat

677* **macOS**: Das Sandbox-Framework Seatbelt blockiert standardmäßig alle Verbindungen außer der zum Sandbox-Proxy

678

679Claude Code betreibt den Sandbox-Proxy auf Ihrem Rechner außerhalb der Sandbox und leitet Befehle mit `HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY` und verwandten Umgebungsvariablen zu ihm. Der Proxy prüft den Hostnamen jeder Verbindung anhand Ihrer erlaubten und gesperrten Domains.

562 680

563* **Domain-Einschränkungen**: Claude Code erlaubt standardmäßig keine Domains vorab. Wenn ein Befehl zum ersten Mal eine neue Domain benötigt, fordert Claude Code zur Genehmigung auf; im [Auto-Modus](/docs/de/permission-modes#eliminate-prompts-with-auto-mode) nennt Claude stattdessen die Hosts, die ein Befehl benötigt, auf dem Befehl selbst, pro [Per-command allowed domains](#per-command-allowed-domains-in-auto-mode).681Was ein Tool erreichen kann, hängt davon ab, ob es den Proxy verwendet:

564* **Genehmigungsoptionen**: Wenn Sie bei der Aufforderung „Ja" wählen, erlaubt Claude Code den Host für den Rest der aktuellen Sitzung und fordert nicht erneut auf für spätere Verbindungen zum gleichen Host. Wenn Sie „Ja, und nicht mehr fragen" wählen, speichert Claude Code eine `WebFetch(domain:...)`-Erlaubnisregel in Ihren [lokalen Einstellungen](/docs/de/permissions#permission-system), sodass der Host in zukünftigen Sitzungen zulässig bleibt.

565* **Vorab zulässige Domains**: Lassen Sie Domains vorab mit [`allowedDomains`](/docs/de/settings-reference#sandbox-network-alloweddomains) zu, um die Aufforderung vollständig zu vermeiden. Claude Code erlaubt auch Domains vorab aus `WebFetch(domain:...)`-Erlaubnisregeln, wie in [Permission rules](#permission-rules) beschrieben.

566* **Strikte Zulassungsliste**: Wenn Sie [`strictAllowlist`](/docs/de/settings-reference#sandbox-network-strictallowlist) in Benutzer-, verwalteten oder CLI-`--settings`-Einstellungen auf `true` setzen, blockiert Claude Code den Zugriff von Sandbox-Befehlen auf jeden Host außerhalb der Zulassungsliste, anstatt zu fragen. Die Zulassungsliste ist die gleiche, gegen die die Sandbox sonst fragt: `allowedDomains` plus Domains aus `WebFetch(domain:...)`-Erlaubnisregeln, oder nur die Einträge der verwalteten Einstellungen, wenn `allowManagedDomainsOnly` gesetzt ist. Claude Code erzwingt dies nur für Sandbox-Befehle; In-Process-Tools wie `WebFetch` folgen immer noch ihren [Permission rules](#permission-rules). Das Setzen in der `.claude/settings.json` oder `.claude/settings.local.json` eines Repositorys hat keine Auswirkung. Erfordert Claude Code v2.1.219 oder später.

567* **Verwaltete Sperrung**: Wenn [`allowManagedDomainsOnly`](/docs/de/settings-reference#sandbox-network-allowmanageddomainsonly) in verwalteten Einstellungen gesetzt ist, werden nicht zulässige Domains automatisch blockiert, anstatt zu fragen, und nur `allowedDomains` und `WebFetch(domain:...)`-Erlaubnisregeln aus verwalteten Einstellungen werden berücksichtigt.

568* **Unternehmens-Proxy**: Wenn Ihr Netzwerk erfordert, dass ausgehender Datenverkehr durch einen Unternehmens-Proxy geleitet wird, setzen Sie `HTTPS_PROXY`, `HTTP_PROXY` und `NO_PROXY` wie [Proxy-Konfiguration](/docs/de/network-config#proxy-configuration) beschreibt, im `env`-Block Ihrer Einstellungen, damit [Background Agents](/docs/de/network-config#set-network-variables-in-settings-not-the-shell) sie auch erhalten, oder in der Umgebung, aus der Sie Claude Code starten. Claude Code erzwingt die Domain-Zulassungsliste und tunnelt dann zulässige Verbindungen durch diesen Upstream-Proxy.

569* **Benutzerdefinierte Proxy-Unterstützung**: Fortgeschrittene Benutzer können benutzerdefinierte Regeln für ausgehenden Datenverkehr implementieren

570* **Umfassende Abdeckung**: Einschränkungen gelten für alle Skripte, Programme und Subprozesse, die durch Befehle erzeugt werden

571 682

572In einer `WebFetch(domain:...)`-Regel ehrt die Sandbox zwei Wildcard-Formen: ein führendes `*.`, wie `*.example.com`, und ein einfaches `*`. Die einfache `*`-Form erfordert Claude Code v2.1.186 oder später. Ein Wildcard an einer anderen Position, wie `WebFetch(domain:example.*)`, stimmt immer noch mit Abrufen überein, hat aber keine Auswirkung auf Sandbox-Befehle.683* **Tools, die die Proxy-Variablen lesen**: `curl`, `npm`, `git` über HTTPS und ähnliche Tools verbinden sich, sobald ihr Host erlaubt ist. Ein `allowedDomains`-Eintrag ohne Port erlaubt jeden Port auf diesem Host

684* **Tools, die die Proxy-Variablen ignorieren**: einfaches `ssh`, die meisten Datenbanktreiber und ähnliche Tools können sich nicht verbinden, selbst zu einem erlaubten Host. Siehe [Ein Datenbank-Client oder ein anderes Nicht-HTTP-Tool erreicht einen erlaubten Host nicht](#a-database-client-or-other-non-http-tool-fails-to-reach-an-allowed-host)

685* **Alles, was nicht TCP ist**: UDP, HTTP/3 über QUIC und ICMP-Tools wie `ping` können die Sandbox nicht verlassen

686

687Die folgenden Einstellungen und Verhaltensweisen steuern, welche Hosts der Proxy erlaubt:

688

689* **Domain-Beschränkungen**: Ihre erlaubten Domains sind anfangs leer. [Hosts außerhalb Ihrer erlaubten Domains](#hosts-outside-your-allowed-domains) beschreibt, was passiert, wenn ein Befehl zum ersten Mal eine neue Domain benötigt.

690* **Genehmigungsoptionen**: Wenn Sie bei der Abfrage Yes wählen, erlaubt Claude Code den Host für den Rest der aktuellen Sitzung. Wenn Sie „Yes, and don't ask again" wählen, speichert Claude Code eine `WebFetch(domain:...)`-allow-Regel in Ihren [lokalen Einstellungen](/docs/de/permissions#permission-system), sodass der Host auch in zukünftigen Sitzungen erlaubt bleibt. Solange die Sandbox [vom Administrator vorgeschrieben](#repository-settings-under-an-admin-required-sandbox) ist, speichert Claude Code die Regel in Ihren Benutzereinstellungen, wo sie in jedem Projekt gilt.

691* **Vorab erlaubte Domains**: Erlauben Sie Domains vorab mit [`allowedDomains`](/docs/de/settings-reference#sandbox-network-alloweddomains), um die Abfrage ganz zu vermeiden. Claude Code erlaubt außerdem vorab Domains aus `WebFetch(domain:...)`-allow-Regeln, wie unter [Berechtigungsregeln](#permission-rules) beschrieben.

692* **Strikte Allowlist**: Wenn Sie [`strictAllowlist`](/docs/de/settings-reference#sandbox-network-strictallowlist) in Benutzer-, verwalteten oder CLI-`--settings`-Einstellungen auf `true` setzen, verweigert Claude Code Befehlen in der Sandbox den Zugriff auf jeden Host außerhalb der Allowlist, statt nachzufragen. Die Allowlist besteht aus `allowedDomains` plus Domains aus `WebFetch(domain:...)`-allow-Regeln oder nur aus den Einträgen der verwalteten Einstellungen, wenn `allowManagedDomainsOnly` gesetzt ist. [Sperren, die ohne vom Administrator vorgeschriebene Sandbox gelten](#locks-that-apply-without-an-admin-required-sandbox) behandelt die Einträge eines Repositorys. Claude Code erzwingt dies nur für Befehle in der Sandbox; prozessinterne Tools wie `WebFetch` folgen weiterhin ihren [Berechtigungsregeln](#permission-rules). Das Setzen in `.claude/settings.json` oder `.claude/settings.local.json` eines Repositorys hat keine Wirkung. Erfordert Claude Code v2.1.219 oder höher.

693* **Verwaltete Sperre**: Wenn [`allowManagedDomainsOnly`](/docs/de/settings-reference#sandbox-network-allowmanageddomainsonly) in verwalteten Einstellungen gesetzt ist, werden nicht erlaubte Domains automatisch blockiert, statt nachzufragen, und nur `allowedDomains` und `WebFetch(domain:...)`-allow-Regeln aus verwalteten Einstellungen werden berücksichtigt.

694* **Unternehmens-Proxy**: Wenn Ihr Netzwerk verlangt, dass ausgehender Datenverkehr über einen Unternehmens-Proxy läuft, setzen Sie `HTTPS_PROXY`, `HTTP_PROXY` und `NO_PROXY` wie unter [Proxy-Konfiguration](/docs/de/network-config#proxy-configuration) beschrieben, und zwar im `env`-Block Ihrer Einstellungen, damit auch [Hintergrund-Agenten](/docs/de/network-config#set-network-variables-in-settings-not-the-shell) sie erhalten, oder in der Umgebung, aus der Sie Claude Code starten. Claude Code erzwingt die Domain-Allowlist und tunnelt erlaubte Verbindungen dann über diesen vorgelagerten Proxy. `http://`- und `https://`-Proxy-URLs funktionieren, bei Bedarf mit Basic-Authentifizierung in der URL.

695

696In einer `WebFetch(domain:...)`-Regel berücksichtigt die Sandbox zwei Platzhalterformen: ein führendes `*.`, etwa `*.example.com`, und ein alleinstehendes `*`. Die Form mit alleinstehendem `*` erfordert Claude Code v2.1.186 oder höher. Ein Platzhalter an jeder anderen Position, etwa `WebFetch(domain:example.*)`, passt weiterhin auf Abrufe, hat aber keine Wirkung auf Befehle in der Sandbox.

573 697

574<Note>698<Note>

575 Der integrierte Proxy erzwingt die Zulassungsliste basierend auf dem angeforderten Hostnamen und beendet oder inspiziert standardmäßig keinen TLS-Datenverkehr. Die experimentelle Einstellung [`network.tlsTerminate`](/docs/de/settings-reference#sandbox-network-tlsterminate), verfügbar in Claude Code v2.1.199 und später, lässt den integrierten Proxy TLS selbst beenden, was [`mask`-Anmeldedateneinträge](#mask-credentials) erfordern. Siehe [Security limitations](#security-limitations) für die Auswirkungen des Standards und [Custom proxy configuration](#custom-proxy-configuration), wenn Ihr Bedrohungsmodell TLS-Inspektion erfordert.699 Der integrierte Proxy erzwingt die Allowlist anhand des angefragten Hostnamens und terminiert oder prüft TLS-Datenverkehr standardmäßig nicht. Die experimentelle Einstellung [`network.tlsTerminate`](/docs/de/settings-reference#sandbox-network-tlsterminate), verfügbar in Claude Code v2.1.199 und höher, lässt den integrierten Proxy TLS selbst terminieren, was für [`mask`-Anmeldedateneinträge](#mask-credentials) erforderlich ist. Siehe [Sicherheitseinschränkungen](#security-limitations) für die Auswirkungen der Standardeinstellung und [Benutzerdefinierte Proxy-Konfiguration](#custom-proxy-configuration), falls Ihr Bedrohungsmodell eine TLS-Prüfung erfordert.

576</Note>700</Note>

577 701

702<h4 id="hosts-outside-your-allowed-domains">

703 Hosts außerhalb Ihrer erlaubten Domains

704</h4>

705

706Wenn sich ein Befehl in der Sandbox mit einem Host verbindet, der nicht zu Ihren erlaubten Domains gehört, bleibt der Befehl in der Sandbox und wartet auf eine Entscheidung. In einer interaktiven Terminal-Sitzung hängt die Entscheidung von Ihrem Berechtigungsmodus ab:

707

708| Berechtigungsmodus | Was mit der Verbindung passiert |

709| :- | :- |

710| `bypassPermissions`-Modus sowie Plan-Modus mit [verfügbarem Umgehen von Berechtigungen](/docs/de/permission-modes#skip-all-checks-with-bypasspermissions-mode) | Ohne Abfrage erlaubt |

711| Manueller Modus, `acceptEdits`-Modus und Plan-Modus in anderen Fällen | Sie erhalten eine Abfrage |

712| Auto-Modus | Abgelehnt, sofern der Befehl den Host nicht [aufgeführt hat](#per-command-allowed-domains-in-auto-mode) und der Klassifikator die Liste genehmigt hat |

713| `dontAsk`-Modus | Abgelehnt |

714

715Wenn [`strictAllowlist`](/docs/de/settings-reference#sandbox-network-strictallowlist) oder [`allowManagedDomainsOnly`](/docs/de/settings-reference#sandbox-network-allowmanageddomainsonly) aktiviert ist, lehnt der integrierte Sandbox-Proxy die Verbindung in jedem Berechtigungsmodus ab. Im `bypassPermissions`-Modus sind Hosts außerhalb Ihrer erlaubten Domains erlaubt, sofern keine dieser Einstellungen aktiviert ist. [Der Notausgang des Wiederholungsversuchs außerhalb der Sandbox](#the-unsandboxed-retry-escape-hatch) beschreibt, wann ein Befehl die Sandbox in diesem Modus verlassen kann. Eine Verbindung zu einem Host in [`deniedDomains`](/docs/de/settings-reference#sandbox-network-denieddomains) wird ebenfalls in jedem Berechtigungsmodus abgelehnt.

716

717<h4 id="hostnames-that-resolve-to-local-addresses">

718 Hostnamen, die zu lokalen Adressen aufgelöst werden

719</h4>

720

721Nachdem ein Hostname die Allowlist passiert hat, löst der Sandbox-Proxy ihn auf und lehnt die Verbindung ab, wenn der Name ausschließlich zu lokalen Adressen aufgelöst wird. Zu den lokalen Adressen gehören Loopback-Adressen wie `127.0.0.1`, Link-Local-Adressen wie der Cloud-Metadaten-Endpunkt `169.254.169.254` sowie Adressen, die Ihrem eigenen Rechner zugewiesen sind. Die Namen `localhost` und `*.localhost` dürfen zu Loopback aufgelöst werden.

722

723Ein erlaubter Intranet-Hostname, der zu einem privaten Bereich wie `10.0.0.0/8` aufgelöst wird, verbindet sich. Damit ein Name zu einer abgelehnten Adresse aufgelöst werden darf, fügen Sie diese IP-Adresse zu `allowedDomains` hinzu, etwa `"127.0.0.1:8080"`.

724

725Die Prüfung gilt für Hostnamen. Über eine Verbindung zu einer IP-Adresse entscheiden Ihre erlaubten Domains und Ihr Berechtigungsmodus. Der Proxy überspringt die Prüfung außerdem bei Verbindungen, die er über einen vorgelagerten Unternehmens-Proxy sendet, da dieser Proxy den Namen auflöst.

726

578<h4 id="per-command-allowed-domains-in-auto-mode">727<h4 id="per-command-allowed-domains-in-auto-mode">

579 Per-command allowed domains im Auto-Modus728 Erlaubte Domains pro Befehl im Auto-Modus

580</h4>729</h4>

581 730

582Im [Auto-Modus](/docs/de/permission-modes#eliminate-prompts-with-auto-mode) mit aktiviertem Sandboxing nennt Claude die Hosts, die ein Befehl benötigt, auf dem Befehl selbst, anstatt für jede Verbindung eine Netzwerk-Genehmigung auszulösen. Jeder Bash-, PowerShell- oder [Monitor](/docs/de/tools-reference#monitor-tool)-Befehl, der in der Sandbox ausgeführt wird, kann eine Liste von Hosts über die Zulassungsliste der Sandbox hinaus tragen: eine Domain wie `registry.npmjs.org`, ein Wildcard wie `*.pythonhosted.org` oder eine IP-Adresse, jeweils mit einem optionalen `:port`. Der Klassifizierer überprüft die Hosts zusammen mit dem Befehl. Erfordert Claude Code v2.1.271 oder später.731Im [Auto-Modus](/docs/de/permission-modes#eliminate-prompts-with-auto-mode) mit aktiviertem Sandboxing benennt Claude die Hosts, die ein Befehl benötigt, direkt am Befehl, statt für jede Verbindung eine Netzwerkgenehmigung auszulösen. Jeder Bash-, PowerShell- oder [Monitor](/docs/de/tools-reference#monitor-tool)-Befehl, der in der Sandbox läuft, kann eine Liste von Hosts über die Allowlist der Sandbox hinaus mitführen: eine Domain wie `registry.npmjs.org`, einen Platzhalter wie `*.pythonhosted.org` oder eine IP-Adresse, jeweils mit optionalem `:port`. Der Klassifikator prüft die Hosts zusammen mit dem Befehl. Erfordert Claude Code v2.1.271 oder höher.

583 732

584Eine genehmigte Liste öffnet diese Hosts nur für diesen einen Befehl, solange er ausgeführt wird. Nichts wird zu Ihren Session-zulässigen Hosts oder Ihren Einstellungen hinzugefügt; der nächste Befehl nennt seine eigenen Hosts.733Eine genehmigte Liste öffnet diese Hosts nur für diesen einen Befehl, solange er läuft. Weder den erlaubten Hosts Ihrer Sitzung noch Ihren Einstellungen wird etwas hinzugefügt; der nächste Befehl benennt seine eigenen Hosts.

585 734

586Ein Befehl, der Hosts trägt, geht an den Klassifizierer, anstatt von einer Erlaubnisregel oder dem [Auto-Allow-Modus](#sandbox-modes) der Sandbox genehmigt zu werden. Wenn eine [ask-Regel](/docs/de/permissions#manage-permissions) eine Aufforderung für den Befehl erzwingt, listet der Berechtigungsdialog in Ihrem Terminal die Hosts daneben auf, und das Genehmigen dort deckt beides ab.735Ein Befehl, der Hosts mitführt, geht an den Klassifikator, statt durch eine Berechtigungsregel oder den [Auto-Allow-Modus](#sandbox-modes) der Sandbox genehmigt zu werden. Wenn eine [ask-Regel](/docs/de/permissions#manage-permissions) eine Abfrage für den Befehl erzwingt, listet der Berechtigungsdialog in Ihrem Terminal die Hosts daneben auf, und eine Genehmigung dort deckt beides ab.

587 736

588Eine Per-Command-Liste verbreitert nur das, was die Sandbox standardmäßig blockiert. [`deniedDomains`](/docs/de/settings-reference#sandbox-network-denieddomains)-Einträge blockieren immer noch. Wenn [`strictAllowlist`](/docs/de/settings-reference#sandbox-network-strictallowlist) oder [`allowManagedDomainsOnly`](/docs/de/settings-reference#sandbox-network-allowmanageddomainsonly) die Zulassungsliste sperrt, lehnt Claude Code Per-Command-Listen ab.737Eine Liste pro Befehl erweitert nur das, was die Sandbox standardmäßig verweigert. Einträge in [`deniedDomains`](/docs/de/settings-reference#sandbox-network-denieddomains) blockieren weiterhin. Wenn [`strictAllowlist`](/docs/de/settings-reference#sandbox-network-strictallowlist) oder [`allowManagedDomainsOnly`](/docs/de/settings-reference#sandbox-network-allowmanageddomainsonly) die Allowlist sperrt, lehnt Claude Code Listen pro Befehl ab.

589 738

590Während Per-Command-Listen gelten, lehnt Claude Code eine Verbindung zu einem Host ab, den kein genehmigter Befehl aufgelistet hat, ohne eine Aufforderung oder eine Klassifizierer-Überprüfung. Die Ablehnung nennt den Host im Ergebnis des Befehls, und Claude führt den Befehl mit dem hinzugefügten Host erneut aus.739Solange Listen pro Befehl gelten, lehnt Claude Code eine Verbindung zu einem Host, den kein genehmigter Befehl aufgeführt hat, ohne Abfrage und ohne Prüfung durch den Klassifikator ab. Die Ablehnung nennt den Host im Ergebnis des Befehls, und Claude führt den Befehl mit hinzugefügtem Host erneut aus.

591 740

592<h4 id="ipv6-addresses-in-domain-lists">741<h4 id="ipv6-addresses-in-domain-lists">

593 IPv6-Adressen in Domain-Listen742 IPv6-Adressen in Domain-Listen

594</h4>743</h4>

595 744

596Die Domain-Listen der Sandbox sind `allowedDomains`, `deniedDomains` und die `WebFetch(domain:...)`-Regeln, die sie speisen. Um eine IPv6-Adresse in einer von ihnen zu treffen, schreiben Sie das Literal in Klammern: `"[::1]"` stimmt mit dieser Adresse auf jedem Port überein, und `"[::1]:443"` stimmt mit ihr nur auf Port 443 überein. Schreiben Sie den Port als Zahl von 1 bis 65535 ohne führende Nullen. Die geklammerte Form erfordert Claude Code v2.1.229 oder später. Vor v2.1.229, wenn der Text nach dem letzten Doppelpunkt eines ungeklammerten Eintrags eine Portnummer war, las Claude Code ihn als eine, also benannte `::1:443` die Adresse `::1` auf Port 443.745Die Domain-Listen der Sandbox sind `allowedDomains`, `deniedDomains` und die `WebFetch(domain:...)`-Regeln, die in sie einfließen. Um in einer davon eine IPv6-Adresse abzugleichen, schreiben Sie das Literal in eckigen Klammern: `"[::1]"` passt auf diese Adresse an jedem Port, und `"[::1]:443"` passt nur an Port 443. Schreiben Sie den Port als Zahl von 1 bis 65535 ohne führende Nullen. Die Form in eckigen Klammern erfordert Claude Code v2.1.229 oder höher. Vor v2.1.229 las Claude Code den Text nach dem letzten Doppelpunkt eines Eintrags ohne Klammern als Port, wenn es sich um eine Portnummer handelte, sodass `::1:443` die Adresse `::1` an Port 443 bezeichnete.

597 746

598Wenn Sie bei der Netzwerk-Genehmigungsaufforderung für eine IPv6-Adresse „Ja, und nicht mehr fragen" wählen, speichert Claude Code die `WebFetch(domain:...)`-Regel mit der Adresse geklammert, sodass die Regel die Adresse in zukünftigen Sitzungen weiterhin trifft.747Wenn Sie bei der Netzwerk-Genehmigungsabfrage für eine IPv6-Adresse „Yes, and don't ask again" wählen, speichert Claude Code die `WebFetch(domain:...)`-Regel mit der Adresse in eckigen Klammern, sodass die Regel die Adresse auch in zukünftigen Sitzungen weiterhin abgleicht.

599 748

600Ein ungeklammerter Eintrag mit zwei oder mehr Doppelpunkten ist mehrdeutig: `::1:443` ist sowohl eine vollständige IPv6-Adresse als auch eine Adresse gefolgt von einem Port. Claude Code erzwingt mehrdeutige Schreibweisen konservativ, anstatt zu erraten, welche Lesart Sie gemeint haben:749Ein Eintrag ohne Klammern mit zwei oder mehr Doppelpunkten ist mehrdeutig: `::1:443` ist sowohl eine vollständige IPv6-Adresse als auch eine Adresse gefolgt von einem Port. Claude Code setzt mehrdeutige Schreibweisen konservativ durch, statt zu raten, welche Lesart Sie gemeint haben:

601 750

602* **Deny-Listen**: Claude Code blockiert jede Lesart, die der Eintrag analysiert, also wird die Lesart, die Sie gemeint haben, blockiert. Für einen Eintrag ohne analysierbare Lesart blockiert Claude Code nichts.751* **Denylists**: Claude Code sperrt jede Lesart, als die der Eintrag geparst werden kann, sodass die von Ihnen gemeinte Lesart in jedem Fall blockiert ist. Bei einem Eintrag ohne parsbare Lesart blockiert Claude Code nichts.

603* **Allow-Listen**: Claude Code erlaubt nie mehr als Sie geschrieben haben. Es schreibt einen mehrdeutigen Eintrag in seine Host-und-Port-Lesart um, wenn diese Lesart sauber analysiert, und kann den Eintrag vollständig fallen lassen, anstatt die Zulassungsliste zu verbreitern.752* **Allowlists**: Claude Code erlaubt nie mehr, als Sie geschrieben haben. Es schreibt einen mehrdeutigen Eintrag in seine Host-und-Port-Lesart um, wenn diese Lesart sauber geparst werden kann, und verwirft den Eintrag gegebenenfalls ganz, statt die Allowlist zu erweitern.

604 753

605Führen Sie `claude doctor` in Ihrem Terminal aus, um die betroffenen Einträge zu finden: Die Warnung `Sandbox network domain entries have unreliable spellings` nennt bis zu drei von ihnen und zählt den Rest. Schreiben Sie jeden in der geklammerten Form um, um die Warnung zu löschen. Die Warnung nennt auch Einträge, deren Schreibweise aus anderen Gründen unzuverlässig ist, wie `@`, Pfad- oder Abfragezeichen oder Wildcards in Klammern.754Führen Sie `claude doctor` in Ihrem Terminal aus, um die betroffenen Einträge zu finden: Die Warnung `Sandbox network domain entries have unreliable spellings` nennt bis zu drei davon und zählt die übrigen. Schreiben Sie jeden davon in die Form mit eckigen Klammern um, damit die Warnung verschwindet. Die Warnung nennt auch Einträge, deren Schreibweise aus anderen Gründen unzuverlässig ist, etwa wegen `@`, Pfad- oder Query-Zeichen oder Platzhaltern innerhalb eckiger Klammern.

606 755

607<h3 id="os-level-enforcement">756<h3 id="os-level-enforcement">

608 OS-Level-Durchsetzung757 Durchsetzung auf Betriebssystemebene

609</h3>758</h3>

610 759

611Das Sandboxed-Bash-Tool nutzt Betriebssystem-Sicherheits-Primitive:760Das in einer Sandbox ausgeführte Bash-Tool verwendet Sicherheitsprimitive des Betriebssystems:

612 761

613* **macOS**: Verwendet Seatbelt für Sandbox-Durchsetzung762* **macOS**: verwendet Seatbelt zur Durchsetzung der Sandbox

614* **Linux**: Verwendet [bubblewrap](https://github.com/containers/bubblewrap) für Isolation763* **Linux**: verwendet [bubblewrap](https://github.com/containers/bubblewrap) zur Isolation

615* **WSL2**: Verwendet bubblewrap, wie Linux764* **WSL2**: verwendet bubblewrap, wie Linux

616 765

617WSL1 wird nicht unterstützt, da bubblewrap Kernel-Features erfordert, die nur in WSL2 verfügbar sind.766WSL1 wird nicht unterstützt, da bubblewrap Kernel-Funktionen benötigt, die nur in WSL2 verfügbar sind.

618 767

619Diese gleichen Primitive sind als das eigenständige Paket [`@anthropic-ai/sandbox-runtime`](https://github.com/anthropic-experimental/sandbox-runtime) verfügbar, das die Seite [Sandbox-Umgebungen](/docs/de/sandbox-environments#sandbox-runtime) als separaten Ansatz zum Wrapping des gesamten Claude Code-Prozesses behandelt.768Sie können das Paket [`@anthropic-ai/sandbox-runtime`](https://github.com/anthropics/sandbox-runtime) auch eigenständig ausführen, um den Claude Code-Prozess zu umschließen. Siehe [Sandbox-Laufzeit](/docs/de/sandbox-environments#sandbox-runtime).

620 769

621<h2 id="how-sandboxing-relates-to-permissions-and-permission-modes">770<h2 id="how-sandboxing-relates-to-permissions-and-permission-modes">

622 Wie Sandboxing sich auf Genehmigungen und Genehmigungsmodi bezieht771 Wie Sandboxing sich auf Genehmigungen und Genehmigungsmodi bezieht

679 828

680Um die Sandbox für jeden Entwickler zu erfordern, liefern Sie die `sandbox`-Schlüssel über [verwaltete Einstellungen](/docs/de/managed-settings#delivery-mechanisms), entweder als Datei, die von Ihrem MDM verwaltet wird, oder über [server-verwaltete Einstellungen](/docs/de/server-managed-settings) auf claude.ai.829Um die Sandbox für jeden Entwickler zu erfordern, liefern Sie die `sandbox`-Schlüssel über [verwaltete Einstellungen](/docs/de/managed-settings#delivery-mechanisms), entweder als Datei, die von Ihrem MDM verwaltet wird, oder über [server-verwaltete Einstellungen](/docs/de/server-managed-settings) auf claude.ai.

681 830

682Die 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:831Die folgende Konfiguration verwalteter Einstellungen aktiviert die Sandbox, verweigert den Start von Claude Code, wenn die Plattform nicht unterstützt wird oder eine Abhängigkeit fehlt, und verhindert, dass das Modell Befehle außerhalb der Sandbox erneut versucht:

683 832

684```json theme={null}833```json theme={null}

685{834{

693 842

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

695 844

696* **`failIfUnavailable`**: Eine fehlende Abhängigkeit wie bubblewrap auf Linux blockiert Claude Code vom Start, anstatt eine Warnung anzuzeigen und auf unsandboxed-Ausführung zurückzufallen845* **`failIfUnavailable`**: Eine fehlende Abhängigkeit wie bubblewrap auf Linux verhindert den Start von Claude Code, anstatt auf eine Ausführung ohne Sandbox zurückzufallen

697* **`allowUnsandboxedCommands: false`**: Claude Code ignoriert die `dangerouslyDisableSandbox`-Fluchtluke, daher können Befehle, die unter der Sandbox fehlschlagen, nicht außerhalb davon erneut versucht werden846* **`allowUnsandboxedCommands: false`**: Claude Code ignoriert die `dangerouslyDisableSandbox`-Fluchtluke. Wenn ein Befehl unter der Sandbox fehlschlägt, kann Claude ihn daher nicht ohne Sandbox erneut versuchen

847

848Erwägen Sie zusätzlich diese Ergänzungen:

849

850* Fügen Sie `excludedCommands` für alle von der Organisation genehmigten Tools hinzu, die ohne Isolation ausgeführt werden müssen, da diese Konfiguration [verhindert, dass die Einstellungen eines Repositorys Befehle aus der Sandbox herausnehmen](#repository-settings-under-an-admin-required-sandbox)

851* Fügen Sie [`sandbox.credentials`](#protect-credentials)-Einträge für Anmeldedaten-Verzeichnisse wie `~/.aws` und `~/.ssh` und für geheime Umgebungsvariablen hinzu, da die Standard-Leserichtlinie diese immer noch zulässt

698 852

699Zwei 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 [`sandbox.credentials`](#protect-credentials)-Einträge für Anmeldedaten-Verzeichnisse wie `~/.aws` und `~/.ssh` und für geheime Umgebungsvariablen hinzu, da die Standard-Lesrichtlinie diese immer noch zulässt.853Diese Konfiguration führt die Befehle, die Claude ausführt, in der Sandbox aus. Ein Entwickler kann immer noch einen Befehl an der [`!`-Shell-Modus-Eingabeaufforderung](/docs/de/interactive-mode#shell-mode-with-prefix) eingeben und ihn außerhalb der Sandbox ausführen, mit dem gleichen Zugriff, den er bereits in jedem Terminal außerhalb von Claude Code hat. Siehe [strikter Sandbox-Modus](#turn-off-the-retry-with-strict-sandbox-mode) für die Sitzungen, in denen eingegebene Befehle in der Sandbox ausgeführt werden.

700 854

701Diese Konfiguration sandboxed die Befehle, die Claude ausführt. Ein Entwickler kann immer noch einen Befehl an der [`!`-Shell-Modus-Eingabeaufforderung](/docs/de/interactive-mode#shell-mode-with-prefix) eingeben und ihn außerhalb der Sandbox ausführen, mit dem gleichen Zugriff, den er bereits in jedem Terminal außerhalb von Claude Code hat. Siehe [Die unsandboxed-Wiederholungs-Fluchtluke](#the-unsandboxed-retry-escape-hatch) für die Sitzungen, in denen eingegebene Befehle sandboxed ausgeführt werden.855Die Sandbox läuft nicht auf nativem Windows, daher beendet sich Claude Code auf diesen Rechnern beim Start, wenn `failIfUnavailable` gesetzt ist. Wenn Ihre Flotte Windows-Hosts enthält, können Sie:

702 856

703Die Sandbox läuft nicht auf nativem 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.857* **Die Konfiguration nach Betriebssystem ausliefern**: Stellen Sie sie über Ihr MDM oder als [Datei für verwaltete Einstellungen](/docs/de/managed-settings#delivery-mechanisms) nur auf macOS- und Linux-Rechnern bereit. [Server-verwaltete Einstellungen](/docs/de/server-managed-settings#current-limitations) gelten für alle Benutzer in der Organisation

858* **Windows-Benutzer in eine unterstützte Umgebung verlagern**: Lassen Sie sie Claude Code in WSL2 oder einem Container ausführen

704 859

705<h3 id="keep-developers-from-widening-the-policy">860<h3 id="keep-developers-from-widening-the-policy">

706 Verhindern Sie, dass Entwickler die Richtlinie erweitern861 Verhindern Sie, dass Entwickler die Richtlinie erweitern

707</h3>862</h3>

708 863

709Fü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.864Wenn verwaltete Einstellungen einen booleschen Schlüssel wie `enabled` oder `failIfUnavailable` setzen, verwendet Claude Code den verwalteten Wert und ignoriert alles, was ein Entwickler lokal setzt. Für Array-Schlüssel wie `allowRead` führt Claude Code Einträge aus den Geltungsbereichen zusammen, die die Sitzung lädt, daher kann ein Entwickler Einträge anhängen, die die Richtlinie erweitern, sofern keine Sperre diesen Schlüssel abdeckt.

710 865

711Setzen Sie `allowManagedReadPathsOnly` auf `true` in verwalteten Einstellungen, damit nur `allowRead`-Einträge aus verwalteten Einstellungen berücksichtigt werden. 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`](/docs/de/settings-reference#sandbox-network-allowmanageddomainsonly).866Sofern verwaltete Einstellungen sie nicht setzen, können die Benutzereinstellungen eines Entwicklers oder `--settings` die folgenden Schlüssel einschalten. Die `.claude/settings.json` eines Repositorys kann dies ebenfalls, es sei denn, die Sandbox ist [vom Administrator erforderlich](#repository-settings-under-an-admin-required-sandbox). Jeder dieser Schlüssel schwächt die Sandbox, setzen Sie ihn daher in verwalteten Einstellungen auf `false`, wenn Sie nicht möchten, dass er verwendet wird:

867

868* [`enableWeakerNestedSandbox`](/docs/de/settings-reference#sandbox-enableweakernestedsandbox)

869* [`enableWeakerNetworkIsolation`](/docs/de/settings-reference#sandbox-enableweakernetworkisolation)

870* [`network.allowAllUnixSockets`](/docs/de/settings-reference#sandbox-network-allowallunixsockets)

871* [`network.allowLocalBinding`](/docs/de/settings-reference#sandbox-network-allowlocalbinding)

872* [`allowAppleEvents`](/docs/de/settings-reference#sandbox-allowappleevents), den ein Repository nicht einschalten kann

873

874Setzen Sie `allowManagedReadPathsOnly` auf `true` in verwalteten Einstellungen, damit nur `allowRead`-Einträge aus verwalteten Einstellungen berücksichtigt werden. Dies verhindert, dass Entwickler den Lesezugriff über die von der Organisation genehmigten Pfade hinaus erweitern.

875

876Um Netzwerk-Domains auf die gleiche Weise auf die verwalteten Werte zu sperren, setzen Sie [`allowManagedDomainsOnly`](/docs/de/settings-reference#sandbox-network-allowmanageddomainsonly). Bei aktiver Sperre können nur verwaltete Einstellungen einen [Proxy-Port](#custom-proxy-configuration) setzen.

712 877

713Wenn verwaltete Einstellungen `sandbox.filesystem` konfigurieren oder einen beliebigen `sandbox.credentials.files`-Eintrag mit `"mode": "deny"` auflisten, können nur verwaltete Einstellungen [`filesystem.disabled`](#disable-filesystem-isolation) setzen, daher können Entwickler von Administratoren bereitgestellte Filesystem-Einschränkungen nicht ausschalten. Ob ein `mask`-Eintrag den Schlüssel fixiert, hängt davon ab, wie er sich auflöst; die Tabelle unter [Welche Einstellungen können es deaktivieren](#which-settings-can-disable-it) behandelt die vier Fälle.878Wenn verwaltete Einstellungen `sandbox.filesystem` konfigurieren oder einen beliebigen `sandbox.credentials.files`-Eintrag mit `"mode": "deny"` auflisten, können nur verwaltete Einstellungen [`filesystem.disabled`](#disable-filesystem-isolation) setzen, daher können Entwickler von Administratoren bereitgestellte Filesystem-Einschränkungen nicht ausschalten. Ob ein `mask`-Eintrag den Schlüssel fixiert, hängt davon ab, wie er sich auflöst; die Tabelle unter [Welche Einstellungen können es deaktivieren](#which-settings-can-disable-it) behandelt die vier Fälle.

714 879

715`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.880<h4 id="repository-settings-under-an-admin-required-sandbox">

881 Repository-Einstellungen bei einer vom Administrator erforderlichen Sandbox

882</h4>

883

884Die Sandbox ist vom Administrator erforderlich, solange eine dieser Einstellungen wirksam ist:

885

886* [`allowUnsandboxedCommands`](/docs/de/settings-reference#sandbox-allowunsandboxedcommands) ist in verwalteten Einstellungen auf `false` gesetzt, oder mit dem `--settings`-Flag, sofern verwaltete Einstellungen es nicht auf `true` setzen

887* [`allowManagedDomainsOnly`](/docs/de/settings-reference#sandbox-network-allowmanageddomainsonly) ist in verwalteten Einstellungen auf `true` gesetzt

888

889Diese Einstellungen schalten die Sandbox nicht ein, setzen Sie daher auch `enabled`.

890

891Solange die Sandbox vom Administrator erforderlich ist, übernimmt Claude Code die Einstellungen, die sie lockern, nur aus verwalteten Einstellungen, dem `--settings`-Flag und der `~/.claude/settings.json` jedes Entwicklers. Diese Einstellungen in der `.claude/settings.json` und `.claude/settings.local.json` eines Repositorys ignoriert es:

892

893| Repository-Einstellung | Was Claude Code ignoriert |

894| :- | :- |

895| `excludedCommands`, `ignoreViolations`, `network.allowedDomains`, `network.allowUnixSockets`, `network.allowMachLookup`, `network.httpProxyPort`, `network.socksProxyPort` | Jeden Eintrag |

896| `filesystem.allowWrite`, `Edit(...)`-Allow-Regeln, `permissions.additionalDirectories` | Den Schreibzugriff, den jeder Eintrag Befehlen in der Sandbox gewährt. Claudes Datei-Tools befolgen weiterhin die `Edit(...)`-Regeln und zusätzlichen Verzeichnisse |

897| `WebFetch(domain:...)`-Allow-Regeln | Den Host, den jede Regel zur Sandbox-Allowlist hinzufügt. Das WebFetch-Tool befolgt die Regel weiterhin |

898| `enableWeakerNestedSandbox`, `enableWeakerNetworkIsolation`, `network.allowAllUnixSockets`, `network.allowLocalBinding` | `true`. Ein `false` gilt weiterhin |

899| `enabled`, `failIfUnavailable` | `false`, wenn die `~/.claude/settings.json` des Entwicklers `true` setzt |

900| `filesystem.allowRead` | Einen Eintrag an oder unterhalb eines Pfads, dessen Lesen verwaltete Einstellungen, `--settings` oder Benutzereinstellungen verweigern, oder ein Glob, der einen solchen treffen könnte |

901

902Diese Einstellungen gelten weiterhin, solange die Sandbox vom Administrator erforderlich ist:

903

904* **In den Dateien eines Repositorys**: Deny-Einträge und der Wert von `autoAllowBashIfSandboxed`. Setzen Sie den Schlüssel in verwalteten Einstellungen, um zu verhindern, dass ein Repository ihn ändert

905* **In den eigenen Einstellungen eines Entwicklers**: Die Einstellungen aus der Tabelle gelten weiterhin aus `~/.claude/settings.json` oder `--settings`, sofern keine nur verwaltete Sperre wie `allowManagedDomainsOnly` sie abdeckt. Die meisten davon, etwa `excludedCommands` und `filesystem.allowWrite`, haben keine nur verwaltete Sperre

906

907Die Konfiguration unter [Erzwingen Sie Sandboxing mit verwalteten Einstellungen](#enforce-sandboxing-with-managed-settings) macht die Sandbox vom Administrator erforderlich. Fügen Sie die `excludedCommands`-, `allowWrite`- und Socket-Einträge, die Ihre genehmigten Tools benötigen, zu verwalteten Einstellungen hinzu, da ein Repository sie nicht bereitstellen kann.

908

909Erfordert Claude Code v2.1.285 oder höher. Von v2.1.282 bis v2.1.284 führten dieselben Einstellungen dazu, dass Claude Code die `excludedCommands`-Einträge eines Repositorys ignorierte.

910

911<h4 id="locks-that-apply-without-an-admin-required-sandbox">

912 Sperren, die ohne eine vom Administrator erforderliche Sandbox gelten

913</h4>

914

915Einige Einstellungen führen dazu, dass Claude Code die Repository-Schlüssel ignoriert, die eine Einschränkung direkt überschreiben, selbst wenn die Sandbox nicht vom Administrator erforderlich ist. Jede davon hat diese Wirkung nur, wenn Sie sie in einer Datei setzen, die in ihrer Zeile genannt ist, und die anderen Sandbox-Einstellungen des Repositorys gelten weiterhin. Erfordert Claude Code v2.1.285 oder höher.

916

917| Einstellung | Wo Sie sie setzen | Was Claude Code in den Einstellungen eines Repositorys ignoriert |

918| :- | :- | :- |

919| `network.deniedDomains` oder eine `WebFetch(domain:...)`-Deny-Regel | Verwaltete Einstellungen, `--settings` | `httpProxyPort` und `socksProxyPort` |

920| `network.strictAllowlist` | Verwaltete Einstellungen, `--settings`, Benutzereinstellungen | Die Proxy-Ports, `allowedDomains` und `WebFetch(domain:...)`-Allow-Regeln |

921| `filesystem.denyRead`, eine `Read(...)`-Deny-Regel oder ein `credentials.files`-Eintrag | Verwaltete Einstellungen, `--settings` | Einen `allowRead`-, `allowWrite`-, `Edit(...)`-Allow- oder `additionalDirectories`-Eintrag an oder unterhalb eines Pfads, dessen Lesen verwaltete Einstellungen, `--settings` oder Benutzereinstellungen verweigern, oder ein Glob, der einen solchen treffen könnte |

922

923Diese Sperren ändern, was Befehle in der Sandbox erreichen können. Das WebFetch-Tool und Claudes Datei-Tools befolgen weiterhin die Regeln und zusätzlichen Verzeichnisse eines Repositorys.

716 924

717<h3 id="custom-proxy-configuration">925<h3 id="custom-proxy-configuration">

718 Benutzerdefinierte Proxy-Konfiguration926 Benutzerdefinierte Proxy-Konfiguration

719</h3>927</h3>

720 928

721Für Organisationen, die erweiterte Netzwerk-Sicherheit erfordern, können Sie einen benutzerdefinierten Proxy implementieren, um:929Um Sandbox-Datenverkehr mit Ihren eigenen Tools zu inspizieren, zu filtern oder zu protokollieren, ersetzen Sie den integrierten Sandbox-Proxy durch einen Proxy, den Sie auf demselben Rechner betreiben.

722 930

723* HTTPS-Datenverkehr zu entschlüsseln und zu inspizieren931Um Sandbox-Datenverkehr stattdessen durch einen Unternehmens-Proxy an anderer Stelle in Ihrem Netzwerk zu leiten, setzen Sie `HTTPS_PROXY`, wie es der Eintrag **Unternehmens-Proxy** unter [Netzwerkisolation](#network-isolation) beschreibt. Auf diese Weise gilt die Allowlist von Claude Code weiterhin.

724* Benutzerdefinierte Filterregeln anzuwenden

725* Alle Netzwerk-Anfragen zu protokollieren

726* Mit bestehender Sicherheitsinfrastruktur zu integrieren

727 932

728Um Claude Code auf Ihren Proxy zu verweisen, setzen Sie die Proxy-Ports in [Sandbox-Einstellungen](/docs/de/settings-reference#sandbox-settings):933Um Befehle in der Sandbox an Ihren Proxy zu leiten, setzen Sie die localhost-Ports, auf denen er lauscht, in [Sandbox-Einstellungen](/docs/de/settings-reference#sandbox-settings):

729 934

730```json theme={null}935```json theme={null}

731{936{

738}943}

739```944```

740 945

946Wenn Sie einen Port setzen und außerdem `HTTPS_PROXY` oder `HTTP_PROXY` setzen, leitet Claude Code das, was Befehle in der Sandbox an Ihren Proxy senden, nicht an den Proxy weiter, den diese Variablen nennen. Um einen Unternehmens-Proxy zu erreichen, konfigurieren Sie Ihren eigenen Proxy so, dass er an diesen weiterleitet.

947

948Welche Dateien einen Port setzen können, hängt von Ihren anderen Sandbox-Einstellungen ab:

949

950* **`allowManagedDomainsOnly` ist aktiviert**: nur verwaltete Einstellungen

951* **Die Sandbox ist [vom Administrator erforderlich](#repository-settings-under-an-admin-required-sandbox), oder eine [engere Netzwerksperre](#locks-that-apply-without-an-admin-required-sandbox) gilt**: verwaltete Einstellungen, `--settings` und Benutzereinstellungen

952* **Andernfalls**: jede Einstellungsdatei

953

954Claude Code ignoriert einen Port, der an anderer Stelle gesetzt ist. Vor v2.1.285 konnte jede Einstellungsdatei einen Port setzen.

955

956<Warning>

957 Sobald einer der beiden Ports gilt, ist Ihr Proxy dafür verantwortlich, alles zu filtern, was an ihn gesendet wird. Die eigenen Netzwerkkontrollen von Claude Code, wie `allowedDomains`, `deniedDomains`, `strictAllowlist`, Genehmigungsabfragen und die [Prüfung auf lokale Adressen](#hostnames-that-resolve-to-local-addresses), gelten für diesen Datenverkehr nicht mehr. Ein Befehl in der Sandbox kann sich mit jedem der beiden Proxys verbinden. Wenn Sie also nur einen Port setzen, begrenzen die Domain-Listen von Claude Code auf dem anderen Proxy nicht, was der Befehl über Ihren Proxy erreicht.

958</Warning>

959

741<h2 id="troubleshooting">960<h2 id="troubleshooting">

742 Fehlerbehebung961 Fehlerbehebung

743</h2>962</h2>

744 963

745Einige Befehle schlagen in der Sandbox fehl, obwohl sie außerhalb funktionieren. Die folgenden Lösungen decken die häufigsten Fälle ab.964Einige Befehle schlagen in der Sandbox fehl, obwohl sie außerhalb funktionieren. Die folgende Liste enthält kurze Lösungen. Fehler, die eine längere Erklärung erfordern, haben jeweils eine eigene Überschrift.

965

966Wenn die Sandbox Ihrer Organisation [vom Administrator vorgeschrieben](#repository-settings-under-an-admin-required-sandbox) ist, ignoriert Claude Code die in diesen Lösungen genannten Einstellungen in den Einstellungsdateien eines Projekts. Speichern Sie sie daher in `~/.claude/settings.json`, wo sie in jedem Projekt gelten. Wenn eine Lösung trotzdem keine Wirkung zeigt, setzen die verwalteten Einstellungen Ihrer Organisation möglicherweise diesen Schlüssel.

967

968Eine Lösung, die ein `excludedCommands`-Muster hinzufügt, nimmt die Befehle, auf die das Muster zutrifft, aus der Sandbox heraus. Siehe [was ein ausgeschlossener Befehl tun kann](#run-commands-outside-the-sandbox-with-excludedcommands).

746 969

747* **Befehle schlagen mit einem host-not-allowed-Fehler fehl**: Viele CLI-Tools müssen bestimmte Hosts erreichen. Wenn Sie die Berechtigung bei der Aufforderung erteilen, wird der Host zu Ihrer Zulassungsliste hinzugefügt, damit das Tool in Zukunft in der Sandbox ausgeführt wird.970* **Befehle schlagen mit einem host-not-allowed-Fehler fehl**: Viele CLI-Tools müssen bestimmte Hosts erreichen. Genehmigen Sie den Host, wenn Sie gefragt werden, oder fügen Sie ihn zu [`allowedDomains`](/docs/de/settings-reference#sandbox-network-alloweddomains) hinzu. Wenn Ihre Organisation die Allowlist mit `allowManagedDomainsOnly` sperrt, erscheint keine Abfrage; bitten Sie in diesem Fall Ihren Administrator, den Host hinzuzufügen.

748* **`jest` hängt oder schlägt fehl**: `watchman` ist nicht kompatibel mit der Sandbox. Führen Sie stattdessen `jest --no-watchman` aus.971* **`jest` hängt oder schlägt fehl**: `watchman` ist nicht kompatibel mit der Sandbox. Führen Sie stattdessen `jest --no-watchman` aus.

749* **Go-basierte CLIs schlagen bei der TLS-Verifizierung auf macOS fehl**: Tools wie `gh`, `gcloud` und `terraform` können unter Seatbelt bei der TLS-Verifizierung fehlschlagen. Listen Sie diese Tools in [`excludedCommands`](/docs/de/settings-reference#sandbox-excludedcommands) auf. Wenn Sie `httpProxyPort` mit einem MITM-Proxy und einer benutzerdefinierten CA verwenden, setzen Sie stattdessen [`enableWeakerNetworkIsolation`](/docs/de/settings-reference#sandbox-enableweakernetworkisolation) auf `true`.972* **Go-basierte CLIs schlagen bei der TLS-Verifizierung auf macOS fehl**: Tools wie `gh`, `gcloud` und `terraform` können unter Seatbelt bei der TLS-Verifizierung fehlschlagen. Fügen Sie für jedes Tool ein Muster wie `gh *` zu [`excludedCommands`](#run-commands-outside-the-sandbox-with-excludedcommands) hinzu. Das Tool läuft dann mit Ihrem vollen Zugriff und seinen gespeicherten Anmeldedaten. Wenn Sie `httpProxyPort` mit einem MITM-Proxy und einer benutzerdefinierten CA verwenden, setzen Sie stattdessen [`enableWeakerNetworkIsolation`](/docs/de/settings-reference#sandbox-enableweakernetworkisolation) auf `true`.

750* **`open`, `osascript` oder browserbasierte Authentifizierungsabläufe schlagen mit Fehler `-600` auf macOS fehl**: Die Sandbox blockiert Apple Events standardmäßig. Setzen Sie [`allowAppleEvents`](/docs/de/settings-reference#sandbox-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 sandboxed-Befehle dann andere Anwendungen ohne Sandbox ohne Benutzereingabeaufforderung 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`](/docs/de/settings-reference#sandbox-excludedcommands) hinzufügen.973* **`open`, `osascript` oder browserbasierte Authentifizierungsabläufe schlagen mit Fehler `-600` auf macOS fehl**: Die Sandbox blockiert Apple Events standardmäßig. Setzen Sie [`allowAppleEvents`](/docs/de/settings-reference#sandbox-allowappleevents) in Ihren Benutzer-, verwalteten oder CLI-Einstellungen auf `true`, um diese zuzulassen. Projekteinstellungen werden für diesen Schlüssel ignoriert. Das Aktivieren hebt die Isolation der Codeausführung auf, da in der Sandbox ausgeführte Befehle dann ohne Benutzerabfrage andere Anwendungen außerhalb der Sandbox starten und AppleScript-Befehle an laufende Anwendungen senden können, vorbehaltlich der macOS-Abfrage zur Automatisierungszustimmung (TCC). Alternativ können Sie ein Muster wie `open *` zu [`excludedCommands`](#run-commands-outside-the-sandbox-with-excludedcommands) hinzufügen. Jeder `open`-Aufruf durchläuft dann den Berechtigungsablauf, und `open` kann jede Datei oder App starten, auch eine, die Claude geschrieben hat.

751* **`docker`-Befehle schlagen fehl**: `docker` ist nicht kompatibel mit der Sandbox. Fügen Sie `docker *` zu [`excludedCommands`](/docs/de/settings-reference#sandbox-excludedcommands) hinzu.974* **`docker`-Befehle schlagen fehl**: `docker` ist nicht kompatibel mit der Sandbox. Nehmen Sie die benötigten `docker`-Befehle mit einem [`excludedCommands`](#run-commands-outside-the-sandbox-with-excludedcommands)-Muster wie `docker compose *` aus der Sandbox heraus. Dieser Abschnitt erklärt, was ein ausgeschlossener `docker`-Befehl erreichen kann. Ein engeres Muster nimmt weniger Befehle aus der Sandbox heraus.

752* **`pbcopy`, `xclip` oder `wl-copy` aktualisiert die Zwischenablage nicht**: Diese Zwischenablage-Dienstprogramme können aus der Sandbox heraus die Systemzwischenablage nicht erreichen, in welchem Fall der Text, der an sie weitergeleitet wird, nicht ankommt.975* **`pbcopy`, `xclip` oder `wl-copy` aktualisiert die Zwischenablage nicht**: Diese Zwischenablage-Dienstprogramme können aus der Sandbox heraus die Systemzwischenablage möglicherweise nicht erreichen, in welchem Fall der Text, der an sie weitergeleitet wird, nicht ankommt.

753 976

754 Um Claudes Ausgabe in Ihre Zwischenablage zu kopieren, bitten Sie Claude, sie in seiner Antwort auszudrucken, und führen Sie dann [`/copy`](/docs/de/commands) aus. `/copy` schreibt aus dem Claude Code-Prozess in die Zwischenablage, nicht aus einem sandboxed-Befehl.977 Um Claudes Ausgabe in Ihre Zwischenablage zu kopieren, bitten Sie Claude, sie in seiner Antwort auszugeben, und führen Sie dann [`/copy`](/docs/de/commands) aus. `/copy` schreibt aus dem Claude Code-Prozess in die Zwischenablage, nicht aus einem in der Sandbox ausgeführten Befehl.

755 978

756 Wenn Claude Text an eines dieser Tools weiterleitet, führt das Hinzufügen des Tools zu [`excludedCommands`](/docs/de/settings-reference#sandbox-excludedcommands) diesen Aufruf nicht automatisch aus der Sandbox heraus.979 Wenn Claude Text an eines dieser Tools weiterleitet, nimmt das Hinzufügen des Tools zu [`excludedCommands`](/docs/de/settings-reference#sandbox-excludedcommands) diesen Aufruf nicht von sich aus aus der Sandbox heraus.

757* **Ein git-Befehl schlägt mit `unable to unlink old` fehl**: `git merge`, `git checkout` und ähnliche Befehle schlagen auf diese Weise fehl, wenn sie eine Datei ersetzen müssen, in die die Sandbox Schreibvorgänge verweigert, unabhängig davon, ob sich diese Datei unter einem [geschützten Pfad](#protected-paths) wie `.claude/skills` befindet, unter einem Ihrer `denyWrite`-Einträge oder außerhalb der Verzeichnisse, in die die Sandbox Befehle überhaupt schreiben lässt. Unter Linux und WSL2 endet der Fehler mit `Read-only file system`.980* **Ein git-Befehl schlägt mit `unable to unlink old` fehl**: `git merge`, `git checkout` und ähnliche Befehle schlagen auf diese Weise fehl, wenn sie eine Datei ersetzen müssen, in die die Sandbox Schreibvorgänge verweigert, unabhängig davon, ob sich diese Datei unter einem [geschützten Pfad](#protected-paths) wie `.claude/skills` befindet, unter einem Ihrer `denyWrite`-Einträge oder außerhalb der Verzeichnisse, in die die Sandbox Befehle überhaupt schreiben lässt. Unter Linux und WSL2 endet der Fehler mit `Read-only file system`.

758 981

759 Nach dem Fehler kann Claude [anbieten, den Befehl außerhalb der Sandbox erneut auszuführen](#the-unsandboxed-retry-escape-hatch); genehmigen Sie diesen erneuten Versuch, oder führen Sie den git-Befehl selbst in einem anderen Terminal aus. Wenn Sie `allowUnsandboxedCommands` auf `false` gesetzt haben, kann Claude den erneuten Versuch nicht anbieten, also führen Sie den Befehl selbst aus. Wenn derselbe git-Befehl häufig fehlschlägt, fügen Sie ihn zu [`excludedCommands`](/docs/de/settings-reference#sandbox-excludedcommands) hinzu.982 Nach dem Fehler kann Claude [anbieten, den Befehl außerhalb der Sandbox erneut auszuführen](#the-unsandboxed-retry-escape-hatch); genehmigen Sie diesen Wiederholungsversuch, oder führen Sie den git-Befehl selbst in einem anderen Terminal aus. Wenn Sie `allowUnsandboxedCommands` auf `false` gesetzt haben, kann Claude den Wiederholungsversuch nicht anbieten, also führen Sie den Befehl selbst aus.

760* **Bubblewrap schlägt fehl, um in einem Container zu starten**: In einem unprivilegierten Container kann bubblewrap kein neues `/proc`-Dateisystem bereitstellen, daher schlagen sandboxed-Befehle mit einem `bwrap`-Fehler wie `Can't mount proc on /newroot/proc: Operation not permitted` fehl. Setzen Sie [`enableWeakerNestedSandbox`](/docs/de/settings-reference#sandbox-enableweakernestedsandbox) auf `true`, damit die innere Sandbox das vorhandene `/proc` des Containers stattdessen bind-mounted. Verwenden Sie diese Einstellung nur, wenn der äußere Container bereits die Isolationsgrenze bietet, die Sie benötigen, da sie Prozessinformationen für sandboxed-Befehle verfügbar macht, die eine neue `/proc`-Bereitstellung verbergen würde.983* **Bubblewrap startet in einem Container nicht**: In einem unprivilegierten Container kann bubblewrap kein neues `/proc`-Dateisystem einhängen, daher schlagen in der Sandbox ausgeführte Befehle mit einem `bwrap`-Fehler wie `Can't mount proc on /newroot/proc: Operation not permitted` fehl. Setzen Sie [`enableWeakerNestedSandbox`](/docs/de/settings-reference#sandbox-enableweakernestedsandbox) auf `true`, damit die innere Sandbox stattdessen das vorhandene `/proc` des Containers per Bind-Mount einbindet. Verwenden Sie diese Einstellung nur, wenn der äußere Container bereits die Isolationsgrenze bietet, die Sie benötigen, da sie in der Sandbox ausgeführten Befehlen Prozessinformationen zugänglich macht, die ein neu eingehängtes `/proc` verbergen würde.

761* **0-Byte-Dateien mit Schreibschutz erscheinen in `.claude`-Einstellungspfaden, und „Ja, und nicht mehr fragen" wird nicht gespeichert**: Unter Linux und WSL2 hält die Sandbox einen Schreibverweigerung auf einer Datei, die noch nicht existiert, indem sie dort einen 0-Byte-Platzhalter mit Schreibschutz erstellt, während ein sandboxed-Befehl ausgeführt wird. Die Sandbox entfernt den Platzhalter danach. Wenn eine Sitzung vor dieser Bereinigung beendet wird, beispielsweise durch SIGKILL, bleiben die Platzhalter bestehen. Spätere Sitzungen binden sie bei jedem Start erneut schreibgeschützt, daher schlägt ein Einstellungsschreibvorgang wie das Speichern einer Berechtigungswahl fehl, wenn einer vorhanden ist.984* **Schreibgeschützte 0-Byte-Dateien erscheinen in `.claude`-Einstellungspfaden, und „Ja, und nicht mehr fragen" wird nicht gespeichert**: Unter Linux und WSL2 setzt die Sandbox eine Schreibsperre für eine noch nicht existierende Datei durch, indem sie dort einen schreibgeschützten 0-Byte-Platzhalter erstellt, während ein Befehl in der Sandbox ausgeführt wird. Die Sandbox entfernt den Platzhalter danach. Wenn eine Sitzung vor dieser Bereinigung beendet wird, beispielsweise durch SIGKILL, bleiben die Platzhalter bestehen. Spätere Sitzungen binden sie bei jedem Start erneut schreibgeschützt ein, daher schlägt ein Schreibvorgang in die Einstellungen, etwa das Speichern einer Berechtigungswahl, dort fehl, wo einer vorhanden ist.

762 985

763 Führen Sie `claude doctor` aus, um die verbleibenden Platzhalter-Dateien aufzulisten. Die Warnung [`Stale sandbox mask files left by a killed session`](/docs/de/errors#stale-sandbox-mask-files-left-by-a-killed-session) nennt bis zu drei davon und zählt den Rest. Löschen Sie jede Datei mit `rm`, während keine andere Claude Code-Sitzung in diesem Projekt ausgeführt wird. Vor v2.1.257 ließ Claude Code dieselben Platzhalter ohne Kennzeichnung zurück.986 Führen Sie `claude doctor` aus, um die verbleibenden Platzhalter-Dateien aufzulisten. Die Warnung [`Stale sandbox mask files left by a killed session`](/docs/de/errors#stale-sandbox-mask-files-left-by-a-killed-session) nennt bis zu drei davon und zählt den Rest. Löschen Sie jede Datei mit `rm`, während keine andere Claude Code-Sitzung in diesem Projekt ausgeführt wird. Vor v2.1.257 ließ Claude Code dieselben Platzhalter ohne Kennzeichnung zurück.

764* **`--dangerously-skip-permissions` schlägt als root fehl**: Dieses Flag wird blockiert, wenn es als root oder über sudo unter Linux und macOS ausgeführt wird, da root-Zugriff kombiniert mit keinen Berechtigungsaufforderungen jede Datei oder jeden Dienst auf dem System ändern kann. Die Überprüfung wird automatisch in einer erkannten Sandbox übersprungen. Um autonom in einem Container zu laufen, verwenden Sie die [dev container](/docs/de/devcontainer)-Konfiguration, die Claude Code als Nicht-Root-Benutzer ausführt.987* **`--dangerously-skip-permissions` schlägt als root fehl**: Dieses Flag wird blockiert, wenn es als root oder über sudo unter Linux und macOS ausgeführt wird, da root-Zugriff in Kombination mit fehlenden Berechtigungsabfragen jede Datei und jeden Dienst auf dem System ändern kann. Die Überprüfung wird in einer erkannten Sandbox automatisch übersprungen. Um autonom in einem Container zu laufen, verwenden Sie die [Dev-Container](/docs/de/devcontainer)-Konfiguration, die Claude Code als Nicht-Root-Benutzer ausführt.

988

989<h3 id="git-over-ssh-fails-with-the-sandbox-on">

990 `git` über SSH schlägt bei aktivierter Sandbox fehl

991</h3>

992

993Unter macOS schlagen `git fetch`, `git pull` und `git push` gegen ein SSH-Remote in der Sandbox fehl, selbst wenn der Host zugelassen ist. Unter Linux und WSL2 funktionieren sie, sobald der Host zugelassen ist. Claude Code tunnelt die SSH-Verbindung von git durch den [Sandbox-Proxy](#network-isolation), und der macOS-Tunnel kann sich nicht bei diesem Proxy authentifizieren.

994

995Prüfen Sie unter Linux und WSL2 Folgendes, wenn die Verbindung weiterhin fehlschlägt:

996

997* **Der Host ist auf Port 22 zugelassen**: Ein `allowedDomains`-Eintrag ohne Port, etwa `"git.example.com"`, deckt dies ab

998* **Ihr Unternehmensproxy lässt Port 22 zu**: Wenn Ihr Netzwerk einen Upstream-Proxy erfordert, läuft auch der Tunnel darüber

999* **Der Schlüssel ist als Datei lesbar**: Die Sandbox kann den `ssh-agent`-Socket blockieren, und ein `denyRead`- oder `credentials`-Eintrag für `~/.ssh` verbirgt Ihre Schlüsseldateien

1000

1001Stellen Sie unter macOS das Remote auf HTTPS um, wofür HTTPS-Anmeldedaten wie ein Personal Access Token erforderlich sind:

1002

1003```bash theme={null}

1004git remote set-url origin https://git.example.com/example-org/example-repo.git

1005```

1006

1007Wenn Sie das SSH-Remote beibehalten müssen, nehmen Sie die Netzwerkbefehle von git mit [`excludedCommands`](#run-commands-outside-the-sandbox-with-excludedcommands) aus der Sandbox heraus:

1008

1009```json theme={null}

1010{

1011 "sandbox": {

1012 "excludedCommands": ["git fetch *", "git pull *", "git push *"]

1013 }

1014}

1015```

1016

1017Diese Einträge treffen auf `git push origin main` zu. Ein Aufruf, der ein `cd` hinzufügt, `git -C` verwendet oder eine Befehlssubstitution enthält, bleibt in der Sandbox. Die ausgeschlossenen git-Befehle können jeden Host erreichen, nicht nur die in `allowedDomains`.

1018

1019Einfaches `ssh`, `scp` und `rsync` über SSH schlagen aus dem Grund fehl, den [der Eintrag zu Datenbank-Clients](#a-database-client-or-other-non-http-tool-fails-to-reach-an-allowed-host) nennt.

1020

1021<h3 id="a-database-client-or-other-non-http-tool-fails-to-reach-an-allowed-host">

1022 Ein Datenbank-Client oder ein anderes Nicht-HTTP-Tool erreicht einen zugelassenen Host nicht

1023</h3>

1024

1025Ein Tool, das die Proxy-Umgebungsvariablen ignoriert, kann sich aus der Sandbox heraus nicht verbinden, nicht einmal mit einem Host in `allowedDomains`. Ein in der Sandbox ausgeführter Befehl hat [keinen direkten Weg ins Netzwerk](#network-isolation), daher schlägt ein Tool fehl, das seine eigene Verbindung öffnet. Die meisten Datenbanktreiber, einfaches `ssh` und Tools, die UDP verwenden, verhalten sich so.

1026

1027Der Fehler sieht wie ein Netzwerk- oder Namensauflösungsfehler aus:

1028

1029* **macOS**: `Operation not permitted` oder ein Namensauflösungsfehler wie `Could not resolve host`

1030* **Linux und WSL2**: `Network is unreachable` oder ein Namensauflösungsfehler wie `Temporary failure in name resolution`

1031

1032Ein Tool, das den Proxy verwendet, schlägt anders fehl, wenn sein Host nicht zugelassen ist. Sie erhalten eine Netzwerkabfrage, oder das Tool erhält eine `403`-Antwort vom Proxy.

1033

1034Damit sich das Tool verbinden kann, führen Sie den Befehl, der es benötigt, mit [`excludedCommands`](#run-commands-outside-the-sandbox-with-excludedcommands) außerhalb der Sandbox aus. Dieses Beispiel schließt ein Skript aus und fügt eine [Ask-Regel](/docs/de/permissions) hinzu, sodass Sie jede Ausführung genehmigen:

1035

1036```json theme={null}

1037{

1038 "sandbox": {

1039 "excludedCommands": ["python scripts/load_orders.py *"]

1040 },

1041 "permissions": {

1042 "ask": ["Bash(python scripts/load_orders.py *)"]

1043 }

1044}

1045```

1046

1047Das Skript läuft mit Ihrem vollen Zugriff, und Claude kann ein Skript bearbeiten, das sich in Ihrem Arbeitsverzeichnis befindet. Prüfen Sie es daher, wenn die Abfrage erscheint.

1048

1049<h3 id="a-command-fails-to-reach-a-server-on-localhost">

1050 Ein Befehl erreicht einen Server auf localhost nicht

1051</h3>

1052

1053Standardmäßig kann sich ein in der Sandbox ausgeführter Befehl nicht direkt mit einem Server verbinden, der auf Ihrem Rechner außerhalb der Sandbox läuft, etwa einem Dev-Server oder einer Datenbank in einem Container. Was Sie ändern können, hängt von Ihrer Plattform ab:

1054

1055* **macOS**: Setzen Sie [`network.allowLocalBinding`](/docs/de/settings-reference#sandbox-network-allowlocalbinding) auf `true`. In der Sandbox ausgeführte Befehle können dann auf Netzwerkports lauschen und sich mit jedem Port auf localhost verbinden, was jeden anderen dort lauschenden Dienst einschließt. Ein localhost-Dienst, der keine Authentifizierung erfordert, etwa ein Debugger, kann dann für den Befehl außerhalb der Sandbox handeln, und ein Befehl, der auf einer Nicht-Loopback-Adresse lauscht, nimmt Verbindungen von anderen Rechnern an

1056* **Linux und WSL2**: Das `localhost` eines in der Sandbox ausgeführten Befehls ist privat für diesen Befehl. Der Befehl kann auf einem Port lauschen und Server erreichen, die er selbst gestartet hat. Eine direkte Verbindung zu `localhost` oder `127.0.0.1` erreicht keine Server auf dem Host, und `allowLocalBinding` hat keine Wirkung. Führen Sie den Befehl, der den Server des Hosts benötigt, mit [`excludedCommands`](#run-commands-outside-the-sandbox-with-excludedcommands) außerhalb der Sandbox aus, wo er keinen Dateisystem- oder Netzwerkbeschränkungen unterliegt. Für Verbindungen, die über den Sandbox-Proxy laufen, siehe [Hostnamen, die zu lokalen Adressen aufgelöst werden](#hostnames-that-resolve-to-local-addresses)

1057

1058Dieses Beispiel aktiviert die Einstellung für macOS:

1059

1060```json theme={null}

1061{

1062 "sandbox": {

1063 "network": {

1064 "allowLocalBinding": true

1065 }

1066 }

1067}

1068```

1069

1070Ein `allowedDomains`-Eintrag für `localhost` gilt für Verbindungen, die über den Proxy laufen, und ändert daher keine direkte Verbindung. Claude Code setzt `NO_PROXY` für in der Sandbox ausgeführte Befehle, damit sie sich direkt statt über den Proxy mit `localhost` verbinden. Der Eintrag macht außerdem jeden Port auf dem localhost Ihres Rechners für einen Befehl zugänglich, der den Proxy tatsächlich verwendet. Für einen Entwicklungs-Hostnamen, der auf `127.0.0.1` zeigt, siehe [Ein zugelassener Hostname wird mit `resolved to a loopback address` abgelehnt](#an-allowed-hostname-is-refused-with-resolved-to-a-loopback-address).

1071

1072<h3 id="an-allowed-hostname-is-refused-with-resolved-to-a-loopback-address">

1073 Ein zugelassener Hostname wird mit `resolved to a loopback address` abgelehnt

1074</h3>

1075

1076Der Sandbox-Proxy lehnt einen zugelassenen Hostnamen ab, der [zu einer lokalen Adresse aufgelöst wird](#hostnames-that-resolve-to-local-addresses). Das betrifft Entwicklungsnamen wie `myapp.test`, die auf `127.0.0.1` zeigen. Der Befehl erhält eine `403`-Antwort, deren Response-Body die Art der Adresse nennt, etwa `Connection to myapp.test blocked: resolved to a loopback address`.

1077

1078Fügen Sie die IP-Adresse, zu der der Name aufgelöst wird, zusammen mit dem Hostnamen zu `allowedDomains` hinzu, jeweils mit dem Port, auf dem Ihr Server lauscht:

1079

1080```json theme={null}

1081{

1082 "sandbox": {

1083 "network": {

1084 "allowedDomains": ["myapp.test:3000", "127.0.0.1:3000"]

1085 }

1086 }

1087}

1088```

1089

1090Ein IP-Adress-Eintrag ohne Port ermöglicht in der Sandbox ausgeführten Befehlen, jeden Dienst zu erreichen, der auf dieser Adresse lauscht.

1091

1092Vor v2.1.284 verband sich der Proxy mit der Adresse, zu der ein zugelassener Hostname aufgelöst wurde, ganz gleich, welche es war.

1093

1094<h3 id="/sandbox-fails-with-sandbox-settings-are-overridden-by-a-higher-priority-configuration">

1095 `/sandbox` schlägt mit `Sandbox settings are overridden by a higher-priority configuration` fehl

1096</h3>

1097

1098`/sandbox` gibt `Error: Sandbox settings are overridden by a higher-priority configuration and cannot be changed locally.` aus, statt sein Panel zu öffnen, wenn eine höhere [Einstellungsebene](/docs/de/settings#settings-precedence) `sandbox.enabled`, `sandbox.autoAllowBashIfSandboxed` oder `sandbox.allowUnsandboxedCommands` setzt. Das Panel speichert Ihre Auswahl in `.claude/settings.local.json`, und ein dort gespeicherter Wert kann diese Ebenen nicht überschreiben.

1099

1100Verwaltete Einstellungen und `--settings` haben Vorrang vor lokalen Einstellungen. Um zu sehen, welche davon diese Sitzung geladen hat, führen Sie `/status` aus und lesen Sie die Zeile `Setting sources`:

1101

1102* **`Command line arguments`**: Wenn Sie Claude Code mit [`--settings`](/docs/de/settings#change-a-setting-for-one-session) gestartet haben, prüfen Sie, ob die übergebene Datei oder das übergebene JSON einen dieser Schlüssel setzt. Falls ja, ändern Sie den Wert dort, oder starten Sie Claude Code erneut ohne diese Schlüssel.

1103* **`Enterprise managed settings`**: Die verwalteten Einstellungen Ihrer Organisation sind geladen. Wenn sie einen dieser Schlüssel setzen, können Sie diesen Schlüssel weder über `/sandbox` noch über eine von Ihnen kontrollierte Einstellungsdatei ändern. Wenden Sie sich in diesem Fall an Ihren Administrator.

765 1104

766<h2 id="limitations">1105<h2 id="limitations">

767 Einschränkungen1106 Einschränkungen

776* **Netzwerk-Filterung**: Die Sandbox schränkt ein, mit welchen Domains Prozesse sich verbinden können. Standardmäßig beendet oder inspiziert der integrierte Proxy TLS auf ausgehenden Datenverkehr nicht, daher werden die Inhalte verschlüsselter Verbindungen nicht untersucht. Die experimentelle Einstellung [`network.tlsTerminate`](/docs/de/settings-reference#sandbox-network-tlsterminate) beendet TLS am Proxy für [`mask`-Anmeldedaten-Substitution](#mask-credentials), fügt aber keine Inhaltsfilterung hinzu. Sie sind verantwortlich dafür, dass nur vertrauenswürdige Domains in Ihrer Richtlinie zulässig sind.1115* **Netzwerk-Filterung**: Die Sandbox schränkt ein, mit welchen Domains Prozesse sich verbinden können. Standardmäßig beendet oder inspiziert der integrierte Proxy TLS auf ausgehenden Datenverkehr nicht, daher werden die Inhalte verschlüsselter Verbindungen nicht untersucht. Die experimentelle Einstellung [`network.tlsTerminate`](/docs/de/settings-reference#sandbox-network-tlsterminate) beendet TLS am Proxy für [`mask`-Anmeldedaten-Substitution](#mask-credentials), fügt aber keine Inhaltsfilterung hinzu. Sie sind verantwortlich dafür, dass nur vertrauenswürdige Domains in Ihrer Richtlinie zulässig sind.

777 1116

778<Warning>1117<Warning>

779 Das Zulassen breiter Domains wie `github.com` kann Pfade für Datenexfiltration schaffen. Da der Proxy seine Zulassungsentscheidung vom Client-bereitgestellten Hostnamen trifft, ohne TLS zu inspizieren, kann Code, der in der Sandbox ausgeführt wird, möglicherweise [Domain Fronting](https://en.wikipedia.org/wiki/Domain_fronting) oder ähnliche Techniken verwenden, um Hosts außerhalb der Zulassungsliste zu erreichen. Wenn Ihr Bedrohungsmodell stärkere Garantien erfordert, konfigurieren Sie einen [benutzerdefinierten Proxy](#custom-proxy-configuration), der TLS beendet und Datenverkehr inspiziert, und installieren Sie sein CA-Zertifikat in der Sandbox. Stärkere TLS-bewusste Netzwerk-Isolation ist ein aktives Entwicklungsgebiet.1118 Das Zulassen breiter Domains wie `github.com` kann Pfade für Datenexfiltration schaffen. Da der Proxy seine Zulassungsentscheidung vom Client-bereitgestellten Hostnamen trifft, ohne TLS zu inspizieren, kann Code, der in der Sandbox ausgeführt wird, möglicherweise [Domain Fronting](https://en.wikipedia.org/wiki/Domain_fronting) oder ähnliche Techniken verwenden, um Hosts außerhalb der Allowlist zu erreichen. Wenn Ihr Bedrohungsmodell stärkere Garantien erfordert, konfigurieren Sie einen [benutzerdefinierten Proxy](#custom-proxy-configuration), der TLS beendet und Datenverkehr inspiziert, und installieren Sie sein CA-Zertifikat in der Sandbox. Stärkere TLS-bewusste Netzwerk-Isolation ist ein aktives Entwicklungsgebiet.

780</Warning>1119</Warning>

781 1120

782* **Privilege Escalation über Unix-Sockets**: Die Konfiguration `allowUnixSockets` kann versehentlich Zugriff auf 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.1121* **Privilege Escalation über Unix-Sockets**: Die Konfiguration `allowUnixSockets` kann versehentlich Zugriff auf 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.

783* **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.1122* **Dateisystem-Berechtigungseskalation**: Übermäßig breite Dateisystem-Schreibberechtigungen 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.

784* **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.1123* **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. Diese Option schwächt die Sicherheit erheblich ab und sollte nur verwendet werden, wenn zusätzliche Isolation anderweitig durchgesetzt wird.

785* **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.1124* **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: In der Sandbox ausgeführte Befehle können andere Anwendungen ohne Sandbox und ohne Rückfrage beim Benutzer starten und können AppleScript-Befehle an laufende Anwendungen senden, vorbehaltlich der macOS-Zustimmungsabfrage für Automatisierung pro App (TCC). Es wird nur von Benutzer-, verwalteten oder CLI-Einstellungen berücksichtigt. Projekteinstellungen können es nicht aktivieren.

786 1125

787<h3 id="platform-and-tool-compatibility">1126<h3 id="platform-and-tool-compatibility">

788 Plattform- und Tool-Kompatibilität1127 Plattform- und Tool-Kompatibilität

796 Umfang1135 Umfang

797</h3>1136</h3>

798 1137

799Die Sandbox isoliert Bash-Subprozesse. Andere Tools funktionieren unter verschiedenen Grenzen:1138Die Sandbox isoliert Shell-Befehle und deren untergeordnete Prozesse. [Was außerhalb der Sandbox ausgeführt wird](#what-runs-outside-the-sandbox) listet die Tools und Hilfsprozesse auf, die sie nicht abdeckt. Computer-Nutzung und Subagenten verhalten sich in Bezug auf die Sandbox wie folgt:

800 1139

801* **Integrierte Datei-Tools**: Read, Edit und Write verwenden das Genehmigungssystem direkt, anstatt durch die Sandbox zu laufen. Siehe [Genehmigungen](/docs/de/permissions).1140* **Computer-Nutzung**: Wenn Claude Apps öffnet und Ihren Bildschirm steuert, läuft es auf Ihrem tatsächlichen Desktop, anstatt in einer isolierten Umgebung. Berechtigungsabfragen pro App kontrollieren jede Anwendung. Siehe [Computer-Nutzung in der CLI](/docs/de/computer-use) oder [Computer-Nutzung auf Desktop](/docs/de/desktop#let-claude-use-your-computer).

802* **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](/docs/de/computer-use) oder [Computer-Nutzung auf Desktop](/docs/de/desktop#let-claude-use-your-computer).

803* **Umgebungsvariablen**: Sandbox-Bash-Befehle erben die Umgebung des übergeordneten Prozesses standardmäßig, einschließlich aller dort gesetzten Anmeldedaten. Verwenden Sie [`sandbox.credentials`](#protect-credentials), um spezifische Variablen für Sandbox-Befehle zu deaktivieren oder zu maskieren, oder setzen Sie [`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`](/docs/de/env-vars), um Anmeldedaten aus allen Subprozessen zu entfernen.

804* **Subagenten**: [Subagenten](/docs/de/sub-agents) 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.1141* **Subagenten**: [Subagenten](/docs/de/sub-agents) 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.

1142* **Mods**: Ein [Mod](/docs/de/plugins/mods/overview) ist ein Plugin, das seinen eigenen Code innerhalb von Claude Code ausführt, und ein Prozess, den ein Mod startet, läuft außerhalb der Sandbox. Siehe [Was ein Mod erreichen kann](/docs/de/plugins/mods/overview#what-a-mod-can-reach).

805 1143

806<Warning>1144<Warning>

807 Effektives Sandboxing erfordert sowohl Dateisystem- als auch Netzwerk-Isolation. Ohne Netzwerk-Isolation könnte ein kompromittierter Agent sensible Dateien wie SSH-Schlüssel exfiltrieren. Ohne Dateisystem-Isolation, ob durch eine permissive Richtlinie oder durch [Deaktivierung der Dateisystem-Schicht](#disable-filesystem-isolation), könnte ein kompromittierter Agent System-Ressourcen manipulieren, um Netzwerkzugriff zu erlangen. Wenn Sie die Standardwerte erweitern, überprüfen Sie, dass ein `allowWrite`-Pfad, ein breiter `allowedDomains`-Eintrag oder eine `excludedCommands`-Ausnahme keine Einschränkung auf der anderen Seite rückgängig macht.1145 Effektives Sandboxing erfordert sowohl Dateisystem- als auch Netzwerk-Isolation. Ohne Netzwerk-Isolation könnte ein kompromittierter Agent sensible Dateien wie SSH-Schlüssel exfiltrieren. Ohne Dateisystem-Isolation, ob durch eine permissive Richtlinie oder durch [Deaktivierung der Dateisystem-Schicht](#disable-filesystem-isolation), könnte ein kompromittierter Agent System-Ressourcen manipulieren, um Netzwerkzugriff zu erlangen. Wenn Sie die Standardwerte erweitern, überprüfen Sie, dass ein `allowWrite`-Pfad, ein breiter `allowedDomains`-Eintrag oder eine `excludedCommands`-Ausnahme keine Einschränkung auf der anderen Seite rückgängig macht.

sandboxing.md 2026-10-01 23:59 UTC to 2026-10-02 03:00 UTC

Das Bash-Tool in der Sandbox konfigurieren

Was die Sandbox einschränkt

Was außerhalb der Sandbox läuft

Erste Schritte

/sandbox ausführen

Einen Modus wählen

Einen Bash-Befehl ausführen

Prüfen, ob Befehle in der Sandbox ausgeführt werden

Linux und WSL2 einrichten

Sandbox-Modi

Auto-Allow-Modus

Modus für reguläre Berechtigungen

Der Ausweg über den Wiederholungsversuch ohne Sandbox

Den Wiederholungsversuch mit dem strikten Sandbox-Modus deaktivieren

Temporäre Verzeichnisse

Sandboxing konfigurieren

Befehle mit `excludedCommands` außerhalb der Sandbox ausführen

Dateisystem-Isolation deaktivieren

Welche Einstellungen sie deaktivieren können

Was sich bei ausgeschalteter Dateisystem-Isolation ändert

Anmeldedaten schützen

Anmeldedaten maskieren

Umgebungsvariablen maskieren

AWS-Anfragen neu signieren

Dateien mit Anmeldedaten maskieren

Wie Sandboxing funktioniert

Dateisystemisolation

Geschützte Pfade

Netzwerkisolation

Hosts außerhalb Ihrer erlaubten Domains

Hostnamen, die zu lokalen Adressen aufgelöst werden

Erlaubte Domains pro Befehl im Auto-Modus

IPv6-Adressen in Domain-Listen

Durchsetzung auf Betriebssystemebene

Wie Sandboxing sich auf Genehmigungen und Genehmigungsmodi bezieht

Genehmigungsregeln

Genehmigungsmodi

Konfigurieren Sie die Sandbox für Ihre Organisation

Erzwingen Sie Sandboxing mit verwalteten Einstellungen

Verhindern Sie, dass Entwickler die Richtlinie erweitern

Repository-Einstellungen bei einer vom Administrator erforderlichen Sandbox

Sperren, die ohne eine vom Administrator erforderliche Sandbox gelten

Benutzerdefinierte Proxy-Konfiguration

Fehlerbehebung

`git` über SSH schlägt bei aktivierter Sandbox fehl

Ein Datenbank-Client oder ein anderes Nicht-HTTP-Tool erreicht einen zugelassenen Host nicht

Ein Befehl erreicht einen Server auf localhost nicht

Ein zugelassener Hostname wird mit `resolved to a loopback address` abgelehnt

`/sandbox` schlägt mit `Sandbox settings are overridden by a higher-priority configuration` fehl

Einschränkungen

Sicherheitsbeschränkungen

Plattform- und Tool-Kompatibilität

Umfang

Siehe auch