Sandbox und Isolierung

Ein Agent auf der Kommandozeile fragt, bevor er etwas ausführt. Wer damit arbeitet, beantwortet diese Frage am Tag ein paar Dutzend Mal, und irgendwann steht eine Liste dessen da, was ohne Rückfrage durchlaufen darf.

Diese Liste beantwortet eine Frage. Sie lässt eine zweite offen: Was erreicht ein Befehl, während er läuft?

Zwei Größen, die man leicht verwechselt

Der Hersteller trennt beide in einem Satz:

Isolation restricts what a command can access once it runs. (externe Seite, code.claude.com)

Eine Rechteregel entscheidet vor dem Start. Sie sieht auf den Aufruf und lässt ihn zu oder hält ihn an. Die Isolierung wirkt danach, und sie sieht auf etwas anderes: auf das, was der laufende Vorgang berührt, also welche Dateien und welche Adressen im Netz.

Der Unterschied wird an einer Stelle greifbar, die für den Betrieb mit Agenten gebaut ist:

The operating system enforces the sandbox boundary on the running process, so it holds regardless of what the model chose to run and even if an allowed command does more than its name suggests. (externe Seite, code.claude.com)

Zwei Halbsätze, zwei verschiedene Sorgen. Der erste betrifft ein Modell, das etwas anderes gewählt hat, als jemand erwartet hätte. Der zweite betrifft einen Befehl, den man selbst erlaubt hat und dessen Name weniger verrät als sein Inhalt. Ein Skript heißt test, und was darin steht, hat niemand gelesen.

Die Grenze hat Stufen

Isolierung ist keine Eigenschaft, die man an- oder ausschaltet. Die Dokumentation stellt sechs Stufen nebeneinander, und fünf davon unterscheiden sich darin, wie viel innerhalb der Grenze liegt. Die sechste liegt neben der stärksten, nicht darüber: derselbe eigene Kern, nur bei Anthropic statt beim Nutzer.

Stufe	Was darin liegt
Bash-Sandbox	jeder Bash-Befehl und seine Kindprozesse
Sandbox-Runtime	der ganze Claude-Code-Prozess, also auch Hooks und MCP-Server
Dev-Container	derselbe Umfang, dazu eine Firewall, die alles verbietet, was nicht erlaubt ist
eigener Container	dasselbe mit den Netzregeln und Abbildern der eigenen Organisation
virtuelle Maschine	eigener Betriebssystemkern, die stärkste Trennung
Cloud-Sitzung	derselbe eigene Kern, in einer virtuellen Maschine bei Anthropic

seitlich verschiebbar

eigene Darstellung nach der Herstellerdokumentation, Stand 24.09.2026

Auf macOS zieht die Grenze das eingebaute Seatbelt-System, auf Linux und WSL2 ein Werkzeug namens bubblewrap. Natives Windows wird nicht unterstützt.

Wo die Frage wirklich zählt

Solange ein Mensch danebensitzt und jede Rückfrage beantwortet, ist die Isolierung eine zweite Schicht. Beim unbeaufsichtigten Lauf wird sie die erste, und die Dokumentation sagt das ungewöhnlich deutlich:

With no prompts to catch mistakes, the isolation boundary you choose is what protects your system. (externe Seite, code.claude.com)

Damit hängt die Antwort daran, wie ein Lauf gestartet wird. Ein nächtlicher Automat, ein Lauf ohne Rückfragen, eine Runde in einem Ablauf: Überall dort fällt die Rückfrage als Sicherung weg, und übrig bleibt allein, was die Grenze hält.

Was der einfachste Fall nicht abdeckt

Die eingebaute Sandbox fasst Bash-Befehle. Daneben stehen zwei Einrichtungen, die unbeschränkt auf dem Rechner laufen:

are separate processes that run unconstrained on the host (externe Seite, code.claude.com)

Gemeint sind MCP-Server und Hooks, also genau die beiden Einrichtungen aus Kapitel 08 und Agenten und Harness, Kapitel 02. Wer sie benutzt und die Isolierung für vollständig hält, hat eine Grenze um den kleineren Teil gezogen.

Auch die stärkeren Stufen haben ihre Kante. Die Anleitung zum Dev-Container schreibt sie selbst hin: Er hält niemanden davon ab, alles auszuleiten, was in ihm erreichbar ist, und dazu zählen die Zugangsdaten von Claude Code.

While the dev container provides substantial protections, no system is completely immune to all attacks. (externe Seite, code.claude.com)

Was daraus für die Einrichtung folgt, steht in der zweiten Tiefe. Der Grundsatz für diese hier ist schlichter. Was ein Agent anrichten kann, ergibt sich aus dem, was er erreicht, und das ist eine Entscheidung beim Einrichten. Sie fällt vor dem ersten Auftrag, nicht während einer Runde.

