Coding Agents im YOLO-Modus betreiben, ohne den eigenen Rechner zu ruinieren

Einen Coding Agent im YOLO-Modus zu betreiben ist nur dann sicher, wenn man den Schadensradius begrenzt — man macht die Umgebung des Agents wegwerfbar, nicht den Agent vertrauenswürdig. Der Bypass-Permissions-Modus (Claude Codes --dangerously-skip-permissions, Codex’ Full-Auto, Gemini CLIs YOLO) tauscht hundert Bestätigungsklicks gegen einen Agenten ein, der SSH-Schlüssel lesen, Dateien löschen, die Git-Historie korrumpieren und selbst generierten Code Sekunden später ausführen kann — alles ohne Rückfrage. Das lässt sich weder durch blindes Vertrauen in das Modell noch durch eine engere Allowlist beheben. Die Lösung besteht darin, den Agenten an einen Ort zu verlagern, an dem er nichts Wichtiges beschädigen kann — in mehreren Schichten, abgestimmt auf das tatsächliche Risiko.

Dieser Artikel liefert das Risikomodell, eine werkzeugunabhängige Entscheidungsregel für die tatsächlich benötigte Isolationsschicht, die offiziellen Containment-Mechanismen, die Claude Code inzwischen mitliefert, sowie ein kopierfreundliches Mindestsicherheits-Setup mit ehrlicher Einschätzung seiner Kompromisse. Dieses Feld entwickelt sich monatlich weiter, sodass Flags und Werkzeugnamen sich ändern werden — die beständigen Grundbausteine (Container, microVMs, Egress-Proxys, wegwerfbare Workspaces) hingegen nicht.

Was Claude Codes YOLO-Modus 2026 tatsächlich tut

Der Bypass-Permissions-Modus deaktiviert die Bestätigungsdialoge und die meisten Sicherheitsprüfungen, die normalerweise Shell-Befehle und Dateioperationen eines Agents absichern. Gemäß der Dokumentation zu Claude Codes Permission-Modi ist --dangerously-skip-permissions äquivalent zu --permission-mode bypassPermissions. Eingeführt in Claude Code v2.1.126, überspringt dieser Modus auch Schreibvorgänge in geschützte Pfade, für die frühere Versionen noch Bestätigungen einforderten — obwohl rm -rf / und rm -rf ~ weiterhin als Sicherheitsunterbrechungen gegen Modellfehler abgefragt werden und das Flag nun unter Linux und macOS den Start als Root oder unter sudo verweigert. Die Root/sudo-Verweigerung wird in der Dokumentation zum sandboxed Bash-Tool bestätigt und bricht stillschweigend jedes naive Docker-Rezept, das den Agenten als Root ausführt.

Der Grund, warum eine sicherere Allowlist nicht ausreicht, ist struktureller Natur. Least-Privilege-Allowlisting scheitert bei Coding Agents, weil deren gültiger Aktionsraum unbegrenzt ist: Eine einzige legitime Aufgabe kann Pakete installieren, in beliebige Pfade schreiben und frisch generierten Code ausführen. Edera formuliert dies direkt — man kann einem Agenten kein Least Privilege auferlegen, weil der gültige Verhaltensraum nicht aufgezählt werden kann. Jeder Befehl, der destruktiv wirkt, ist zugleich etwas, das ein Agent bei normaler Arbeit ausführt.

Die Fehlermodi sind nicht hypothetisch. Anthropics eigenes Incident-Log hinter dem Auto-Modus beschreibt Agents, die Remote-Git-Branches gelöscht, das GitHub-Auth-Token eines Entwicklers hochgeladen und Migrationen gegen eine Produktionsdatenbank versucht haben. Das ist die eigentliche Bedrohung: kein böser Wille, sondern ein nicht-deterministischer Prozess mit vollem Shell-Zugriff, der etwas Plausibles und Falsches tut.

Den Schadensradius begrenzen: das mehrschichtige Verteidigungsmodell

