Claude Code Sandboxing

Problem: Ein KI-Agent mit offem Zugriff auf deine Festplatte und dein Netzwerk ist ein Risiko, das du nicht einfach ignorieren kannst. Jedes npm install lädt Code herunter, den Fremde geschrieben haben. Jedes Build-Skript läuft mit deinen vollen Nutzerrechten. Jede Prompt-Injection, die ankommt, hat denselben Spielraum wie du. Eine schlechte Abhängigkeit kann ohne Schutzmauern SSH-Schlüssel lesen, Umgebungsvariablen nach außen schicken oder deine Shell-RC-Dateien still und heimlich bearbeiten.

Claude Codes Sandbox schließt diese Tür. Sie drückt Dateisystem- und Netzwerkgrenzen auf den Kernel herunter, sodass die Regeln nicht mehr von Vertrauen oder der Formulierung eines Prompts abhängen.

Schnellstart: Ein Befehl aktiviert das Sandboxing sofort:

> /sandbox

Ein Menü erscheint, um den Sandbox-Modus auszuwählen. Auf macOS ist die Funktion bereits aktiv. Für Linux oder WSL2 müssen zuerst zwei Pakete installiert werden: bubblewrap und socat (Anweisungen unten).

Warum Berechtigungsabfragen allein nicht ausreichen

Wer Claude Code länger nutzt, kennt das Muster. Claude will einen Befehl ausführen. Bestätigen. Claude will eine Datei schreiben. Bestätigen. Claude will die Tests ausführen. Bestätigen. Nach dreißig Klicks stempelst du den Ablauf ab, ohne auch nur eine Abfrage zu lesen.

Das ist Bestätigungsmüdigkeit. Es ist ein Sicherheitsproblem im Kostüm eines Sicherheitsfeatures.

Mehr Abfragen bedeuten weniger Aufmerksamkeit auf jede einzelne. Die Forschung zur Sicherheits-UX kommt immer wieder zum gleichen Ergebnis: Wiederholte Dialoge trainieren Menschen dazu, einfach durchzuklicken. Du verlierst auf beiden Seiten. Der Fluss wird trotzdem unterbrochen, und der Schutz nimmt trotzdem ab.

Sandboxing dreht das Modell um. Statt bei jedem Schritt zu fragen "kann diese eine Aktion stattfinden?", richtest du die Zäune einmal ein. Hier darf gelesen werden. Hier darf geschrieben werden. Das darf das Netzwerk erreichen. Innerhalb dieser Zäune gibt es keine Abfragen. Außerhalb stoppt das OS die Aktion, kein Dialog.

Das Ergebnis: weniger Unterbrechungen, stärkere Abwehr, und ein Agent, der autonom innerhalb bekannter sicherer Grenzen arbeitet.

Wie Claude Code Sandboxing funktioniert

Zwei Isolationsschichten laufen nebeneinander. Beide sind wichtig. Nimmst du eine heraus, entstehen in der verbliebenen Lücken, durch die man einen Lkw fahren könnte.

Dateisystem-Isolation

Das sandboxed Bash-Tool beschränkt den Dateizugriff auf eine kurze Liste von Verzeichnissen:

Schreibzugriffe bleiben im Arbeitsverzeichnis und alles darunter
Lesezugriffe decken das gesamte System ab, außer Pfaden, die du als verweigert markiert hast
Out-of-Tree-Bearbeitungen schlagen fehl, es sei denn, du erteilst ausdrücklich Erlaubnis
Benutzerdefinierte Pfade öffnen oder schließen weitere Verzeichnisse über die Sandbox-Einstellungen

In der Praxis liest Claude Projektdateien und bearbeitet Code in deinem Repo, aber ~/.bashrc, /usr/local/bin und alles in ~/.ssh bleibt außer Reichweite. Ein bösartiges npm-Paket, das versucht, diese Wände zu überschreiten, wird vom OS selbst blockiert.

Netzwerk-Isolation

Ausgehender Traffic wird über einen Proxy-Server geleitet, der außerhalb der Sandbox läuft:

Domain-Allowlist begrenzt die Hosts, die ein Prozess erreichen darf
Unbekannte Domains lösen eine Berechtigungsabfrage aus, damit jeder neue Host vor dir erscheint
Vererbte Grenzen reisen mit jedem Child-Prozess mit, sodass eine Shell, die ein Build-Skript erzeugt, die Regeln nicht umgehen kann
Benutzerdefinierte Proxys ermöglichen Unternehmen, Sandbox-Traffic durch ihre eigene Inspektions-Pipeline zu leiten

Dateisystem-Wände allein lassen eine Lücke. Ein gekaperter Agent könnte Quellcode noch immer an einen vom Angreifer kontrollierten Host schicken. Netzwerk-Wände allein lassen die entgegengesetzte Lücke. Beide Schichten müssen nebeneinander laufen. Das Design basiert darauf.

Durchsetzung auf Kernel-Ebene

Die Sandbox hängt nicht von App-Layer-Prüfungen ab. Ein cleverer Exploit kann diese immer umgehen. Was die Arbeit erledigt, sind Kernel-Sicherheitsprimitive:

macOS: Seatbelt, dasselbe Framework, das Apple zur Isolierung von App Store-Apps verwendet
Linux: bubblewrap (bwrap), das kleine unprivilegierte Sandbox-Tool, auf dem Flatpak aufgebaut ist
WSL2: bubblewrap genauso wie unter nativem Linux

WSL1 ist nicht unterstützt. bubblewrap braucht Features, die der Kernel nur unter WSL2 bereitstellt, nämlich User- und Mount-Namespaces. Ein nativer Windows-Build ist geplant, aber noch nicht verfügbar.

Jeder Child-Prozess, den ein sandboxed Befehl erzeugt, erbt dieselben Grenzen. Führst du npm install in der Sandbox aus, landet auch jeder Postinstall-Hook in der Box.

Voraussetzungen und Installation

macOS

Nichts extra zu installieren. Sandboxing läuft sofort auf dem Seatbelt-Framework, das bereits im OS ist. Tippe /sandbox und wähle einen Modus.

Linux und WSL2

Du brauchst zwei Pakete. bubblewrap macht die Dateisystem-Isolation und socat kümmert sich um das Netzwerk-Proxy-Plumbing:

Ubuntu/Debian:

sudo apt-get install bubblewrap socat

Fedora:

sudo dnf install bubblewrap socat

Wenn die installiert sind, tippe /sandbox in Claude Code. Falls eine Abhängigkeit noch fehlt, zeigt das Menü die Installationsanleitung für deine Plattform.

Sandbox-Modi: Auto-Allow vs. normale Berechtigungen

Zwei Modi gibt es. Die Dateisystem- und Netzwerkwände sind in beiden identisch. Was sich ändert, ist, ob ein sandboxed Befehl noch deinen Klick braucht.

Auto-Allow-Modus

Ein Bash-Befehl versucht, unter der Sandbox zu laufen, und wenn er passt, fragt nichts zuerst. Falls derselbe Befehl einen Host braucht, der nicht auf deiner Allowlist steht, greift der normale Berechtigungsablauf. Jede bereits konfigurierte Allow- oder Deny-Regel feuert weiterhin.

Die meisten wollen diesen Modus. Der Agent hat maximalen Spielraum innerhalb der Zäune, und Abfragen kommen nur zurück, wenn etwas einen Zaun überschreiten würde.

Eine Besonderheit ist wissenswert. Auto-Allow läuft unabhängig vom Berechtigungsmodus. Selbst wenn "Bearbeitungen akzeptieren" ausgeschaltet ist, läuft ein sandboxed Bash-Befehl ohne Abfrage, wenn Auto-Allow aktiv ist. Dateibearbeitungen über das Edit-Tool folgen weiterhin deinen normalen Berechtigungsregeln. Nur Bash innerhalb der Sandbox wird durchgeschleust.

Normaler Berechtigungsmodus

Jeder Bash-Befehl, sandboxed oder nicht, läuft noch immer durch den normalen Berechtigungsdialog. Die Wände bleiben, und jeder Befehl fragt dich auch noch einmal.

Wähle diesen Modus, wenn du Sandbox-Schutz willst, ohne die Überprüfung pro Befehl aufzugeben. Gut geeignet für strenge Umgebungen oder für die ersten Tage beim Einrichten einer neuen Sandbox-Konfiguration.

