Wo Auto Mode und Sandbox den Coding-Agenten stoppen
Was stoppen Auto Mode in Claude Code, Auto-Review in Codex und die Sandbox, und was nicht? Doku und Messungen von fünf Tools.
Zusammenfassung. Ob ein Coding-Agent einen Befehl ausführen darf, entscheiden nacheinander vier Stellen: die Regeln, die Sie selbst schreiben, die Sandbox, ein Modell, das an Ihrer Stelle entscheidet, und zuletzt Sie. Am 20. Oktober 2026 haben wir die Dokumentation und die Release Notes von Claude Code, OpenAIs Codex, GitHub Copilot (CLI und VS Code), Cursor und Googles Antigravity CLI gelesen, dazu die eigenen Messungen von Anthropic und OpenAI und die Sicherheitseinträge in der NVD.
- Rückfragen werden in der Praxis ungelesen bestätigt. Laut einer Messung von Anthropic bestätigen Nutzer von Claude Code 97 % der Rückfragen, ob ein Befehl laufen darf. In einem Experiment des Unternehmens mit 1.053 Testnutzern stoppten Menschen einen in die Sitzung eingeschleusten gefährlichen Befehl in 13,6 % der Fälle, der Auto Mode in 89 %.
- Die Freigabe erteilt in den meisten Tools inzwischen ein eigenes Modell. Alle fünf Tools haben ein solches Freigabemodell (Gemini CLI nicht); in Claude Code und Cursor ist es standardmäßig aktiv. Laut OpenAI hält eine Codex-Sitzung mit aktivem Auto-Review etwa 200-mal seltener für eine menschliche Freigabe an.
- Die Anbieter sehen dieses Modell nicht als Sicherheitsgrenze. Cursor und VS Code schreiben das ausdrücklich. In Anthropics eigener Messung ging der Agent in 52 echten Aktionen über das hinaus, was der Nutzer wollte; der Klassifikator übersah 17 % davon.
- Die eigentliche Grenze zieht die Sandbox, doch in den meisten Tools ist sie ab Werk aus. In drei der fünf Tools (Claude Code, Copilot, Antigravity CLI) ist die Sandbox standardmäßig aus; selbst wenn sie läuft, können Teile wie Datei-Tools, Hooks oder lokale MCP-Server außerhalb bleiben. Nutzen Sie im Alltag das Freigabemodell zusammen mit der Sandbox; bei unbeaufsichtigten Läufen lassen Sie die Sandbox an, beschränken das Netz auf eine Liste von Domains und legen keine Secrets in die Umgebung.
Welche Prüfungen durchläuft ein Befehl, bevor er läuft?
Wenn ein Coding-Agent einen Befehl ausführen will, fällt die Entscheidung nicht an einer einzigen Stelle. Die Dokumentation aller fünf Tools beschreibt dieselben vier Schichten: zuerst die Regeln, die Sie selbst schreiben, dann die Sandbox, die das Betriebssystem durchsetzt, dann ein eigenes Modell, das den Befehl prüft, und zuletzt Sie. Wie Sie Regeln mit Hooks schreiben, steht im Beitrag über Hooks. Hier geht es um die anderen drei, mit den eigenen Messungen der Anbieter:

