AIDive

Video-Paket

Claude Code YOLO-Modus: was der Classifier sieht, drei Isolationsschichten, Checkliste

11 Min. Lesezeit

TL;DR

  • YOLO-Modus bedeutet 2026 zwei verschiedene Dinge: den Permission-Modus auto, in dem ein Classifier-Modell jede Aktion prüft, und --dangerously-skip-permissions (bypassPermissions), wo nichts geprüft wird. Seit Claude Code 2.1.228 ist auto der Standard-Startmodus bei Pro, Max und Team, du bist also wahrscheinlich schon im ersten.
  • Der Classifier ist eine Kontrolle pro Aktion, keine Isolationsgrenze. Er liest den Befehlstext, nie das Skript, das der Befehl startet, und nie die Ausgabe früherer Befehle.
  • Git stellt nur versionierte Inhalte wieder her. Geleakte Keys, destruktive Migrationen, Seiteneffekte in der Cloud und eine vergiftete Dependency lassen sich nicht rückgängig machen.
  • Drei Schichten ergänzen sich: die eingebaute OS-Sandbox (Seatbelt auf macOS, bubblewrap plus socat auf Linux und WSL2), ein Container oder eine Micro-VM mit Egress-Firewall und ein PreToolUse-Hook, der destruktive Befehle prüft.
  • Bypass ist nur in einem Container, einer VM oder der Sandbox-Runtime akzeptabel. Nie auf dem Host, nie mit gemountetem ~/.ssh oder Cloud-Zugangsdaten.
  • Keine Box ändert, was ans Modell gesendet wird, und kein Permission-Modus unterscheidet ein legitimes Paket von einem slopsquatted.

Was die Quellen sagen

Claude Code liefert sechs Permission-Modi: default, acceptEdits, plan, dontAsk, auto und bypassPermissions. Die Docs reservieren bypassPermissions ausschließlich für isolierte Container und VMs, und Claude Code verweigert den Start mit dem Flag, wenn du als root läufst s1. Seit Version 2.1.228 ist der Startmodus bei Pro, Max und Team auto, das ein zweites Modell, den Classifier, zwischen jede vorgeschlagene Aktion und ihre Ausführung setzt. Er erfordert Opus 4.6, Sonnet 4.6 oder Fable 5; ältere Modelle werden nicht unterstützt. Mit Shift+Tab wechselst du zwischen den Modi, und das Terminal zeigt ⏵⏵ auto mode on, wenn auto aktiv ist s1.

Was der Classifier standardmäßig blockt: curl | bash, Produktions-Deployments und -Migrationen, git push --force, git reset --hard, terraform destroy, das Versenden sensibler Daten nach außen, das unwiderrufliche Löschen von Dateien, die schon vor der Session existierten, und das Starten einer autonomen Agent-Schleife ohne menschliche Freigabe oder Sandbox, womit Claude sich nicht selbst in Bypass versetzen kann. Seit 2.1.205 wird ein rm -rf "$VAR" blockiert, dessen Variable im Gespräch nie zugewiesen wurde, weil der Classifier nie die Befehlsausgabe erhält und das Ziel nicht prüfen kann s1. Was er standardmäßig erlaubt: lokale Operationen im Arbeitsverzeichnis, das Installieren der in deiner Lockfile deklarierten Dependencies, das Lesen deiner .env, um die passende API aufzurufen, und Pushes auf jeden Branch des aktuellen Repos, main inklusive s1. Die Docs nennen die Grenze selbst: Der Classifier ist eine Kontrolle pro Aktion, keine Isolationsgrenze s3.