Deine Sandbox konfigurieren

Das Sandbox-Verhalten wird über deine settings.json eingestellt. Ein funktionierendes Beispiel sieht so aus:

{
  "sandbox": {
    "mode": "auto-allow",
    "allowedDomains": ["registry.npmjs.org", "api.github.com", "pypi.org"],
    "network": {
      "httpProxyPort": 8080,
      "socksProxyPort": 8081
    }
  }
}

Wichtige Einstellungen

mode: Setz es auf "auto-allow" oder "regular". Dieser Flag entscheidet, ob sandboxed Befehle von selbst laufen oder auf einen Klick warten.

allowedDomains: Hosts, die Bash ohne Rückfrage erreichen darf. Neue Domains, die du ansteuerst, lösen eine Abfrage aus, und durch Akzeptieren wird die Domain für das nächste Mal in diese Liste geschrieben.

allowUnixSockets: Steuert Socket-Zugriff. Vorsicht hier. Das Erlauben von /var/run/docker.sock ist faktisch ein Freifahrtschein zum Host über die Docker-API, was die Sandbox-Wände umgeht.

allowUnsandboxedCommands: Standardmäßig true. Wenn eine Sandbox-Regel einen Befehl blockt, kann Claude diesen Befehl nach deiner Bestätigung ohne Sandbox erneut ausführen. Auf false setzen, um den Retry-Pfad zu deaktivieren.

excludedCommands: Eine Liste von Befehlen, die die Sandbox jedes Mal überspringen. Gut für Tools, die schlicht nicht kooperieren wollen, wie docker.

enableWeakerNestedSandbox: Ein Linux-only-Schalter für nicht-privilegierte Docker-Setups. Er schwächt die Wände, also greife nur darauf zurück, wenn der äußere Container seine eigene Isolation durchführt.

Wie Sandboxing neben Berechtigungen funktioniert

Berechtigungen und Sandbox sind zwei unabhängige Sicherheitsschichten, die sich gegenseitig absichern:

Berechtigungen entscheiden, welche Tools überhaupt für Claude Code erreichbar sind. Sie laufen vor jedem Tool-Aufruf, und sie gelten für jedes Tool: Bash, Read, Edit, WebFetch, MCP-Tools, alles.

Sandboxing ist OS-erzwungen und formt nur, was ein Bash-Befehl (oder seine Unterprozesse) mit dem Dateisystem und dem Netzwerk tun kann.

Denk an Defense in Depth. Erstes Tor: Ist dieses Tool überhaupt erlaubt? Zweites Tor: Sobald es läuft, wie weit kann seine Reichweite gehen?

Sicherheitsvorteile

Schutz vor Prompt-Injection

Prompt-Injection ist das größte aktive Risiko für einen KI-Agenten. Ein Angreifer versteckt Anweisungen in einer Datei, einem README oder einer Webseite. Claude liest sie, als hättest du sie geschrieben, und führt Angreifer-Befehle aus.

Mit aktiver Sandbox läuft selbst eine erfolgreiche Injection gegen harte Wände:

Dateisystemschutz:

Shell-RC-Dateien wie ~/.bashrc und ~/.zshrc sind tabu
System-Binaries unter /bin/ oder /usr/local/bin/ können nicht angefasst werden
Jeder Pfad, der in deinen Berechtigungsregeln als "deny" markiert ist, ist unlesbar

Netzwerkschutz:

Vom Angreifer kontrollierte Server können nicht für Daten-Exfiltration genutzt werden
Bösartige Skripte von unbekannten Domains können nicht heruntergeladen werden
API-Aufrufe zu nicht genehmigten Diensten gehen nicht durch
Jede Domain, die nicht auf der Allowlist steht, ist unerreichbar

Kleinere Angriffsfläche

Abgesehen von Injection reduziert die Sandbox auch Schäden durch alltägliche Risiken:

Schlechte Abhängigkeiten: npm-, pip- oder andere Bibliotheken, die in Postinstall-Hooks bösartige Logik verstecken
Kaputte Build-Tools: Build-Utilities mit eigenen Schwachstellen
Social Engineering: gefährliche Befehle, die ein Nutzer dazu verleitet wurde auszuführen
Supply-Chain-Angriffe: manipulierte Upstream-Pakete, die die Installation zur Code-Injection machen