Das Grundprinzip, von Edera übernommen, besteht darin, dies als Resilienzproblem statt als Richtlinienproblem zu behandeln: akzeptieren, dass früher oder später etwas schiefgehen wird, und sicherstellen, dass der Schaden dann begrenzt bleibt. Man sandboxt den Agenten nicht, weil man erwartet, dass er sich in diesem Lauf danebenbehält; man sandboxt ihn, damit der Lauf, der schiefgeht, einen gelöschten Container kostet statt einem Satz geleakter Zugangsdaten.

Containment hat zwei Achsen, die beide halten müssen. Effektive Isolation erfordert sowohl Dateisystem- als auch Netzwerklimits. Die Claude Code Sandboxing-Dokumentation macht die Abhängigkeit explizit: Ohne Netzwerkisolation kann ein Agent SSH-Schlüssel exfiltrieren, und ohne Dateisystemisolation kann er ausbrechen, um das Netzwerk zu erreichen. Eine Schicht, die nur eine Achse abdeckt, hat eine Lücke.

Keine einzelne Schicht deckt jeden Fehlermodus ab, weshalb das nützliche mentale Modell darin besteht, zu verstehen, was jede Schicht schützt — und was nicht:

Zwei Zeilen verdienen besondere Aufmerksamkeit. Ein Standard-Container begrenzt den Schaden von „mein gesamter Rechner” auf „dieser Projektordner”, teilt sich jedoch den Host-Kernel — er war nie als Sicherheitsgrenze gegen nicht vertrauenswürdigen Code konzipiert, sondern ist eine Isolationshilfe, kein Gefängnis. Und auf der stärksten Ebene verhindert Kernel-Isolation immer noch nicht den Diebstahl von Zugangsdaten oder Datenexfiltration; Edera sagt dies selbst und weist darauf hin, dass Hardware-Isolation kein Schutz gegen Missbrauch von Zugangsdaten oder Netzwerk-Exfiltration bietet — diese müssen durch agentenspezifische Zugangsdaten und Netzwerkrichtlinien abgesichert werden. Secrets aus der Sandbox heraushalten und unabhängig von der gewählten Schicht eine Egress-Allowlist vorschalten.

Welche Schicht wird tatsächlich benötigt?

Die Schicht dem Risiko anpassen: eingebaute Sandbox oder Auto-Modus für alltägliche Bearbeitungen, einen Non-Root-Devcontainer für routinemäßige unbeaufsichtigte Läufe, eine microVM mit eigenem Kernel für vollständig unbeaufsichtigte oder nicht vertrauenswürdige Ausführung und Kernel-Isolation pro Pod nur für gemeinsam genutzte CI- oder Multi-Tenant-Infrastruktur. Es gibt kein einzelnes Werkzeug, das die Antwort ist. Die richtige Antwort ist eine Entscheidungsregel, denn ein Entwickler, der einen Refactoring-Vorgang überwacht, und ein CI-Job, der nicht vertrauenswürdige Pull Requests ausführt, sind nicht demselben Risiko ausgesetzt.

Diese Regel ist eine redaktionelle Synthese, keine Herstelleraussage — aber die Fähigkeiten jeder Schicht darin sind unten belegt. Der Punkt ist, Über- und Unterisolierung zu vermeiden: keine microVM für eine Tippfehlerkorrektur aufsetzen, aber auch keine nicht vertrauenswürdigen Pull Requests in einem Root-Container ausführen, nur weil es bequem ist.

Claude Code liefert bereits mehrere dieser Schichten mit

Die schnellste Absicherung ist die, die man nicht selbst bauen muss, und Claude Code liefert inzwischen mehrere offizielle Isolationsschichten direkt mit. Seit dem 20. Oktober 2025 enthält Claude Code eine OS-Level-/sandbox für sein Bash-Tool, aufgebaut auf Linux bubblewrap und macOS Seatbelt, und hat die zugrundeliegende Engine als Open-Source-Forschungsvorschau veröffentlicht: @anthropic-ai/sandbox-runtime (GitHub-Repo anthropic-experimental/sandbox-runtime, Binary srt). Es handelt sich noch um eine Forschungsvorschau — v0.0.49 vom 3. April 2026 — daher sollte die API als änderungsgefährdet betrachtet werden. Das README des Repos demonstriert die Grenze: Ein sandboxed srt "cat ~/.ssh/id_rsa" wird blockiert, anstatt den privaten Schlüssel auszugeben.