Warum ein Modell dazwischengeschaltet wurde, zeigen die Daten der Anbieter selbst. Laut Anthropic bestätigen Nutzer von Claude Code 97 % der Rückfragen. Dieselben Nutzer lehnen 39 % der Pläne ab, die der Agent vorlegt, bei einzelnen Rückfragen liegt die Ablehnungsquote aber nur bei 3 %. Das ist, als würde man einen Pull Request ungelesen freigeben: Die Fragen kommen so oft, dass man sie durchwinkt, ohne sie zu lesen.
Ein Experiment im selben Beitrag von Anthropic macht den Unterschied in Zahlen sichtbar. In die Sitzungen von 1.053 bezahlten Testnutzern wurde ein einziger gefährlicher Befehl eingeschleust. Tatsächlich war nur der Text der Rückfrage verändert; auch wer zustimmte, brachte nichts zur Ausführung. Menschen stoppten diesen Befehl in 13,6 % der Fälle, der Auto Mode in 89 %. Je länger die Sitzung, desto mehr übersahen die Menschen: Anfangs stoppten sie etwa 17 % der gefährlichen Befehle, nach 50 und mehr Rückfragen etwa 5 %. Diese Ergebnisse stammen aus dem eigenen Experiment des Anbieters.
Auch OpenAI hat das Problem bei den eigenen Nutzern gesehen. Laut dem Beitrag von OpenAI wechseln Nutzer bei häufigen Rückfragen entweder in den Modus Full Access, in dem keine Regel greift, oder sie schreiben breite Regeln, die jeden Befehl erlauben, der mit python beginnt. Laut Anthropic hatten im Juni 43 % der aktiven CLI-Nutzer eine Interpreter-Regel wie Bash(python:*). Beide Anbieter lösen das gleich: Sie stellen die Frage nicht einem Menschen, sondern einem eigenen Modell.
Wie entscheiden Auto Mode und Auto-Review?
Einen Aufruf, über den weder die Regeln noch die Sandbox entscheiden, bekommt das Freigabemodell; es entscheidet, ob er läuft. Alle fünf Tools haben inzwischen ein solches Modell. Was es sieht, wann es die Entscheidung an Sie zurückgibt und ob es standardmäßig aktiv ist, unterscheidet sich aber von Tool zu Tool. Stand 20. Oktober 2026:
| Tool | Freigabemodell | Was es sieht | Wann es Ihnen die Entscheidung überlässt | Standard |
|---|---|---|---|---|
| Claude Code | Klassifikator des Auto Mode; Standardmodell Claude Sonnet 5 | Nutzernachrichten, Tool-Aufrufe und CLAUDE.md; Tool-Ausgaben sieht er nicht | Fragt nach 3 Blockaden in Folge oder insgesamt 20 in einer Sitzung wieder Sie | An: Seit dem 28. September starten interaktive Sitzungen in diesem Modus |
| Codex | Auto-Review (“Approve for me”): ein eigener Codex-Agent | Der verdichtete Verlauf, relevante Tool-Ausgaben und die ganze Freigabeanfrage; verborgenes Reasoning sieht er nicht | Bricht den Turn nach 3 Ablehnungen in Folge ab, oder wenn unter den letzten 50 Prüfungen 10 Ablehnungen sind | Aus: Standardmäßig prüfen Sie selbst |
| GitHub Copilot | Assisted Permissions: ein LLM-Richter, dessen Modell automatisch gewählt wird | Steht nicht in der Dokumentation; laut Release Notes geht der sichtbare Shell-Code an den Richter | Fragt Sie, wenn der Richter nicht zustimmt | Aus: eine experimentelle Berechtigungsstufe |
| Cursor | Klassifikator von Auto-Review: Gemini 3.5 Flash Lite, Haiku als Ersatz | Ihre Anfrage und Ihre eigenen Anweisungen; bei Bedarf liest er Ihre Dateien, ohne sie zu ändern | Wird ein Aufruf blockiert, versucht der Agent einen anderen Weg; besteht er darauf, werden Sie gefragt | An: seit dem 29. Mai der empfohlene Standard |
| Antigravity CLI | Auto Mode: Ein eigener Agent prüft Befehle, die die Sandbox verlassen würden | Steht nicht in der Dokumentation | Fragt vor einer Aktion, die sich nicht rückgängig machen lässt | Aus: wird mit --mode auto eingeschaltet |
Quelle: Dokumentation und Release Notes der Tools, 20. Oktober 2026. „Steht nicht in der Dokumentation“ heißt: Auf den Seiten, die wir an diesem Tag gelesen haben, fanden wir keinen Satz dazu. Der Richter von Copilot kam am 7. Juli in die CLI; in der Dokumentation von VS Code ist diese Berechtigungsstufe als experimentell aufgeführt.
In Claude Code ist die Reihenfolge der Entscheidung fest: zuerst Ihre allow-, ask- und deny-Regeln, dann Lese- und Bearbeitungsvorgänge im Arbeitsverzeichnis, zuletzt der Klassifikator. Sobald Sie in den Auto Mode wechseln, fallen breite Regeln weg, die beliebigen Code erlauben, etwa Bash(*) oder Bash(python*); enge Regeln wie Bash(npm test) bleiben. Der Klassifikator sieht keine Tool-Ausgaben; so kann ihn eine Anweisung, die in einer Datei oder auf einer Webseite versteckt ist, nicht direkt lenken. Blockiert er einen Aufruf, steht auf dem Bildschirm Denied by auto mode classifier, daneben der Name der passenden Regel, etwa [Data Exfiltration].
Codex entscheidet sich für das Gegenteil. Auto-Review sieht auch Tool-Ausgaben und macht bei Bedarf selbst Prüfungen, die nur lesen. Es schaut sich aber nur Aufrufe an, die die Grenze der Sandbox überschreiten wollen; ein Befehl, der in der Sandbox bleibt, wird nie geprüft. Laut Dokumentation ist das keine Berechtigung, sondern nur ein anderer Prüfer: Auto-Review erweitert weder die beschreibbaren Verzeichnisse, noch schaltet es das Netz frei. Die Standard-Policy liegt im Open-Source-Repository von Codex, in einem Ordner namens guardian. Schreiben Sie eine eigene Policy, wird sie nicht mit der Standard-Policy zusammengeführt, sondern ersetzt sie. Laut dem Beitrag von OpenAI vom 30. April 2026 lief der Prüfer damals mit GPT-5.4 Thinking; welches Modell es heute ist, steht nicht in der Dokumentation.
Cursor hat Auto-Review am 29. Mai veröffentlicht und bietet es seitdem als empfohlenen Standard an. Der Klassifikator läuft mit kleinen Modellen auf den Servern von Cursor und darf für seine Entscheidung Dateien auf Ihrem Rechner lesen, aber nicht ändern. Bei Copilot kam der Richter zuerst in die CLI. Laut der Dokumentation von VS Code ist Assisted permissions eine experimentelle Stufe: Jeden Tool-Aufruf bewertet ein LLM-Richter; stimmt er nicht zu, werden Sie gefragt. Antigravity CLI hat den Auto Mode am 14. Oktober eingeführt: Er bestätigt Dateiänderungen und sichere Befehle ohne Rückfrage, Befehle, die die Sandbox verlassen würden, prüft vorher ein eigener Agent. Auf der Seite zu den Modi von Antigravity fehlt dieser Modus noch; die Angabe steht in den Release Notes.
Wenn Sie noch Gemini CLI nutzen: Dort ist kein Freigabemodell dokumentiert. Die Policy Engine entscheidet mit festen Regeln, und das Ergebnis bestimmt die erste passende Regel. Google hat Gemini CLI am 18. Juni 2026 für Abonnenten von Google AI Pro und Ultra sowie für kostenlose Einzelnutzer abgeschaltet und diese Nutzer zu Antigravity CLI geschickt; mit einem bezahlten API-Schlüssel können Sie Gemini CLI weiter verwenden. Achten Sie auch auf eine Namensverwechslung: In Copilot und Cursor heißt auch der Router, der ein Modell wählt, “Auto”. Den haben wir im Beitrag über die Modellwahl behandelt; der Auto Mode in diesem Beitrag betrifft Berechtigungen.
Wie oft irrt sich das Freigabemodell?
Das Freigabemodell kann sich auf zwei Arten irren: Es lässt einen gefährlichen Aufruf durch, oder es stoppt einen harmlosen Aufruf unnötig. Im ersten Fall läuft der Befehl; im zweiten versucht der Agent einen anderen Weg oder fragt Sie. Zwei Anbieter messen beides und veröffentlichen es: Anthropic und OpenAI. In der Dokumentation von Cursor, GitHub und Google haben wir keine Messung gefunden. Anthropic hat Menschen und Klassifikator mit denselben Befehlen verglichen:

Diese Zahlen stammen aus Testmengen; im echten Einsatz sieht das Bild weniger gut aus. In Anthropics Engineering-Beitrag vom 25. März 2026 stoppte der Klassifikator bei 10.000 echten Tool-Aufrufen von Mitarbeitern des Unternehmens 0,4 % der harmlosen Aufrufe unnötig. Andererseits ging der Agent in 52 echten Aktionen über das hinaus, was der Nutzer wollte, und der Klassifikator übersah 17 % davon. Der Beitrag nennt diese Zahl selbst “the honest number”. In den meisten übersehenen Fällen erkannte der Klassifikator die Gefahr, nahm aber an, dass die Zustimmung des Nutzers auch diese Aktion abdeckte: “Clean up the PR” ist keine Erlaubnis für einen Force-Push. Damals lief der Klassifikator mit Sonnet 4.6; heute ist das Standardmodell Claude Sonnet 5.
OpenAI hat seine Messung mit synthetischen Daten gemacht. Laut OpenAI fand Auto-Review 90,3 % der Fälle, in denen der Agent über das Verlangte hinausging. Bei Prompt Injection liegt die Trefferquote über drei Angriffsarten bei 99,3 %; zählt man alle Arten mit, auch Löschen und Datenmanipulation, sinkt sie auf 90,2 %. In Red-Team-Übungen fanden sie Fälle, in denen sich Auto-Review dazu bringen ließ, einen Befehl ohne Zustimmung des Nutzers freizugeben; sie schreiben auch, dass sie von dieser Art System keine deterministischen Garantien erwarten. In einem synthetischen Angriffstest, den Anthropic mit einem externen Team machte, sank der Anteil der Angriffe, die der Klassifikator übersah, nach Korrekturen von 12 % auf 7 %; Anthropic bittet, diese Zahl nicht als Anteil übersehener Fälle im echten Verkehr zu lesen. Wie Sie ein Ergebnis lesen, das ein Anbieter selbst meldet, steht im Beitrag über SWE-bench.
Die Dokumentation sagt auch, was das Modell nicht sieht. Das Freigabemodell sieht nur den Aufruf, der gerade vor ihm liegt: In Codex erreichen es Befehle, die in der Sandbox bleiben, gar nicht, in Claude Code ebenso wenig Lese- und Bearbeitungsvorgänge im Arbeitsverzeichnis. OpenAI schreibt, dass ein Modell, das seine Absicht verbirgt, eine harmlos aussehende Anfrage stellen oder in der Sandbox Dinge tun kann, die Auto-Review nie sieht. Der Klassifikator von Claude Code sieht die Ausgabe früherer Befehle nicht. Ist das Ziel eines rm -rf deshalb eine Shell-Variable, deren Wert in der Unterhaltung nie auftauchte, kann er das Löschen nicht prüfen und blockiert es. Eine Grenze, die Sie in der Unterhaltung setzen, etwa „nicht pushen“, wird auch nicht als Regel gespeichert; laut Dokumentation kann diese Nachricht verloren gehen, wenn der Kontext komprimiert wird. Wie das passiert, steht im Beitrag über Auto-Compact. Für ein festes Verbot schreiben Sie eine deny-Regel.
Die Abwägung zwischen übersehener Gefahr und unnötigem Stopp ist dieselbe wie im Code-Review zwischen echtem Fehler und Fehlalarm: Eine Einstellung, die das eine senkt, erhöht das andere. Auch die Anbieter selbst sind deutlich. Cursor schreibt schon in einer Überschrift, dass Auto-Review keine Sicherheitsgrenze ist; VS Code sagt dasselbe über Assisted permissions. OpenAI schreibt, dass Auto-Review keine deterministische Sicherheitsgarantie ist, Anthropic, dass der Auto Mode keine Sicherheit garantiert. Die Grenze zieht die Sandbox.
Was begrenzt eine Sandbox tatsächlich?
Eine Sandbox begrenzt den Befehl, den der Agent ausführt, mit den Mitteln des Betriebssystems: unter macOS mit Seatbelt, unter Linux mit bubblewrap, Landlock oder Kernel-Namespaces. Selbst wenn das Modell sich irrt, kann der Befehl keine Datei beschreiben und keinen Server erreichen, die nicht erlaubt sind. Die Voreinstellungen der fünf Tools sind aber sehr verschieden:
| Tool | Standard | Netz (wenn an) | Geheime Dateien | Bleibt außerhalb |
|---|---|---|---|---|
| Claude Code | Aus; wird mit /sandbox eingeschaltet | Läuft über einen Proxy; die Liste erlaubter Domains ist anfangs leer | Kann den Großteil des Rechners lesen, auch ~/.ssh; keine eingebaute Sperrliste | Datei-Tools wie Read, Edit und Write, Hooks, lokale MCP- und LSP-Server |
| Codex | An: workspace-write | Aus | Die Dokumentation nennt die voreingestellte Lesegrenze nicht; für Pfade wie ~/.ssh empfiehlt sie eine deny-Regel | MCP-Server, Browser, Computer Use und Connectors; jedes mit eigener Einstellung |
| GitHub Copilot | Aus; in der CLI /sandbox enable, in VS Code chat.agent.sandbox.enabled | An; zu jedem Server, bis Sie eine Erlaubnisregel hinzufügen | Dateisystem standardmäßig gesperrt; Git- und gh-Zugangsdaten werden als Platzhalter übergeben | Die eigenen Datei-Tools der CLI (Kontrolle in der Software), entfernte MCP-Server |
| Cursor | An bei Auto-Review; aus bei Run Everything | Aus; der Standard-Netzmodus erlaubt eine Liste von Paket-Registrys, github.com eingeschlossen | Lesegrenze standardmäßig “system”: ~/.ssh ist lesbar | Ein Befehl, der nicht in die Sandbox passt; ihn bestätigt der Klassifikator oder Sie |
| Antigravity CLI | Aus; wird mit enableTerminalSandbox eingeschaltet. In der Antigravity-App unter macOS und Linux an | Aus; nur Domains, die Sie bestätigen | ~/.ssh und .env gesperrt | Ein Befehl, der zu einer unsandboxed(...)-Regel passt oder den Sie bestätigen, mit vollen Rechten |
Quelle: Sandbox-Dokumentation der Tools, 20. Oktober 2026. Die lokale Sandbox von Copilot ist seit dem 7. Oktober allgemein verfügbar. Auch in Gemini CLI schalten Sie die Sandbox selbst ein, per Flag, Umgebungsvariable oder Einstellung.
Die wichtigste Spalte der Tabelle ist die letzte. Laut der Dokumentation von Claude Code deckt die Sandbox nur Shell-Befehle ab: Datei-Tools wie Read und Edit folgen den Berechtigungsregeln, Hooks und lokale MCP-Server laufen mit Ihren vollen Rechten. Laut der Dokumentation von GitHub sieht die Sandbox des Betriebssystems auch nicht, was die eigenen Datei-Tools von Copilot CLI tun; sie begrenzt nur eine Kontrolle in der Software. Warum lokale MCP-Server besondere Vorsicht brauchen, steht im Beitrag über MCP-Sicherheit.
Die meisten dokumentierten Ausbrüche aus der Sandbox kommen genau aus dieser Lücke: Ein Befehl in der Sandbox bereitet etwas vor, ein Teil außerhalb der Sandbox führt es aus oder schreibt auf diesem Weg. In der NVD gibt es drei Beispiele dafür, alle drei behoben:
- Claude Code (CVE-2026-39861, vor 2.1.64): Ein Befehl in der Sandbox konnte einen Symlink anlegen, der aus dem Arbeitsverzeichnis hinauszeigte. Schrieb Claude Code, das außerhalb der Sandbox läuft, auf diesen Pfad, landete die Datei außerhalb des Verzeichnisses. Laut dem Eintrag konnte keiner der beiden allein außerhalb des Verzeichnisses schreiben; der Ausbruch entstand erst, wenn beide zusammenkamen.
- Cursor (CVE-2026-26268, vor 2.5): Ein per Prompt Injection gesteuerter Agent konnte in schlecht geschützte
.git-Einstellungen und Git-Hooks schreiben; Git führte diese Hooks dann von selbst außerhalb der Sandbox aus. Cursor sperrt Schreibzugriffe auf.git/hooksund.git/configinzwischen immer. - Codex (CVE-2026-19591): Der Parser, der sichere Befehle erkennt, hielt einige PowerShell-Befehle fälschlich für sicher, und ein Git-Befehl, der in eine Datei schreibt, konnte ohne Rückfrage laufen. Laut dem Eintrag konnte die Standard-Sandbox unter macOS und Linux das Schreiben an nicht erlaubte Orte trotzdem verhindern: Als die Regelschicht sich irrte, konnte die Sandbox die Grenze halten.
Diese Schwäche der Regelschicht beschreibt auch die Dokumentation von VS Code: Die regelbasierte automatische Freigabe kann einen Befehl nur nach bestem Bemühen zerlegen; verkettete Anführungszeichen oder Shell-Aliase können die Regeln umgehen. Auch beim Netz gibt es eine bekannte Lücke. Laut der Dokumentation von Claude Code entscheidet der Proxy anhand des Domainnamens, den der Client angibt, ohne TLS zu prüfen; deshalb lassen sich mit Techniken wie Domain Fronting Server erreichen, die nicht auf der Liste stehen. Dieselbe Seite warnt, dass eine breite Domain wie github.com einen Weg für den Abfluss von Daten öffnen kann. Auch Fehler der Sandbox selbst tauchen in den Release Notes auf: In Version 2.1.224 wurde ein Fehler behoben, durch den ein denyRead-Eintrag mit abschließendem Schrägstrich unter Linux und macOS unbemerkt umgangen werden konnte.
Auch bei Secrets verhalten sich die Tools unterschiedlich. Claude Code hat keine eingebaute Sperrliste für Zugangsdaten; eingeschränkt werden nur die Dateien und Variablen, die Sie auflisten. Einen Schlüssel können Sie maskieren: Der Befehl sieht statt des echten Werts einen Platzhalter, der nur für diese Sitzung gilt, und der Proxy setzt den echten Wert nur in Anfragen an Server ein, die Sie erlauben. Diese Einstellung liest Claude Code nicht aus der .claude/settings.json im Repository, sondern nur aus den Nutzer- oder den verwalteten Einstellungen. Copilot übergibt die Git- und gh-Zugangsdaten bei aktiver Sandbox standardmäßig auf dieselbe Weise; das echte Token von gh geht nur an Adressen von github.com. Antigravity sperrt ~/.ssh und .env von vornherein. Was bei Copilot ohne Sandbox passiert, schreibt die Dokumentation von GitHub klar: Befehle können mit den Rechten Ihres Kontos überall lesen und schreiben, jedes Netz erreichen, das Ihr Rechner erreicht, und Ihre Zugangsdaten ohne Einschränkung nutzen.
Welcher Modus passt zu welcher Aufgabe?
Alle Belege zeigen in dieselbe Richtung: Das Freigabemodell verringert die Rückfragen, die bei Ihnen landen, die Grenze zieht die Sandbox. Nutzen Sie beides zusammen und wählen Sie die Einstellung nach der Aufgabe:

Bei der täglichen Arbeit, die Sie selbst verfolgen, nutzen Sie das Freigabemodell zusammen mit der Sandbox. In Claude Code ist der Auto Mode ohnehin der Startmodus; schalten Sie mit /sandbox auch die Sandbox ein. In Codex ist die Sandbox schon an; wählen Sie im Berechtigungsmenü “Approve for me”. In Cursor lassen Sie Auto-Review an. In Copilot CLI schalten Sie die Sandbox mit /sandbox enable ein. In Antigravity CLI schalten Sie die Sandbox mit --sandbox ein und wählen --mode auto. Wenn Sie sehen wollen, was das Modell blockiert: Claude Code schreibt die Entscheidung des Klassifikators seit dem 15. Oktober in OpenTelemetry-Events, und Codex legt die Protokolle von Auto-Review unter ~/.codex/sessions ab.
Fragt der Agent ständig um Erlaubnis, stellen Sie die Grenze richtig ein, statt alles freizugeben. Das ist auch die Empfehlung von OpenAI: Landen gewöhnliche Anfragen in der Prüfung, korrigieren Sie zuerst die Grenze der Sandbox und schreiben Sie enge Regeln wie ["cargo", "test"] statt breiter Präfixe wie ["python"]. Wenn Sie in Claude Code keinen Klassifikator wollen, kombinieren Sie den Manual-Modus mit dem Auto-Allow-Modus der Sandbox; Befehle, die in der Sandbox bleiben, laufen dann ohne Rückfrage. Erteilen Sie eine Erlaubnis einmal als enge Regel, nicht jedes Mal, wenn der Agent fragt.
Bei unbeaufsichtigten Läufen ist niemand da, den man fragen könnte. Claude Code startet Läufe mit -p im Manual-Modus, solange Sie keinen Modus angeben, und lehnt Aufrufe ab, die eine Freigabe brauchen. Die Cloud Agents von Cursor laufen auf einer eigenen Maschine und fragen nie nach einer Freigabe. Lassen Sie bei einem solchen Lauf die Sandbox an, beschränken Sie das Netz auf eine Liste von Domains und legen Sie keine Schlüssel in die Umgebung, die der Lauf nicht braucht. Wenn Sie vollen Zugriff geben müssen, dann nur in einem Wegwerf-Container; dort zieht der Container selbst die Grenze. Die Dokumentation von Codex schreibt, dass selbst in einem solchen Container ein bösartiges Projekt alles darin nach außen bringen kann, auch die Zugangsdaten von Codex.
Ein Teil dieser Einstellungen liegt im Repository und kann sich mit einem Pull Request ändern. Claude Code lässt den Auto Mode nicht über die Einstellungsdatei im Repository einschalten; Einträge, die die Grenze lockern, etwa excludedCommands und network.allowedDomains, liest es aber aus dieser Datei, solange ein Admin die Sandbox nicht vorschreibt. Die Dokumentation schreibt, dass der Agent mit einem breiten excludedCommands-Eintrag eine Datei schreiben und sie außerhalb der Sandbox ausführen kann. Cursor führt die .cursor/sandbox.json im Repository mit der Nutzereinstellung zusammen und gibt der Datei im Repository Vorrang; Codex lädt in einem Projekt, dem Sie vertrauen, die .codex/config.toml im Repository. Ein Pull Request, der eine dieser Dateien berührt, ändert die Grenze für alle, die das Repository öffnen; prüfen Sie ihn wie eine Sicherheitsänderung. Sehen Sie sich diese Dateien auch an, bevor Sie ein Repository, dem Sie nicht vertrauen, mit einem Agenten öffnen.
Dasselbe Prinzip wenden wir in unserem eigenen Produkt an. In diffox, unserem Tool für KI-Code-Review, liest der Schritt, der den Blast Radius eines Pull Requests ermittelt, die Dateien des Kunden und ruft niemanden außerhalb auf. Dieser Schritt baut seine Umgebung aus einer Positivliste auf: Außer PATH, HOME, den Spracheinstellungen und dem temporären Verzeichnis übernimmt er keine Variable. Eine Sperrliste würde einen neuen Schlüssel durchlassen, der morgen hinzukommt.
Häufige Fragen
Was ist der Auto Mode in Claude Code?
Der Auto Mode ist einer der Berechtigungsmodi von Claude Code: Ein eigenes Klassifikator-Modell beantwortet die Rückfragen an Ihrer Stelle. Zuerst gelten Ihre allow-, ask- und deny-Regeln, Lese- und Bearbeitungsvorgänge im Arbeitsverzeichnis laufen ohne Rückfrage; die übrigen Aufrufe prüft der Klassifikator, der standardmäßig mit Claude Sonnet 5 läuft. Das Modell ändern Sie mit CLAUDE_CODE_AUTO_MODE_MODEL. Standardmäßig blockiert er das Senden sensibler Daten nach außen, Deployments in die Produktion und Force-Pushes; nach 3 Blockaden in Folge oder insgesamt 20 in einer Sitzung fragt er wieder Sie. Am 14. August wurde er in den Plänen Pro, Max und Team zum Startmodus; seit dem 28. September starten interaktive Sitzungen in jedem Plan in diesem Modus. Die Dokumentation von Anthropic schreibt, dass der Auto Mode keine Sicherheit garantiert.
Was bedeutet “Denied by auto mode classifier”?
Der Klassifikator von Claude Code hat diesen Aufruf als unsicher eingestuft. Der Name in eckigen Klammern, etwa [Data Exfiltration] oder [Production Deploy], ist der Name der passenden Regel. Blockierte Aufrufe sehen Sie in /permissions im Tab Recently denied; mit der Taste r sagen Sie dem Agenten, dass er den Aufruf erneut versuchen darf. Braucht der Agent das Blockierte ständig, etwa eine Paket-Registry oder eine interne Domain, tragen Sie es in autoMode.environment ein; /auto-mode-setup entwirft diese Einträge für Sie. Geht es um etwas Einmaliges, schreiben Sie Ihre Absicht in der nächsten Nachricht klar dazu.
Was unterscheidet Auto-Review und Full Access in Codex?
Beide verringern die Rückfragen, ziehen die Grenze aber an verschiedenen Stellen. Auto-Review (“Approve for me”) lässt die Sandbox workspace-write unverändert; nur Aufrufe, die die Sandbox verlassen wollen, gehen statt an Sie an einen eigenen Prüf-Agenten. Full Access bedeutet sandbox_mode = "danger-full-access" zusammen mit approval_policy = "never": keine Sandbox und keine Rückfrage; der Agent erreicht das Internet und jede Datei auf Ihrem Rechner. In OpenAIs eigener Messung fand Auto-Review 90,3 % der synthetischen Szenarien, in denen der Agent die Grenze überschritt; die Sitzung hielt zudem etwa 200-mal seltener für eine menschliche Freigabe an. Bei Full Access gibt es diese Prüfung gar nicht.
Wie schaltet man die Sandbox in Claude Code ein?
Tippen Sie in der Sitzung /sandbox oder setzen Sie in ~/.claude/settings.json sandbox.enabled auf true. Unter macOS brauchen Sie nichts weiter; unter Linux und WSL2 müssen bubblewrap und socat installiert sein. Unter nativem Windows laufen Befehle ohne Sandbox. Ist sie an, können Befehle ins Arbeitsverzeichnis und ins temporäre Verzeichnis schreiben und ins Netz nur zu Domains, die Sie erlauben. Die Sandbox deckt nur Shell-Befehle ab; Datei-Tools, Hooks und lokale MCP-Server bleiben außerhalb. Wenn Befehle nicht außerhalb der Sandbox erneut versucht werden sollen, setzen Sie allowUnsandboxedCommands auf false.
Kann der Agent mit aktiver Sandbox ~/.ssh lesen?
Das hängt vom Tool ab. Die Sandbox von Claude Code kann standardmäßig den Großteil des Rechners lesen, auch ~/.ssh und ~/.aws/credentials; um das zu sperren, brauchen Sie die Einstellung filesystem.denyRead oder credentials. In Cursor ist die Lesegrenze standardmäßig “system”, und ~/.ssh ist lesbar; wählen Sie “workspace”, bleibt von ~/.ssh nur known_hosts lesbar. Die Sandbox von Copilot sperrt im Dateisystem jeden Pfad, den Sie nicht erlaubt haben, aber mit dem voreingestellten Zugriff auf Entwickler-Tools können Befehle die Tokens lesen, die Paketmanager speichern. Antigravity sperrt ~/.ssh und .env von vornherein. Die Dokumentation von Codex nennt die voreingestellte Lesegrenze nicht klar; für Pfade wie ~/.ssh empfiehlt sie eine deny-Regel.
Warum fragt Claude Code ständig um Erlaubnis?
Meist, weil die Sitzung im Manual-Modus gestartet ist. Seit dem 28. September startet Claude Code interaktive Sitzungen im Auto Mode; zeigt defaultMode in Ihren Nutzereinstellungen aber auf einen anderen Modus, unterstützt Ihr Modell den Auto Mode nicht oder hat Ihre Organisation den Auto Mode abgeschaltet, startet die Sitzung im Manual-Modus. Mit Shift+Tab wechseln Sie in den Auto Mode. Auch im Auto Mode werden Sie bei ask-Regeln wie Bash(git push *) und beim ersten Lesen außerhalb des Arbeitsverzeichnisses gefragt. Wenn Sie keinen Klassifikator wollen, schalten Sie die Sandbox im Auto-Allow-Modus ein; Befehle in der Sandbox laufen dann ohne Rückfrage. Schreiben Sie keine Regel wie Bash(*), die alles öffnet.
Kostet der Auto Mode extra?
Das hängt vom Tool ab. Anthropic berechnet seit dem 7. August in den Plänen Pro, Max und Team nichts für die zusätzlichen Tokens des Klassifikators. Im Enterprise-Plan und bei Konten, die die Claude API, Bedrock, Google Cloud oder Foundry nutzen, zählen die Aufrufe des Klassifikators zum Token-Verbrauch; wird serverseitig geprüft, gibt es keinen eigenen Aufruf. Cursor schreibt, dass der Klassifikator von Auto-Review keine Kosten zur Agent-Nutzung hinzufügt. In der Dokumentation von Codex, Copilot und Antigravity steht nicht, was das Freigabemodell kostet.