Die eingebaute Sandbox ist eingeschaltet und beschrieben, damit ist die Arbeit noch nicht getan. Drei Dinge entscheiden darüber, ob er im Betrieb wirklich hält: welcher Modus läuft, was passiert, wenn er nicht starten kann, und was geschieht, wenn ein Befehl an ihm scheitert.

Zwei Modi, ein Unterschied

Die Sandbox kennt zwei Betriebsarten, und der Unterschied liegt nicht in der Grenze:

In both, the sandbox enforces the same filesystem and network restrictions; the difference is only in whether sandboxed commands are auto-approved or require explicit permission. (externe Seite, code.claude.com)

Im Modus mit Selbstfreigabe läuft ein Befehl, der sich abschotten lässt, ohne Rückfrage. Im anderen bleibt die gewöhnliche Rechteprüfung davor stehen. Die Grenze ist beide Male dieselbe. Wer sie also als Ersatz für Rechteregeln einrichtet, hat die Rückfragen abgeschafft und nichts über die Reichweite gewonnen.

Ausdrückliche Verbote gelten in beiden Modi weiter, und Löschbefehle auf kritische Pfade gehen weiterhin durch die gewöhnliche Prüfung.

Eine Ausnahme davon kam mit dem Auto-Modus dazu:

Auto-allow mode works independently of your permission mode setting, except in plan mode and, in auto mode, for a command that carries per-command allowed domains. (externe Seite, code.claude.com)

Ein Befehl, der eine eigene Liste erlaubter Rechner mitbringt, läuft also selbst im Modus mit Selbstfreigabe nicht einfach durch. Was das für einen Befehl bedeutet, der einen nicht erlaubten Rechner braucht, steht weiter unten, bei der zweiten Stelle, an der die Grenze nachgibt.

Die erste Stelle, an der sie nachgibt

Eine Sandbox braucht Unterbau. Auf Linux und WSL2 sind das zwei Pakete, auf Windows fehlt die Grundlage ganz. Was geschieht, wenn davon etwas fehlt, ist die aufschlussreichste Zeile der ganzen Seite:

By default, if the sandbox cannot start because dependencies are missing or the platform is unsupported, Claude Code shows a warning and runs commands without sandboxing. (externe Seite, code.claude.com)

Die Voreinstellung ist also, weiterzuarbeiten. Ein Schalter namens sandbox.failIfUnavailable macht daraus einen harten Fehlschlag, und die Dokumentation nennt ihn ausdrücklich für Umgebungen, in denen die Abschottung verlangt wird.

Das ist die Klasse von Befund, die man an keinem laufenden Lauf bemerkt. Ein Sandbox, die nicht startet und deren Warnung im Protokoll steht, sieht bei der Arbeit genauso aus wie eine, die hält. Wer sich auf ihn verlässt, prüft also einmal absichtlich, ob wirklich etwas stehenbleibt.

seitlich verschiebbar

eigene Darstellung nach der Herstellerdokumentation, Stand 03.09.2026

Die zweite Stelle: das Modell darf hinaus

Manche Befehle laufen in der Sandbox nicht. Sie brauchen einen Rechner, der nicht erlaubt ist, oder vertragen sich mit der Abschottung nicht. Claude Code meldet den Verstoß dem Modell mitsamt dem Pfad oder Rechner, den die Grenze verweigert hat. Was dann passieren kann, steht in der Dokumentation:

The retried command runs outside the sandbox, so it goes through the regular permission flow (externe Seite, code.claude.com)

Das Modell darf den Befehl also erneut versuchen, diesmal außerhalb. Die Grenze, die eben noch unabhängig von der Wahl des Modells galt, hat damit eine Tür, die das Modell selbst anstößt. Sie führt nicht ins Freie: Dahinter steht die Rechteprüfung, im gewöhnlichen Betrieb also eine Rückfrage. Im Auto-Modus urteilt dort der Klassifikator.

Das ergibt eine brauchbare Ordnung. Die Sandbox ist die Grenze, die Rechteprüfung ist die Tür, und wer beide gleichzeitig weit stellt, hat keines von beidem. Wer jeden solchen Rückfall sehen will, hängt eine Nachfrageregel an den zugehörigen Schalter.

Für einen fehlenden Rechner gibt es daneben einen zweiten Weg, der die Sandbox gar nicht erst verlässt. Läuft die Sandbox im Auto-Modus, kann ein Bash-, PowerShell- oder Monitor-Befehl seine eigene Liste erlaubter Rechner mitbringen, zusätzlich zu denen aus der Einstellungsdatei:

A command that carries hosts goes to the classifier instead of being approved by a permission rule or the sandbox’s auto-allow mode. (externe Seite, code.claude.com)

Die Freigabe gilt nur für diesen einen Lauf und verschwindet danach wieder, der nächste Befehl nennt seine Rechner erneut. Verlangt der laufende Befehl unterwegs einen Rechner, der nicht auf seiner Liste steht, weist die Sandbox die Verbindung ab, ohne Rückfrage und ohne den Klassifikator zu bemühen, und nennt den fehlenden Rechner im Ergebnis. Anders als beim Rückfall zuvor verlässt der Befehl die Sandbox dafür nicht: Er läuft erneut, diesmal mit dem fehlenden Rechner auf seiner eigenen Liste, innerhalb derselben Grenze.

Was der Umfang kostet

Die sechs Stufen aus der ersten Tiefe unterscheiden sich in dem, was sie einschließen, und im Aufwand.

Stufe	Was dazukommt	Was sie kostet
Bash-Sandbox	im Programm enthalten, ein Befehl schaltet ihn ein	deckt nur Bash
Sandbox-Runtime	Hooks und MCP-Server liegen mit darin	eigene Einstellungsdatei, Vorschaufassung
Dev-Container	Firewall mit Standardverbot	Docker und ein Editor, der ihn verwaltet
eigener Container	eigene Abbilder und Netzregeln	vorhandene Container-Infrastruktur
virtuelle Maschine	eigener Betriebssystemkern	Betrieb und Bereitstellung
Cloud-Sitzung	eigener Kern bei Anthropic, kein eigener Betrieb	Claude-Abo, ohne claude --cloud zusätzlich ein verbundenes GitHub-Konto

Die Sandbox-Runtime ist der Schritt, der am meisten ändert, weil sie den ganzen Vorgang einfasst statt einzelner Befehle. Ihre Einstellungen brauchen Schreibrechte für das Projektverzeichnis, die Konfigurationspfade von Claude Code und das Verzeichnis für flüchtige Dateien, dazu die Adressen, die eine Sitzung erreichen muss.

Genau an diesen Schreibrechten hängt der Fall, der die dritte Tiefe eröffnet. Ein Verzeichnis, das die abgeschottete Sitzung beschreiben darf, ist ein Verzeichnis, aus dem beim nächsten Start etwas geladen wird.

Der Klassifikator ist keine Grenze

Seit dem 14. August 2026 ist der Auto-Modus die Voreinstellung, und er ersetzt die Rückfrage durch eine Prüfung, die Aktionen beurteilt. Die Dokumentation ordnet ihn selbst ein:

The classifier is a per-action control, not an isolation boundary (externe Seite, code.claude.com)

Damit steht er auf derselben Seite wie eine Rechteregel. Er entscheidet vor dem Start, er urteilt über einen Aufruf, und was daraus wird, bleibt außerhalb seines Blicks. Für einen unbeaufsichtigten Lauf verbessert er damit die Tür. Über die Reichweite dahinter sagt er nichts.

Bei der Rechnerliste weiter oben ist das eng gefasst: Er urteilt über den Befehl und die Rechner, die er nennt, mehr nicht, und eine Rechteregel allein öffnet dort nichts.

Eine Grenze wird an ihren Rändern interessant. Drei davon sind so gebaut, dass man sie erst nach einigen Wochen Betrieb bemerkt.

Die Sitzung, die ihre eigene Grenze verschiebt

Die Sandbox-Runtime braucht Schreibrechte, damit Claude Code darin arbeiten kann, und dazu gehören dessen eigene Konfigurationspfade. Was daraus folgt, steht als Warnung in derselben Anleitung:

A sandboxed session that can write them can persist hooks, permission rules, or MCP servers that run unsandboxed the next time you launch Claude Code. (externe Seite, code.claude.com)

Der Vorgang ist harmlos, solange man ihn im Voraus sieht. Innerhalb der Grenze wird eine Datei geschrieben. Beim nächsten Start liest Claude Code sie, und was darin steht, läuft mit den Rechten des Benutzers. Ein Hook ist ein Programm, das ungefragt startet; eine Rechteregel entscheidet, was ohne Rückfrage durchgeht; ein MCP-Server ist ein eigener Vorgang.

Die Abschottung eines Laufs ist damit keine Aussage über den Lauf danach. Die Runtime hält selbst einige dieser Pfade zurück, ohne dass jemand sie einträgt: Am Projektstamm verweigert sie Schreibzugriffe auf die Hook-Verzeichnisse von Git, auf die MCP-Konfiguration und auf die Verzeichnisse für eigene Befehle und Subagenten.

Auf Linux und WSL2 hat diese Liste eine Eigenschaft, die im Betrieb zählt:

it reliably covers the project root, makes a best-effort shallow scan for nested copies that exist at that point, and does not cover anything the session creates later (externe Seite, code.claude.com)

Sie entsteht beim Start. Ein Verzeichnis, das die Sitzung danach anlegt, etwa beim Klonen eines fremden Verzeichnisses, steht nicht darauf. Auf macOS wird beim Schreiben geprüft, dort greift die Liste auch für später Entstandenes.

seitlich verschiebbar

eigene Darstellung nach der Herstellerdokumentation, Stand 03.09.2026

Ein sauberer Start beweist nichts

Die Runtime liest ihre Einstellungen aus einer Datei. Fehlt sie oder ist sie unbrauchbar, bricht der Start nicht ab. Sie läuft weiter, sperrt das Netz und beschränkt Schreibzugriffe auf wenige eingebaute Pfade. Die Anleitung zieht daraus den Schluss selbst:

Don’t take a clean start as proof your settings loaded. (externe Seite, code.claude.com)

Das ist dieselbe Klasse wie die Voreinstellung aus der zweiten Tiefe, in der ein fehlgeschlagene Sandbox nur eine Warnung erzeugt. Beide Male läuft etwas, beide Male sieht es von außen richtig aus, und beide Male misst niemand, ob der Riegel eingelegt ist. Wer die Datei über den zugehörigen Schalter mitgibt, bekommt das andere Verhalten: Dann verweigert die Runtime den Start, wenn die Datei sich nicht laden lässt.

Der praktische Schluss ist derselbe wie bei jedem Riegel. Ein Schutz, der nie ausgelöst hat, ist von einem ohne Wirkung äußerlich gleich. Also einmal absichtlich dagegenlaufen: einen Schreibzugriff außerhalb des erlaubten Bereichs versuchen, einen Abruf auf eine nicht erlaubte Adresse, und nachsehen, ob wirklich etwas stehenbleibt.

Was eine Grenze im Netz wert ist

Die Filterung nach Adressen hat eine bekannte Kante, und die Dokumentation benennt sie:

code running inside the sandbox can potentially use domain fronting or similar techniques to reach hosts outside the allowlist (externe Seite, code.claude.com)

Gemeint ist die Möglichkeit, eine erlaubte Adresse nach außen zu zeigen und dahinter eine andere zu erreichen. Für die Einrichtung heißt das, dass eine Adressliste die Ausleitung erschwert und sie nicht ausschließt. Wo das zählt, liegt die Antwort eine Stufe höher, bei einer Firewall vor dem Container oder einer eigenen virtuellen Maschine.

Auch der Dev-Container hat diese Kante ausgeschrieben, und sie betrifft die eigenen Zugangsdaten:

dev containers do not prevent a malicious project from exfiltrating anything accessible inside the container, including the Claude Code credentials stored in (externe Seite, code.claude.com)

Der Satz endet in der Anleitung mit dem Pfad, unter dem diese Daten liegen. Das eingehängte Projektverzeichnis kommt dazu: Es liegt unmittelbar auf dem Rechner des Benutzers, ein Schreibzugriff darin berührt die Grenze also gar nicht.

Und wenn die Grenze der Kern selbst ist

Bleibt die stärkste Stufe, die eigene virtuelle Maschine. Sie bringt einen eigenen Betriebssystemkern mit, und genau dort setzte der Fall an, der im Juli 2026 bekannt wurde. Eine einzige Nachricht genügte, damit ein Agent in Claude Cowork seine virtuelle Maschine verließ und auf dem Mac lesen und schreiben konnte.

Der Bericht des Entdeckers fasst in vier Worten, warum dieser Fall über einen einzelnen Fehler hinausgeht:

That boundary is the product. (externe Seite, accomplish.ai)

Der benutzte Kernel-Fehler ist der austauschbare Teil. Er ist als CVE-2026-46331 (externe Seite, nvd.nist.gov) verzeichnet und behoben, der nächste sitzt woanders. Aufschlussreich ist die Haltung, die der Bericht daraus ableitet:

we treat the whole guest VM as untrusted, root included (externe Seite, accomplish.ai)

Jede dieser Grenzen ist Software, und Software hat Fehler. Die Frage beim Einrichten lautet deshalb weniger, ob eine Grenze hält. Sie lautet, was hinter ihr liegt, wenn sie einmal nicht hält.

Damit schließt sich der Bogen zur ersten Tiefe. Die Wahl der Stufe ist eine Aussage darüber, was man bereit ist zu verlieren. Ein Wegwerf-Verzeichnis mit eigenen Zugangsdaten ist ein anderes Ergebnis als das Hauptverzeichnis mit den Schlüsseln des Benutzers, und diese Entscheidung fällt beim Einrichten.