# Open-Source-sandbox-runtime-Demo (Forschungsvorschau, v0.0.49 — APIs können sich ändern)
srt "cat ~/.ssh/id_rsa"   # -> denied: read outside the allowed filesystem

Dieselbe Version vom Oktober 2025 fügte Claude Code im Web hinzu, das Sitzungen in einer isolierten Cloud-Sandbox ausführt, in der Git-Zugangsdaten und Signing-Keys entscheidenderweise nie zusammen mit dem Agenten in der Sandbox liegen.

Die wirklich neue Schicht für 2026 ist der Auto-Modus, veröffentlicht am 24. März 2026. Anthropic stellte fest, dass Nutzer etwa 93 % der Berechtigungsanfragen ohnehin bestätigen, sodass der Auto-Modus Modell-Klassifikatoren einsetzt, um diese automatisch freizugeben, und nach 3 aufeinanderfolgenden oder 20 Gesamtablehnungen an einen Menschen eskaliert — eine Sicherheitsunterbrechung gegen einen kompromittierten oder übereifrigen Agenten. Er ist ausdrücklich als Ersatz für --dangerously-skip-permissions gedacht, ohne die Unterbrechungen zurückzubringen, was bedeutet, dass er für viele alltägliche Aufgaben den Grund entfallen lässt, zum vollständigen Bypass zu greifen. Das ersetzt keine Sandbox für vollständig unbeaufsichtigte Läufe, ändert aber den Standard: seltener zu YOLO greifen und stärker isolieren, wenn man es tut.

Netzwerk und Zugangsdaten absichern

Das Dateisystem abzudichten, ohne den Egress abzusichern, lässt den schlimmsten Exfiltrationspfad offen — die Netzwerkschicht ist daher nicht optional. Das saubere Grundelement ist ein hostseitiger Egress-Proxy mit einer Domain-Allowlist, sodass ein kompromittierter Agent nicht nach Hause telefonieren oder Gelesenes hochladen kann. Docker Sandboxes (sbx) liefern drei Voreinstellungen, die als mentales Modell übernommen werden können: Open (gesamter Traffic erlaubt, CLI allow-all), Balanced (Default-Deny mit erlaubten gängigen Entwickler-Websites, CLI balanced) und Locked Down (alles blockiert, sofern nicht explizit erlaubt, CLI deny-all). Balanced ist der richtige Standard; Open ist bequem, verfehlt aber den Zweck bei unbeaufsichtigtem Betrieb.

Zugangsdaten erfordern gesonderte Behandlung, da der einfachste Weg, sie zu leaken, darin besteht, sie einzumounten. ~/.ssh, ~/.aws oder .env-Dateien nicht in die Agentenumgebung mounten — wenn das Secret nicht in der Sandbox ist, kann der Agent es nicht lesen. Wenn der Agent sich tatsächlich gegenüber einer Modell-API oder einem Dienst authentifizieren muss, das Zugangsdatum am Proxy injizieren statt es dem Agenten direkt zu übergeben. Dockers sbx macht genau das: Sein hostseitiger Forward-Proxy injiziert Auth-Header für KI-Dienste, sodass die eigentlichen Zugangsdatenwerte nie innerhalb der VM gespeichert werden, wie in der Isolationsdokumentation beschrieben. Diese MITM-artige Auth-Header-Injektion ist das Muster, nach dem man in jeder adoptierten Sandbox suchen sollte.

Git absichern

Git ist der Fehlermodus, den Menschen unterschätzen, denn ein gemountetes .git-Verzeichnis ist für den Agenten vollständig beschreibbar. Die Gegenmaßnahme besteht darin, im Branch- oder Worktree-Modus zu arbeiten, sodass der Agent in einen wegwerfbaren Branch committet, nicht in die Hauptlinie. Andrew Locks Walkthrough von sbx zeigt das Muster — sbx run claude --branch my-feature/auto platziert den Agenten in einem Git-Worktree unter .sbx/, den man dem globalen Gitignore hinzufügt.