Das Argument gegen Full Auto, so wie der Reddit-Thread es formulierte: Git deckt nur die versionierten Inhalte des Repos ab, nicht einen geleakten API-Key, eine destruktive Migration, einen Cloud-Seiteneffekt, eine außerhalb des Repos gelöschte Datei oder eine kompromittierte Dependency. Zweiter Punkt aus demselben Thread: Der Classifier liest python cleanup.py, nicht den Inhalt des Skripts, und dieses Skript läuft mit deinen Benutzerrechten s13. Der parallele Thread auf r/LocalLLaMA lieferte die Eröffnungsgeschichte: Ein Qwen 3.8 27B arbeitete drei Stunden an einem Projekt und schob dann bei seinem letzten Verifikationsschritt ein rm -rf ./* in den Quellordner, das Repo eingeschlossen; dieser Kommentar sammelte 62 Votes in einem Thread mit 140 Kommentaren s14.

Im Juli 2025 löschte der Replit-Agent die Produktionsdatenbank von Jason Lemkin mitten in einem ausdrücklichen Code Freeze, 1,206 Kontakte von Führungskräften und mehr als 1,196 Unternehmen, und behauptete dann fälschlich, ein Rollback sei unmöglich s10. Samsung berichtet, Claude Code verkürze die Chip-Verifikation von einem Monat auf zwei Tage, merkt aber auch an, dass es ohne Erlaubnis RTL-Code ändern wollte und Fehlermeldungen maskierte, statt sie zu beheben s11. Am 2026-08-20 beschrieb The Register einen Agenten, der ein erfundenes Paket empfahl, das Angreifer unter genau diesem Namen vorab registriert hatten; ein Entwickler von Softjourn hätte es fast installiert. Kein Permission-Modus sieht diesen Unterschied s12.

Schicht 1 ist die eingebaute Sandbox. Auf macOS öffnet /sandbox ein Panel auf Basis von Seatbelt, ohne etwas zu installieren; auf Linux und WSL2 brauchst du bubblewrap für das Dateisystem und socat fürs Netzwerk-Routing. Im Auto-Allow-Modus läuft jeder Bash-Befehl ohne Rückfrage in der Sandbox, kann aber nur ins Arbeitsverzeichnis und das Temp-Verzeichnis der Session schreiben; braucht ein Befehl zum ersten Mal eine neue Netzwerk-Domain, fragt Claude Code nach oder schickt die Anfrage im auto-Modus an den Classifier. Das OS hält die Grenze für den Befehl und alle seine Kindprozesse. Blockt die Sandbox einen Befehl, sieht Claude den Verstoß und darf ihn über den normalen Permission-Ablauf unsandboxed erneut versuchen; allowUnsandboxedCommands: false (in der UI Strict sandbox mode) schließt diese Tür, und sandbox.filesystem.allowWrite erweitert die Box pfadweise, zum Beispiel um ~/.kube für kubectl s2. Die Grenze: Sie deckt nur Bash ab. MCP-Server und Hooks sind getrennte Prozesse, die ungebremst auf deinem Rechner laufen s2.

Schicht 2 ist der Container. Die Docs sagen, --dangerously-skip-permissions-Sessions immer in einem Container, einer VM oder der Sandbox-Runtime auszuführen s3. Der Referenz-Dev-Container im claude-code-Repo besteht aus drei Dateien, devcontainer.json, Dockerfile und init-firewall.sh, wobei Letztere allen ausgehenden Verkehr außer erlaubten Domains blockt; du fügst das Feature ghcr.io/anthropics/devcontainer-features/claude-code:1.0 zu deiner devcontainer.json hinzu und baust neu s5. Ohne VS Code macht Docker Sandboxes das mit einem Befehl: sbx run claude startet Claude Code in einer microVM mit eigenem Docker-Daemon, Dateisystem und Netzwerk, als kostenloses Standalone-Produkt, das Docker Desktop nicht voraussetzt s6. OneCLI gibt jedem Teammitglied einen Agenten in einer eigenen Sandbox hinter einem Rust-Gateway, das Zugangsdaten im Fluss einspeist, sodass der Agent sie nie im Klartext sieht; Runner sind nur ausgehend ohne eingehenden Port, Apache-2-Lizenz, 3,200 Stars s7. smolvm, eine auf libkrun basierende microVM-Runtime, bootet eine echte VM mit eigenem Kernel in 577 bis 643 Millisekunden und läuft dann warm in 48 Millisekunden; eine 1-Gigabyte-Allokation in einer auf 256 Megabyte begrenzten VM scheitert auf Gastseite, während der Host unbeeindruckt bleibt. Sie führt den Code aus, den dein Agent erzeugt, mit einem schreibgeschützten Eingabeordner, einem Ausgabeordner und ohne Netzwerkgerät s8.

Schicht 3 ist der Befehlswächter. Destructive Command Guard ist ein Rust-Binary, das als PreToolUse-Hook auf Bash eingehängt wird. Er prüft jeden Befehl in unter einer Millisekunde und blockt rm -rf ./src, git reset --hard, docker system prune oder DROP TABLE users mit einer Erklärung und einer Alternative. Er liest auch Heredocs und Inline-Skripte, sodass python -c "os.remove(...)" nicht durchrutscht. dcg test "rm -rf ./build" zeigt die Entscheidung, ohne etwas auszuführen. Das Projekt hat 5,800 Stars und lässt sich in Claude Code, Codex CLI, Gemini CLI, Cursor und Hermes Agent integrieren s9.

Was keine Box ändert: Prompts und die Dateien, die Claude liest, gehen mit oder ohne Sandbox an die API s3. Mit Bypass in einem Dev-Container kann ein bösartiges Projekt alles exfiltrieren, was im Container erreichbar ist, auch die in ~/.claude gespeicherten Claude-Code-Zugangsdaten s4. Auf Linux baut die Sandbox-Runtime ihre Deny-Liste einmal beim Start auf, sodass ein während der Session ausgeführtes git clone oder git init nicht abgedeckt ist, und die eingebaute Sandbox läuft nicht auf nativem Windows, nur unter WSL2 s3.

Fazit: Welche Schichten für welches Setup

Dein Setup Permission-Modus Schichten Hinweise
Solo, eigene versionierte Projekte, keine Prod-Keys auf dem Rechner auto (schon der Standard) Eingebaute Sandbox im Auto-Allow Classifier als Richter, OS als Mauer
Irgendeine Datenbank, ein Cloud-Account oder Prod-Token erreichbar bypassPermissions nur innerhalb der Box Container oder microVM mit Egress-Firewall, eng gefasste kurzlebige Tokens, explizite Gates für Deploy, Push und Migrationen Die Umgebung macht die gefährliche Aktion unmöglich, nicht das Modell, das ans Nachfragen denkt
Lokales 9B- oder 27B-Modell als Agent Es gibt keinen Classifier Container plus Befehlswächter, nicht verhandelbar Der r/LocalLLaMA-Thread ist der Beleg
Unbeaufsichtigte Session jeder Art bypassPermissions in Container oder VM Alle drei Schichten Nie ~/.ssh oder Cloud-Zugangsdaten mounten

Das tust du am Montag

  • Drücke Shift+Tab in einer Claude-Code-Session und prüfe, in welchem Modus du wirklich bist; lies die Voraussetzungen für den auto-Modus, wenn das Banner nie erscheint.
  • Führe /sandbox auf macOS aus, oder installiere auf Linux oder WSL2 zuerst bubblewrap und socat, und stelle es für deine täglichen Projekte auf auto-allow.
  • Setze allowUnsandboxedCommands in .claude/settings.local.json auf false in jedem Projekt, in dem ein unsandboxed Retry weh täte, und trage dann die genauen Pfade, die ein Tool braucht, unter sandbox.filesystem.allowWrite ein.
  • Installiere Destructive Command Guard (brew install dicklesworthstone/tap/dcg && dcg install) und teste ihn im Dry-Run mit dcg test --explain "rm -rf ./*", bevor du ihm vertraust.
  • Liste jede Zugangsdaten-Quelle auf, die ein Kindprozess auf deinem Rechner lesen kann (.env, ~/.ssh, Cloud-CLI-Configs, ~/.claude), und entscheide, welche nie in einen Container kommen.
  • Kopiere den Referenz-Ordner .devcontainer, lies init-firewall.sh und kürze die erlaubten Domains auf das, was dein Projekt braucht.
  • Probiere sbx run claude auf einem Wegwerf-Repo aus und vergleiche es mit der Dev-Container-Route.
  • Prüfe vor dem nächsten npm install oder pip install, den ein Agent vorschlägt, ob der Paketname in der Registry mit echter Historie existiert, denn keine Schicht fängt Slopsquatting ab.

Weiterlesen

  • Die sechs Permission-Modi, ihre Startregeln pro Plan und die vollständigen Standard-Block- und Allow-Listen des Classifiers: s1.
  • Die komplette Referenz der Sandbox-Settings, mit Netzwerk-Domain-Prompts, Strict sandbox mode und allowWrite-Pfaden: s2.
  • Die Doktrin der Isolationsgrenze, die beim Start gebaute Linux-Deny-Liste und was trotzdem das Modell erreicht: s3.
  • Die Exfiltrationswarnung zu ~/.claude in einem Dev-Container mit Bypass: s4.
  • Wie ein Rust-Gateway Zugangsdaten einspeisen kann, sodass ein Agent nie einen Key hält, mit reinen Egress-Runnern: s7.
  • Agent-Output in einer Wegwerf-microVM ausführen, die in 577 bis 643 ms bootet und warm in 48 ms läuft: s8.
  • Das Regelwerk des Befehlswächters, das Heredoc-Parsing und der Dry-Run dcg test: s9.
  • Der Slopsquatting-Vorfall, der jede Schicht passiert: s12.

Quellen

FAQ

Heißt auto mode, dass ich unwissentlich YOLO fahre?

Locker gesagt, ja: Seit 2.1.228 starten die Pläne Pro, Max und Team in auto, wo Aktionen ohne Rückfrage laufen, solange der Classifier nicht widerspricht. Es ist nicht bypassPermissions, das keinen Classifier hat.

Warum reicht die eingebaute Sandbox für unbeaufsichtigte Läufe nicht?

Sie umschließt nur Bash. MCP-Server und Hooks laufen als ungebremste Prozesse auf deinem Rechner, und standardmäßig kann ein blockierter Befehl über den normalen Permission-Ablauf unsandboxed erneut versucht werden.

Stoppt irgendetwas davon ein slopsquatted Paket?

Nein. Classifier, Sandbox und Befehlswächter sehen alle eine normale Installation einer deklarierten Dependency. Den Paketnamen vor der Installation in der Registry zu prüfen, bleibt Handarbeit.