Sandbox und Iso­lie­rung

Ein Agent auf der Kommandozeile fragt im manuellen Modus, 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: Die Isolierung begrenzt laut Übersicht der Sandbox-Umgebungen (externe Seite, code.claude.com), worauf ein Befehl zugreifen kann, sobald er läuft.

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. Laut Sandbox-Doku (externe Seite, code.claude.com) setzt das Betriebssystem die Grenze am laufenden Vorgang durch. Sie hält deshalb unabhängig davon, was das Modell zu starten beschlossen hat, und selbst dann, wenn ein erlaubter Befehl mehr tut, als sein Name vermuten lässt.

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.

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 (externe Seite, code.claude.com) sagt das ungewöhnlich deutlich: Wo keine Rückfrage mehr Fehler abfängt, schützt die Grenze das System, die man bei der Isolierung gewählt hat.

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 laut Übersicht der Sandbox-Umgebungen (externe Seite, code.claude.com) eigene Prozesse sind und unbeschränkt auf dem Rechner laufen.

Gemeint sind MCP-Server und Hooks, also genau die beiden Einrichtungen aus Kapitel 12 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. Erheblichen Schutz bietet er laut Dev-Container-Anleitung (externe Seite, code.claude.com) durchaus, gegen alle Angriffe vollständig gefeit ist aber kein System.

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. Laut Sandbox-Doku (externe Seite, code.claude.com) setzt sie in beiden dieselben Beschränkungen für Dateisystem und Netz durch; verschieden ist allein, ob abgeschottete Befehle automatisch freigegeben werden oder eine ausdrückliche Erlaubnis brauchen.

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.

Weitere Ausnahmen kamen mit dem Auto-Modus dazu. Die Selbstfreigabe arbeitet laut Sandbox-Doku (externe Seite, code.claude.com) unabhängig vom eingestellten Rechtemodus, mit drei Ausnahmen: dem Planmodus, einem Befehl im Auto-Modus, der seine eigene Liste erlaubter Rechner mitbringt, und der serverseitigen Prüfung abgeschotteter Befehle durch den Klassifikator im Auto-Modus.

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 dritte Ausnahme betrifft die Sandbox insgesamt: Auch ein gewöhnlicher Befehl darin geht im Auto-Modus serverseitig durch denselben Klassifikator, der weiter unten in einem eigenen Abschnitt beschrieben ist.

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 auf­schluss­reichste Zeile der ganzen Sandbox-Doku (externe Seite, code.claude.com): Kann die Sandbox nicht starten, weil eine Abhängigkeit fehlt oder die Plattform nicht unterstützt wird, führt Claude Code die Befehle voreingestellt ohne Sandbox aus.

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. Eine Sandbox, die nicht startet, lässt die Befehle trotzdem laufen, nur ohne Grenze, und am Ergebnis der Arbeit ändert das nichts. Wer sich auf sie verlässt, prüft also einmal absichtlich, ob wirklich etwas stehenbleibt.

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 Sandbox-Doku (externe Seite, code.claude.com): Der wiederholte Befehl läuft ohne Sandbox.

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. Wer sie öffnet, hängt in einer interaktiven Sitzung im Terminal vom Rechtemodus ab: Im gewöhnlichen Betrieb kommt eine Rückfrage, im Auto-Modus urteilt der Klassifikator, in dontAsk wird der Versuch abgelehnt, sofern kein installierter Mod ihn freigibt, und mit bypassPermissions läuft er ohne Rückfrage. Ist permissions.blockReadsOutsideWorkingDirectories eingeschaltet, fragt Claude Code seit Version 2.1.257 auch in bypassPermissions und im Auto-Modus nach, wenn der Rückfall eine Freigabe braucht, um außerhalb der Sandbox zu laufen (Doku zu den Rechtemodi (externe Seite, code.claude.com)). Auch eine Erlaubnisregel, die den Befehl ohnehin trifft, etwa Bash(curl *), genehmigt den Rückfall mit, und der Befehl verlässt die Sandbox ohne Frage.

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. Wer ihn ganz abschalten will, setzt allowUnsandboxedCommands auf false; dann ignoriert Claude Code den Schalter des Modells.

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. Ein solcher Befehl geht laut Sandbox-Doku (externe Seite, code.claude.com) an den Klassifikator, statt von einer Rechteregel oder der Selbstfreigabe der Sandbox genehmigt zu werden.

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.

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 Pro­jekt­ver­zeichnis, die Kon­fi­gu­ra­ti­ons­pfade 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, nach der Doku seit Version 2.1.283 auf jedem Tarif, nach der Versionsliste (externe Seite, code.claude.com) seit 2.1.284. Er ersetzt die Rückfrage durch eine Prüfung, die Aktionen beurteilt. Die Übersicht der Sandbox-Umgebungen (externe Seite, code.claude.com) ordnet ihn selbst ein: Der Klassifikator ist eine Kontrolle je Aktion.

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 Kon­fi­gu­ra­ti­ons­pfade. Was daraus folgt, steht als Warnung in derselben Anleitung (externe Seite, code.claude.com): Eine abgeschottete Sitzung, die dort schreiben darf, kann Hooks, Rechteregeln oder MCP-Server hinterlegen, die beim nächsten Start von Claude Code ohne Sandbox laufen.

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. Laut Anleitung (externe Seite, code.claude.com) deckt sie den Projektstamm zuverlässig ab, sucht ohne Gewähr und nur in geringer Tiefe nach verschachtelten Kopien, die zu diesem Zeitpunkt bestehen, und erfasst nichts, was die Sitzung später anlegt.

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.

