SpyBara
Go Premium

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

This page contains 601 additions and 302 deletions.

2026
Fri 2 07:00

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:

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
1

/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.

2

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.

3

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 Bubblewrap startet nicht innerhalb eines Containers.

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

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

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:

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.

Dateisystempfade der Sandbox folgen den üblichen Konventionen: /tmp/build ist absolut, und ~/.kube ist relativ zu Ihrem Home-Verzeichnis. Dies unterscheidet sich von den Berechtigungsregeln für Read und Edit, die //path für absolute und /path für projektrelative Pfade verwenden. Informationen zu relativen Pfaden, abschließenden Schrägstrichen und Platzhaltern finden 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.

sandbox.filesystem.disabled ist standardmäßig false. 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.

Ein gültiger mask-Eintrag legt den Schlüssel nicht fest, auch wenn Claude Code für ihn beim Start auf deny zurückfällt. Tragen Sie einen Pfad, der nicht maskiert werden kann, etwa ein Verzeichnis mit Anmeldedaten, als expliziten deny-Eintrag in den verwalteten Einstellungen ein, der den Schlüssel festlegt.

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, die den Proxy nicht mehr autorisieren, den echten Wert einzusetzen, 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

Wenn Sie Anmeldedaten maskieren, zeigt Claude Code Befehlen in der Sandbox einen sitzungsspezifischen Platzhalter, den Sentinel, und der Sandbox-Proxy setzt bei ausgehenden Anfragen an von Ihnen erlaubte Hosts den echten Wert ein. Ein deny-Eintrag unter Anmeldedaten schützen sperrt die Anmeldedaten stattdessen. Bei Dateien unter macOS sperrt Claude Code die Datei, anstatt sie zu maskieren.

Das Maskieren von Umgebungsvariablen erfordert Claude Code v2.1.199 oder höher. Die Referenz zu sandbox.credentials listet alle Felder auf.

Die Maskierung setzt Folgendes voraus:

  • TLS-Terminierung: Der Proxy ersetzt den echten Wert 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.
  • Ein erlaubtes Ziel: Jeder mask-Eintrag kann injectHosts auflisten, die Hosts, die der echte Wert erreichen darf. Der Proxy fügt den Wert nur bei Verbindungen ein, die die Domain-Allowlist zulässt. Jeder injectHosts-Host muss daher auch über network.allowedDomains erreichbar sein. Bei einem mask-Eintrag ohne injectHosts setzt der Proxy den echten Wert bei Anfragen an jeden Host in network.allowedDomains ein.
  • Ein vertrauenswürdiger Einstellungs-Geltungsbereich: Die Maskierung autorisiert den Proxy, Ihre echten Anmeldedaten an ein Ziel zu senden. Claude Code berücksichtigt mask-Einträge, network.tlsTerminate, credentials.allowPlaintextInject, awsPairs und sigv4 daher nur aus Benutzereinstellungen, verwalteten Einstellungen und dem Flag --settings. In der .claude/settings.json oder .claude/settings.local.json eines Repositorys ignoriert es sie. 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.

Umgebungsvariablen maskieren

Um eine Umgebungsvariable zu maskieren, setzen Sie "mode": "mask" in ihrem credentials.envVars-Eintrag. Der Befehl und alles, was er protokolliert, enthalten nie die echten Anmeldedaten, aber seine Anfragen werden dennoch authentifiziert. Wenn dieselbe Variable in einem beliebigen Geltungsbereich mit deny aufgeführt ist, hat deny Vorrang.

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" }
      ]
    }
  }
}

Die Maskierung ersetzt standardmäßig den gesamten Wert. Verwenden Sie für einen strukturierten Wert, etwa einen DATABASE_URL-Verbindungsstring oder ein JWT, die Felder extract, decode, maskClaims und onExtractNoMatch, damit Tools, die den Wert parsen, weiterhin funktionieren.

Schreiben Sie ein IPv6-Ziel in den beiden Listen unterschiedlich:

  • network.allowedDomains: die Form mit eckigen Klammern, etwa "[::1]"
  • injectHosts: die reine Adresse in ihrer kanonischen komprimierten Form, etwa "::1"

Der Proxy gleicht jeden injectHosts-Eintrag mit der reinen Zieladresse der Verbindung ab und ignoriert dabei Ports, sodass eine Schreibweise mit eckigen Klammern, Zonen-ID oder anderer Komprimierung nie passt. claude doctor kennzeichnet 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.

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 die Anfrage mit den echten Werten neu, was Claude Code v2.1.221 oder höher erfordert. Wird nur der geheime Schlüssel maskiert, werden Anfragen mit einem Platzhalter signiert, den der Proxy nicht erkennen kann, sodass sie bei AWS fehlschlagen.

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 mit credentials.awsPairs, was Claude Code v2.1.224 oder höher erfordert.