Grenzen, die du kennen solltest

Keine Sandbox ist perfekt. Offen über die Lücken zu sein, ist der Weg zu einem realistischen Bedrohungsmodell.

Domain Fronting

Der Netzwerkfilter erkennt Domains, macht aber keine Deep Packet Inspection. Domain Fronting, bei dem Traffic so aussieht, als ginge er zu einem Host, aber tatsächlich bei einem anderen landet, kann den Domain-Filter in manchen Fällen umgehen.

Unix Socket Eskalation

allowUnixSockets kann leise mächtigen Zugriff herausgeben. Erlaube /var/run/docker.sock und der sandboxed Prozess hat die vollständige Docker-API in der Hand, was in der Praxis Zugriff auf den Host bedeutet.

Dateisystem-Berechtigungseskalation

Zu lockere Schreibrechte ermöglichen Eskalationspfade. Lass die Sandbox in jeden Ordner mit Binaries auf $PATH, System-Konfigurationsverzeichnissen oder Shell-RC-Dateien schreiben, und Code kann unter einem anderen Sicherheitskontext landen.

Praktische Tipps und Kompatibilität

Docker spielt nicht gut mit

Docker-Befehle funktionieren nicht unter der Sandbox. Sie brauchen eine direkte Verbindung zum Docker-Daemon. Pack docker in excludedCommands, damit es immer außerhalb läuft.

Watchman spielt auch nicht gut mit

Facebooks watchman-Datei-Watcher kooperiert nicht mit einem sandboxed Prozess. Wenn du Jest ausführst, hänge das --no-watchman-Flag dran.

Der Notausgang

Hin und wieder schlägt ein sandboxed Befehl wegen der Wände selbst fehl. Claude kann sich das Scheitern ansehen und anbieten, mit dangerouslyDisableSandbox erneut zu versuchen. Dieser Retry läuft außerhalb der Sandbox und wartet trotzdem auf deine Genehmigung durch den normalen Berechtigungsablauf.

Benutzerdefinierte Proxy-Konfiguration für Unternehmen

Organisationen mit tieferem Netzwerksicherheitsbedarf können Sandbox-Traffic durch einen eigenen Proxy zur Inspektion, Protokollierung und Anbindung an den Rest des Sicherheits-Stacks leiten.

Das ermöglicht:

HTTPS-Traffic zu terminieren und zu inspizieren
Regeln anzuwenden, die weiter gehen als eine einfache Domain-Blockierung
Jede ausgehende Anfrage in ein Audit-Log zu schreiben
Die Sandbox in ein bestehendes SIEM oder einen Sicherheits-Stack einzubinden
Organisationsweite Regeln über den verwalteten Einstellungsbereich zu verteilen

Open-Source Sandbox Runtime

Die Runtime wird als eigenes npm-Paket ausgeliefert, Open Source. Bau es in jedes Agentenprojekt ein. Kein Claude Code erforderlich:

npx @anthropic-ai/sandbox-runtime <command-to-sandbox>

Der Quellcode liegt auf github.com/anthropic-experimental/sandbox-runtime.

Deine erste Sandbox einrichten

Ein praktischer Weg von Null zu einer funktionierenden Konfiguration:

Abhängigkeiten zuerst (nur Linux/WSL2): sudo apt-get install bubblewrap socat
Tippe /sandbox in Claude Code und wähle einen Modus aus dem Menü
Wähle Auto-Allow, wenn du den Sweet Spot zwischen Sicherheit und Geschwindigkeit willst
Nutze Claude wie gewohnt und bestätige alle neuen Domains, die die Abfragen zeigen
Überprüfe die Konfiguration nach einer oder zwei Sessions und prüfe die Domain-Liste
Räum auf, was du nicht brauchst, indem du veraltete Domains wieder rausnimmst

Fang eng an. Öffne nur, wenn der Bedarf wirklich da ist. Eine Regel zu lockern ist billiger als eine aufzuräumen, die nie da war.

Claude Code Sandboxing

On this page