Ein sauberer Start beweist nichts

Die Runtime liest ihre Einstellungen aus einer Datei. Fehlt die Standarddatei und wird auch keine andere übergeben, bricht der Start nicht ab. Die Runtime läuft weiter, sperrt das Netz und beschränkt Schreibzugriffe auf wenige eingebaute Pfade. Die Anleitung (externe Seite, code.claude.com) zieht daraus den Schluss selbst: Man soll einen sauberen Start nicht als Beweis dafür nehmen, dass die eigenen Einstellungen geladen wurden.

Das ist dieselbe Klasse wie die Voreinstellung aus der zweiten Tiefe, in der eine Sandbox, die nicht startet, die Befehle ohne Grenze weiterlaufen lässt. 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 fehlt. Das gilt auch für eine Datei, die leer, nicht lesbar oder ungültig ist, gleich auf welchem der beiden Wege sie gefunden wird. Täuschen kann also nur die fehlende Standarddatei: Wer sie am falschen Ort ablegt, bekommt einen sauberen Start ohne die eigenen Regeln.

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 Sandbox-Doku (externe Seite, code.claude.com) benennt sie: Code, der in der Sandbox läuft, kann unter Umständen über Domain Fronting oder ähnliche Techniken Rechner erreichen, die nicht auf der Liste der erlaubten stehen.

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. Laut Dev-Container-Anleitung (externe Seite, code.claude.com) halten Dev-Container ein bösartiges Projekt nicht davon ab, alles auszuleiten, was im Container erreichbar ist, auch die dort abgelegten Zugangsdaten von Claude Code.

Der Satz endet in der Anleitung mit dem Pfad, unter dem diese Daten liegen. Das eingehängte Pro­jekt­ver­zeichnis 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 Betriebs­sys­tem­kern 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 (externe Seite, accomplish.ai) fasst in vier Worten, warum dieser Fall über einen einzelnen Fehler hinausgeht: Diese Grenze ist das Produkt.

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 (externe Seite, accomplish.ai) daraus ableitet: Sein Verfasser behandelt die ganze virtuelle Maschine des Gasts als nicht vertrauenswürdig, den Root-Zugang eingeschlossen.

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.