Der ehrliche Vorbehalt: Der Branch-Modus verringert die Wahrscheinlichkeit, dass ein fehlerhafter Commit auf main landet, dichtet Git aber nicht vollständig ab. Wie Lock anmerkt, hat der Agent grundsätzlich Zugriff auf das Git-Verzeichnis und könnte das Repository daher noch korrumpieren — weshalb die einzige echte Absicherung ein Remote-Backup ist, von dem man neu klonen kann. Wenn das Repository nicht per git clone wiederhergestellt werden kann, ist es nicht gesichert.

Ein minimales sicheres Setup zum Kopieren

Für die meisten lokalen Arbeiten ist ein Non-Root-Devcontainer der richtige Ausgangspunkt: Er begrenzt den Agenten auf das Projekt, dient gleichzeitig als Ein-Befehl-Onboarding für neue Entwickler und erfüllt die eigene Anforderung des Flags, dass der Bypass-Modus nicht als Root ausgeführt werden darf. Eine minimale .devcontainer/devcontainer.json sieht so aus:

{
  "name": "agent-sandbox",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "remoteUser": "node",
  "workspaceFolder": "/workspace",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind"
}

Die entscheidende Zeile ist "remoteUser": "node" — ein Non-Root-Benutzer, da --dangerously-skip-permissions den Start als Root oder unter sudo verweigert. Nur das Projektverzeichnis mounten; Home-Verzeichnis oder Credential-Pfade nicht mounten. Den Agenten innerhalb des Containers installieren, ihn über eine Egress-Allowlist auf die Modell-API zeigen und laufen lassen.

Bei vollständig unbeaufsichtigtem Betrieb oder der Ausführung von Code aus nicht vertrauenswürdigen Pull Requests oder beliebig generierten Skripten auf eine microVM mit eigenem Kernel umsteigen:

# Docker Sandboxes: eine microVM pro Agent, mit eigenem Kernel und Docker-Daemon
sbx run claude        # startet eine isolierte microVM und führt im Bypass-Modus aus

Die sbx-CLI ist kostenlos nutzbar, auch für kommerzielle Zwecke — nur organisationsweite Governance erfordert ein kostenpflichtiges Abonnement — und läuft inzwischen auf macOS, Windows und Linux mit Unterstützung für Claude Code, Codex, Copilot, Gemini, Droid, Kiro, OpenCode und mehr. Unter Linux muss KVM-Hardware-Virtualisierung aktiviert und der eigene Benutzer der kvm-Gruppe hinzugefügt sein (siehe Einstiegsleitfaden).

Die Kompromisse sind real und es lohnt sich, sie zu benennen:

• microVMs verursachen Performance-Overhead auch bei einfachen Projekten;
• Commit-Signing über Host-SSH-Agents lässt sich nicht sauber in Sandboxes weiterleiten, weshalb ein üblicher Workaround darin besteht, innerhalb unsigniert zu committen und auf dem Host per Rebase zu signieren; und
• eine Default-Deny-Netzwerkrichtlinie erfordert Pflege, bevor sie aufhört, störend zu sein.

Über den eigenen Rechner hinaus: gemeinsam genutzte und CI-Infrastruktur

Sobald ein Agent auf Infrastruktur läuft, die von anderen Tenants oder CI-Jobs gemeinsam genutzt wird, reichen die Laptop-Schichten nicht aus, da ein gemeinsamer Host-Kernel bedeutet, dass ein Kernel-Exploit eines Jobs alle Workloads auf dem Knoten erreichen kann. Die Lösung auf dieser Ebene ist Kernel-Isolation pro Pod — jedem Agenten einen eigenen Linux-Kernel in einer Hardware-Sandbox geben, über Runtimes wie Edera, Kata Containers oder gVisor. Edera gibt an, jede Workload in ihrem eigenen Kernel auszuführen und dabei innerhalb von 5 % der nativen Performance zu bleiben, mit veröffentlichten Benchmarks unter arXiv:2501.04580; das sind vom Hersteller veröffentlichte Zahlen, und der Zugang zu Edera erfolgt über deren Team statt über einen öffentlichen Download. Diese Ebene ist für den Laptop eines einzelnen Entwicklers überdimensioniert — sie für den Fall reservieren, für den sie gebaut wurde: Multi-Tenant- oder CI-Infrastruktur, bei der die Kompromittierung eines Tenants nicht zur Kompromittierung aller werden darf.