Streaming-Uploads, vorsignierte URLs und SigV4A-Anfragen tragen Signaturen, die der Proxy nicht neu berechnen kann. Wenn eine dieser Anfragen 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 nicht betroffen. Verwenden Sie credentials.sigv4, was Claude Code v2.1.224 oder höher erfordert, um eine dieser Anfrageformen stattdessen weiterzuleiten. AWS lehnt die Anfrage weiterhin ab, sodass das aufrufende Tool die Ablehnungsantwort von AWS selbst statt eines Proxy-Fehlers erhält.

Dateien mit Anmeldedaten maskieren

Um eine Datei mit Anmeldedaten zu maskieren, setzen Sie "mode": "mask" in ihrem credentials.files-Eintrag. Das Maskieren von Dateien erfordert Claude Code v2.1.221 oder höher. 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, und der Proxy setzt bei ausgehenden Anfragen den echten Wert ein.
  • macOS: Befehle in der Sandbox können die Datei überhaupt nicht lesen. Claude Code erstellt keine Sentinel-Kopie, sodass Tools, die sich mit der Datei authentifizieren, innerhalb der Sandbox nicht funktionieren, mit derselben Wirkung wie deny. Die Lesesperre bleibt auch dann bestehen, wenn Sie die Dateisystem-Isolation deaktivieren.

Das folgende Beispiel maskiert ein GitHub-Token, das in ~/.config/gh/hosts.yml gespeichert ist. Das extract-Muster kennzeichnet, welcher Teil der Datei das Geheimnis ist, sodass gh unter Linux und WSL2 den Rest seiner Konfiguration weiterhin parst:

{
  "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 anstelle des Tokens, und unter macOS schlägt das Lesen fehl.

Ohne extract oder decode ersetzt Claude Code die gesamte Datei durch einen einzigen Sentinel, was für eine Datei geeignet ist, die ein einzelnes reines Geheimnis enthält. Verwenden Sie die Felder extract, decode, maskClaims, onExtractNoMatch und maskDuplicates, um die teilweise Maskierung zu steuern und festzulegen, was passiert, wenn das Muster auf nichts passt.

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.

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 Ein Git-Befehl schlägt mit unable to unlink old fehl.

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

Um eine IPv6-Adresse in allowedDomains, deniedDomains oder einer WebFetch(domain:...)-Regel abzugleichen, schreiben Sie die Adresse in eckigen Klammern: "[::1]" passt auf diese Adresse an jedem Port, und "[::1]:443" passt nur an Port 443. Die Form in eckigen Klammern erfordert Claude Code v2.1.229 oder höher.

Ein Eintrag ohne Klammern wie ::1:443 ist mehrdeutig, da er sowohl eine Adresse als auch eine Adresse mit Port sein kann:

  • 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

Um mehrdeutige Einträge zu finden, führen Sie claude doctor in Ihrem Terminal aus und achten Sie auf die Warnung Sandbox network domain entries have unreliable spellings. Schreiben Sie jeden mehrdeutigen Eintrag in die Form mit eckigen Klammern um.

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

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:

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:

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. Ein gültiger mask-Eintrag sperrt den Schlüssel nicht. Siehe Welche Einstellungen können es deaktivieren.

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:

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. Suchen Sie die Überschrift, die zu Ihrem Symptom oder Ihrer Fehlermeldung passt.

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. Um diese Tools außerhalb der Sandbox auszuführen, 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. Claude Code ignoriert diesen Schlüssel in Projekteinstellungen.

Das Aktivieren von allowAppleEvents 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. Befehle mit excludedCommands außerhalb der Sandbox ausführen 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

Die Zwischenablage-Dienstprogramme pbcopy, xclip und wl-copy 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.

git merge, git checkout und ähnliche Befehle schlagen mit unable to unlink old fehl, wenn sie eine Datei ersetzen müssen, in die die Sandbox Schreibvorgänge verweigert. Unter Linux und WSL2 endet der Fehler mit Read-only file system. Die Datei kann sich an einem dieser Orte befinden:

  • Unter einem geschützten Pfad wie .claude/skills
  • Unter einem Ihrer denyWrite-Einträge
  • Außerhalb der Verzeichnisse, in die die Sandbox Befehle überhaupt schreiben lässt

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 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 die Einstellung 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 die Platzhalter bei jedem Start erneut schreibgeschützt ein, daher schlägt ein Schreibvorgang in die Einstellungen, etwa das Speichern einer Berechtigungswahl, an einem Pfad fehl, an dem ein Platzhalter verblieben ist.

Führen Sie claude doctor in Ihrem Terminal aus, um die verbleibenden Platzhalter-Dateien aufzulisten. Die Warnung Stale sandbox mask files left by a killed session nennt einige 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.

`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.

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