Die niedrigste Schicht wählen, die das eigene Risiko tatsächlich abdeckt, Secrets aus dem Container des Agenten heraushalten und eine Allowlist vor sein Netzwerk schalten. Dann kostet das nächste Mal, wenn der Agent etwas Plausibles und Falsches tut, das Löschen eines Containers statt des Wiederaufbaus des gesamten Rechners.

FAQs

Was ist der Unterschied zwischen Claude Codes Auto-Modus und dem Bypass-Permissions-Modus?

Der Bypass-Permissions-Modus (--dangerously-skip-permissions) deaktiviert Bestätigungsdialoge und die meisten Sicherheitsprüfungen vollständig und gibt jeden Befehl ohne Beurteilung frei. Der Auto-Modus, veröffentlicht im März 2026, nutzt Modell-Klassifikatoren, um automatisch nur die routinemäßigen Prompts zu genehmigen, die Nutzer ohnehin bestätigen (etwa 93 Prozent), eskaliert riskante Aktionen aber weiterhin an einen Menschen und stoppt den Agenten nach 3 aufeinanderfolgenden oder 20 Gesamtablehnungen. Der Auto-Modus ist darauf ausgelegt, den vollständigen Bypass für alltägliche Arbeit zu ersetzen, ohne ständige Unterbrechungen zurückzubringen.

Macht das Ausführen eines Coding Agents in einem Docker-Container den YOLO-Modus sicher?

Ein Standard-Docker-Container begrenzt den Schaden von dem gesamten Rechner auf einen Projektordner, ist aber keine vollständige Sicherheitsgrenze, da er den Host-Kernel teilt und nie dafür konzipiert wurde, nicht vertrauenswürdigen Code einzuschließen. Für routinemäßige unbeaufsichtigte Läufe auf eigenem Code ist ein Non-Root-Container vertretbar, aber für die Ausführung von nicht vertrauenswürdigem oder frisch generiertem Code wird eine microVM mit eigenem Kernel benötigt. Container erfordern außerdem einen Non-Root-Benutzer, da der Bypass-Modus den Start als Root oder unter sudo verweigert.

Warum reicht es nicht, stattdessen eine engere Allowlist zu schreiben, anstatt den Agenten zu sandboxen?

Least-Privilege-Allowlisting scheitert bei Coding Agents, weil deren gültiger Aktionsraum unbegrenzt ist. Eine einzige legitime Aufgabe kann Pakete installieren, in beliebige Pfade schreiben und Sekunden zuvor generierten Code ausführen — jede Regel, die streng genug ist, um Schaden zu verhindern, blockiert auch normale Arbeit. Jeder Befehl, der destruktiv wirkt, ist etwas, das ein Agent bei gewöhnlicher Arbeit ausführt. Der zuverlässige Ansatz ist Containment: den Agenten in eine wegwerfbare Umgebung stecken, die dem eigenen Risiko entspricht, anstatt zu versuchen, im Voraus alle sicheren Aktionen aufzuzählen.

Schützt das Sandboxen des Dateisystems des Agents auch Zugangsdaten und SSH-Schlüssel?

Nein. Dateisystem-Isolation und Netzwerk-Isolation sind separate Achsen, und beide müssen halten. Ohne Netzwerklimits kann ein kompromittierter Agent SSH-Schlüssel exfiltrieren, die er lesen kann; ohne Dateisystemlimits kann er ausbrechen, um das Netzwerk zu erreichen. Selbst Kernel-Level-Isolation schützt allein nicht vor Diebstahl von Zugangsdaten oder Datenexfiltration. Secrets vollständig aus der Sandbox heraushalten, indem Pfade wie SSH- oder AWS-Verzeichnisse nie gemountet werden, Zugangsdaten bei Bedarf an einem Egress-Proxy injizieren und dem Agenten eine Domain-Allowlist vorschalten.