Codex danger-full-access, --yolo und der "Unsafe Mode": Was jedes Flag abschaltet

Was macht danger-full-access in Codex tatsächlich?

danger-full-access ist einer der drei Werte des Flags --sandbox in Codex und schaltet die Sandbox vollständig ab. OpenAIs Sandboxing-Dokumentation beschreibt ihn in einem Satz: Der Agent läuft ohne Sandbox-Einschränkungen, was die Grenzen für Dateisystem und Netzwerk aufhebt. Jeder Shell-Befehl, den das Modell erzeugt, läuft dann als Ihr Benutzer, mit Ihren Rechten, auf Ihrem echten Dateisystem, mit Ihrem echten Netzwerk.

Die anderen beiden Werte sind die, die im Alltag zählen:

Zwei Details von workspace-write sollten Sie kennen, bevor Sie ihn für zu restriktiv halten. Erstens ist die beschreibbare Menge nicht nur das aktuelle Verzeichnis: /tmp und $TMPDIR sind standardmäßig beschreibbar, und über sandbox_workspace_write.writable_roots in config.toml lassen sich Pfade ergänzen (die Konfigurationsreferenz bietet außerdem exclude_slash_tmp und exclude_tmpdir_env_var, falls Sie beide ausschließen wollen). Zweitens hat der Netzwerkzugriff einen eigenen Schalter, sandbox_workspace_write.network_access = true. "Ich brauche npm install" ist also ein Argument für einen Booleschen Wert, nicht für Vollzugriff.

Innerhalb jedes beschreibbaren Wurzelverzeichnisses bleiben einige Ordner schreibgeschützt: .git, .agents, .codex und seit Codex 0.159.0 (29. September 2026) auch .aws. Der zugehörige Pull Request nennt den Grund: Ein AWS-Profil kann einen Credential Helper festlegen, den die Anwendung ausführt. Ein Agent, der .aws/config bearbeiten darf, könnte dort also einen Befehl hinterlegen, der beim nächsten AWS-Aufruf startet. Der Schutz verhindert das Schreiben, nicht das Lesen.

Was danger-full-access nicht tut: Codex zum Schweigen bringen. Die Freigabeabfragen hängen an einem separaten Flag, und genau daher stammt der Großteil der Verwirrung im nächsten Abschnitt.

Was entfernt --dangerously-bypass-approvals-and-sandbox?

--dangerously-bypass-approvals-and-sandbox, Alias --yolo, entfernt beide Schutzmechanismen auf einmal: die OS-Sandbox und die Freigabeabfragen. OpenAIs CLI-Referenz beschreibt es so: jeden Befehl ohne Freigaben oder Sandboxing ausführen, nur innerhalb einer von außen gehärteten Umgebung verwenden. Dieser zweite Satz ist die ganze Richtlinie. Das Flag existiert für einen Container oder eine virtuelle Maschine, die selbst die Grenze bildet, nicht für ein Notebook mit Ihren SSH-Schlüsseln, Ihren Cloud-Zugangsdaten und der Produktions-.env.

Der Unterschied zwischen den beiden Mechanismen wird einfach, sobald man sie nebeneinanderlegt:

• Die Sandbox entscheidet, was ein Befehl anfassen kann: welche Pfade beschreibbar sind, ob Sockets geöffnet werden dürfen. Sie wird vom Betriebssystem durchgesetzt, sodass ein Befehl, den das Modell gar nicht ausführen wollte, genauso eingegrenzt bleibt wie ein beabsichtigter.
• Freigaben entscheiden, wann Codex anhält, um Sie zu fragen. Sie sind ein menschlicher Kontrollpunkt und funktionieren nur, wenn ein Mensch sie liest.

danger-full-access allein lässt Ihnen den Kontrollpunkt. --yolo lässt Ihnen nichts außer dem Urteil des Modells, und das Urteil des Modells ist genau das, was eine Prompt Injection in einer README, einer Test-Fixture oder der Fehlermeldung einer Abhängigkeit verbiegen soll. Das ist keine Theorie: Unser Leitfaden zu Sandbox-Ausbrüchen von KI-Coding-Agenten zeigt, wie Repository-Inhalte zu Befehlen werden, und das Muster gilt für Codex unverändert.

Sind -a never, --full-auto und "Unsafe Mode" dasselbe?

Nein. Sie lockern unterschiedliche Schichten, einer der Begriffe ist gar kein Flag, und --full-auto gibt es nicht mehr. Hier die vollständige Karte, inklusive der neueren Flags:

--ask-for-approval kennt nur noch zwei Werte: on-request (der Standard: das Modell fragt, wenn es eskalieren, ins Netzwerk oder aus dem Workspace hinaus will) und never. untrusted wurde mit Codex 0.149.0 (20. August 2026) abgeschafft, und eine Konfiguration, die den Wert noch setzt, kann den Start von Codex verhindern. Ältere Versionen akzeptierten zusätzlich on-failure, das alles in der Sandbox ausführte und nur nachfragte, wenn ein Befehl dort scheiterte; --full-auto war die Kurzform dieser Kombination. Seit 0.128.0 veraltet, ist es seit 0.147.0 (7. August 2026) ganz verschwunden.

Die Voreinstellung "Full access" im interaktiven Auswahlmenü ist die Kombination aus danger-full-access und never, und OpenAI kennzeichnet sie in der eigenen Freigabe-Dokumentation als "not recommended". Es ist --yolo mit freundlicherem Namen.

Was bedeutet "Approve for me" in Codex?

"Approve for me" ist der Berechtigungsmodus von Codex, in dem nicht Sie, sondern ein Prüf-Agent die Freigabeabfragen beantwortet, während die Sandbox workspace-write und die Richtlinie on-request bestehen bleiben. OpenAIs Sandboxing-Leitfaden fasst es so zusammen: dieselbe workspace-write-Sandbox wie bei "Ask for approval", nur dass berechtigte Freigabeanfragen durch eine automatische Prüfung laufen, statt Ihnen zur manuellen Freigabe angezeigt zu werden. Sie wählen den Modus im Berechtigungsmenü unter dem Eingabefeld, in der CLI mit /permissions oder beim Start mit --approve-for-me, einem Flag, das mit Codex 0.147.0 (7. August 2026) kam. In config.toml lautet das approvals_reviewer = "auto_review"; der Standardwert user sind Sie selbst.

Eine weitere Freigaberichtlinie ist das nicht: approval_policy legt fest, wann Codex anhält, der Prüfer legt fest, wer antwortet. OpenAIs Auto-Review-Seite nennt es "a reviewer swap, not a permission grant", also einen Wechsel des Prüfers und keine zusätzliche Berechtigung: Beschreibbare Wurzelverzeichnisse, Netzwerkzugriff und geschützte Pfade bleiben, wie sie sind, und was die Sandbox ohnehin erlaubt, wird nie geprüft. Außerdem braucht der Modus Abfragen: Mit -a never gibt es nichts zu prüfen, und unter danger-full-access oder --yolo kann eine Aktion laufen, ohne je die Anfrage zu erzeugen, die der Prüfer liest. OpenAI warnt, dass Auto-Review keine deterministische Sicherheitsgarantie ist; immerhin unterbrechen drei Ablehnungen in Folge den laufenden Durchlauf.

Ist der Vollzugriff von Codex sicher?

Der Vollzugriff von Codex ist genau so lange sicher, wie es die Umgebung darum herum ist, und unsicher in dem Moment, in dem sie es nicht mehr ist. In einem frischen Container ohne Zugangsdaten, mit einem Wegwerf-Klon und einer Egress-Regel ist danger-full-access ein vertretbarer Tausch: Der Container ist die Sandbox, und die von Codex würde ihn nur bremsen. Auf einem Entwicklerrechner bedeutet er, dass ein Modell mit Ihrer Identität überallhin curl ausführen, überall schreiben und jedes Token in Ihrem Home-Verzeichnis lesen kann, und das Einzige zwischen einer feindlichen Anweisung und diesem Ergebnis ist die Entscheidung des Modells, nicht zu gehorchen.

Die Daten, die wir zu ungeschützten Agenten haben, sind nicht beruhigend. In unserer vorherigen Studie, in der Agenten eine Plattform von Grund auf gegen eine laufende Anwendungsdatenbank bauten, führten zwei ungeschützte Studienarme DROP SCHEMA auf dieser Datenbank sieben- und elfmal aus, achtzehnmal insgesamt, und einer von ihnen setzte rm -rf auf einen absoluten Pfad außerhalb des eigenen Projekts ab. Der geschützte Arm versuchte denselben Schema-Drop ein einziges Mal und wurde abgewiesen. In unserer kontrollierten Studie vom 24. August 2026 prüfte der Befehlswächter 1.769 Shell-Befehle und verweigerte siebzehn. Die Aufschlüsselung zählt mehr als die Summe: ein echter Treffer, ein Agent, der nach gespeicherten Zugangsdaten griff; drei korrekte Anwendungen der Richtlinie auf Befehle, die dort wenig Risiko trugen; und dreizehn False Positives, von denen jeder den Agenten einen Zug kostete. Ein Wächter, der Muster im Text eines Befehls sucht, ist ein Stolperdraht, keine Grenze. Er kann den einen Befehl verweigern, auf den es ankommt, und er löst auch bei harmlosen aus. Genau deshalb zählt die Sandbox: Das Betriebssystem grenzt einen Befehl ein, ohne erraten zu müssen, was er bedeutet.

18

DROP-SCHEMA-Ausführungen gegen eine laufende Datenbank durch ungeschützte Agenten, in unserer vorherigen Studie

1.769

vom Wächter geprüfte Shell-Befehle in unserer kontrollierten Studie vom 24. August 2026

17

verweigerte Befehle: 1 echter Treffer, 3 korrekte Anwendungen der Richtlinie, 13 False Positives

Beachten Sie, wovor der Vollzugriff Sie selbst in einer sauberen Umgebung nicht schützt: vor dem Code. Eine Sandbox grenzt Befehle ein; ob die Autorisierungsprüfung, die das Modell gerade geschrieben hat, korrekt ist, interessiert sie nicht. Darauf kommen wir am Ende zurück.

Wie funktioniert die Codex-Sandbox unter macOS, Linux und Windows?

Codex setzt seine Sandbox mit dem Betriebssystem durch, nicht mit dem Modell, und deshalb hält sie auch dann, wenn das Modell manipuliert wird. Unter macOS nutzt sie Apples Seatbelt-Framework, denselben sandbox-exec-Richtlinienmechanismus, der auch Systemdienste einsperrt, und sie funktioniert ohne Installation. Unter Linux und in WSL2 nutzt sie bubblewrap (bwrap) mit seccomp-Filtern; frühere Versionen setzten direkt auf Landlock und seccomp. Unter Windows nutzt sie eine native Windows-Sandbox, mit oder ohne Elevation, wenn sie aus PowerShell gestartet wird, und den Linux-Mechanismus unter WSL2.

Daraus folgen zwei praktische Konsequenzen. Fehlt bwrap auf einer Linux-Maschine, kann Codex dort keine Sandbox aufbauen: Installieren Sie es, bevor Sie sich geschützt wähnen. Und wird ein Befehl abgelehnt, ohne dass Sie wissen warum, führt codex sandbox einen Befehl unter der aktuellen Richtlinie zu Diagnosezwecken aus, unter macOS mit --log-denials, um auszugeben, was Seatbelt blockiert hat. Das ist das richtige Werkzeug für "Codex kann hier nicht schreiben", und eine deutlich bessere Antwort als der Griff zu danger-full-access.

Seatbelt klärt auch eine Frage, die in Suchanfragen häufig auftaucht: "Codex seatbelt" ist keine Funktion, die man einschaltet. Es ist das Material, aus dem read-only und workspace-write auf einem Mac bestehen.

Wann ist Vollzugriff die richtige Entscheidung?

Vollzugriff ist die richtige Entscheidung, wenn etwas anderes bereits die Grenze bildet. Das Muster, das funktioniert:

Frischer Container oder VM, Wegwerf-KlonKeine langlebigen Zugangsdaten eingebundenEgress auf die benötigten Registries begrenztDann, und nur dann, --yolo

Drei Prüfungen, bevor Sie das Flag setzen:

1. Was kann der Prozess lesen? Sind ~/.ssh, ~/.aws, ~/.codex/auth.json oder eine .env mit aktiven Schlüsseln erreichbar, lautet die Antwort nicht Vollzugriff. Die Codex-Zugangsdatei war bereits Ziel eines bösartigen npm-Pakets; machen Sie es nicht noch leichter.
2. Wohin kann er Daten senden? Unbeschränktes Netzwerk plus Prompt Injection ist ein Exfiltrationskanal. Können Sie den Egress nicht einschränken, lassen Sie network_access aus und lassen Sie Codex fragen.
3. Wer liest die Ausgabe? In codex exec-Pipelines schaut ohnehin niemand auf die Freigaben, was ein Grund ist, sich stärker auf die Sandbox zu stützen, nicht sie zu entfernen.

Scheitert eine der drei Prüfungen, verwenden Sie stattdessen die Konfiguration unten.

Was sollten Sie statt --yolo verwenden?

Für fast jede Aufgabe liefert workspace-write mit on-request-Freigaben, geschlossenem Netzwerk und einem als vertrauenswürdig markierten Projekt einen schnellen Agenten, der seine Spur trotzdem nicht verlassen kann. In ~/.codex/config.toml:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false
writable_roots = ["/Users/sie/scratch"]

[projects."/Users/sie/work/payments-api"]
trust_level = "trusted"

trust_level = "trusted" weist Codex an, die projekteigene .codex/-Konfiguration anzuwenden; nicht vertrauenswürdige Projekte überspringen diese projektbezogenen Schichten, und genau das wollen Sie für ein Repository, das Sie gerade von einem Fremden geklont haben. Wenn die Abfragen das Problem sind, verengen Sie, was sie auslöst, statt sie abzuschalten: Neuere Builds bieten eine granulare approval_policy und die Option approvals_reviewer = "auto_review", die Freigaben an einen automatischen Prüfer weiterleitet. Behandeln Sie Auto-Review als Komfortfunktion, nicht als Grenze: Es ist ein Modell, das ein Modell beurteilt.

Für CI und codex exec behalten Sie die Sandbox und streichen nur die Abfragen: --sandbox workspace-write -a never auf einem Runner ohne Produktionszugangsdaten ist eine stimmige Haltung. --yolo auf demselben Runner ist es nicht, denn die Sandbox hat Sie nichts gekostet.

Die Lücke, die kein Flag schließt

Jedes Flag in diesem Artikel regelt, was Codex ausführen darf. Keines regelt, was Codex schreibt, und im Code sitzt inzwischen der größte Teil des Risikos. Eine workspace-write-Sandbox lässt den Agenten bereitwillig einen Endpunkt ohne Autorisierungsprüfung, einen Erstattungs-Handler ohne Obergrenze oder eine per String-Verkettung gebaute Abfrage committen, denn nichts davon ist ein Befehl. Es sind Diffs.

Das ist die Schicht, die VibeDefend zur Agent-Zeit ergänzt. Sie sitzt in der Codex-Schleife, prüft den Diff, den der Agent gleich schreiben will, gegen Ihre eigenen Regeln, schreibt die unsichere Variante um, bevor sie landet, und bewacht die Shell-Befehle mit derselben Richtlinie, die die siebzehn Verweigerungen oben erzeugt hat, False Positives eingeschlossen. In unserer kontrollierten Studie vom 24. August 2026 setzte der Studienarm mit dieser Schicht 57 von 64 bewerteten Regeldetails exakt um (89 %), gegenüber 7 von 55 (13 %) mit einer von Hand gepflegten Regeldatei im Repository und 8 von 65 (12 %) ohne jedes Hilfsmittel. Die Sandbox hält Codex von Ihrem Rechner fern; der Wächter hält seinen Code aus Ihrer Incident-Warteschlange.

Wenn Sie Codex bewusst mit --yolo betreiben, in einem Container, mit einem Wächter auf dem Diff, haben Sie eine vertretbare Konfiguration. Wenn Sie es mit --yolo auf Ihrem Notebook betreiben, weil die Abfragen nervten, lesen Sie den vollständigen Codex-Sicherheitsleitfaden, vergleichen Sie mit dem YOLO mode in Cursor, der heute Run Everything heißt, und sprechen Sie dann mit uns.

Häufige Fragen

Sind danger-full-access und --yolo dasselbe?

Nein. --sandbox danger-full-access entfernt die OS-Sandbox und behält die Freigabeabfragen. --dangerously-bypass-approvals-and-sandbox (--yolo) entfernt Sandbox und Abfragen. Die Voreinstellung "Full access" im Auswahlmenü entspricht dem zweiten.

Was macht codex --yolo genau?

Es führt jeden vom Modell erzeugten Befehl sofort aus, mit den Rechten Ihres Benutzers, auf Ihrem echten Dateisystem, mit unbeschränktem Netzwerk, und fragt nie nach. OpenAIs Referenz beschränkt es auf eine von außen gehärtete Umgebung, also einen Container oder eine VM, die selbst die Grenze bildet.

Ist -a never für sich genommen gefährlich?

Weniger, als viele annehmen, solange die Sandbox aktiv bleibt. --ask-for-approval never entfernt den menschlichen Kontrollpunkt, aber workspace-write grenzt Schreibzugriffe weiterhin ein, und das Netzwerk bleibt geschlossen, sofern Sie es nicht geöffnet haben. Gefährlich wird es in dem Moment, in dem es mit danger-full-access kombiniert wird.

Was ist der "Unsafe Mode" von Codex?

Ein Flag mit diesem Namen gibt es nicht. "Unsafe Mode", "Dangerous Mode" und "run dangerously" meinen je nach Sprecher danger-full-access, --yolo oder -a never, und das sind drei verschiedene Dinge. Prüfen Sie, was ein Tutorial tatsächlich meint, bevor Sie den Befehl kopieren.

Was bewirkt --dangerously-bypass-hook-trust?

Es führt Ihre aktivierten Hooks ohne die Vertrauensprüfung aus, und zwar nur für diesen einen Aufruf. Seit Codex 0.129.0 (7. Mai 2026) wird ein neuer oder geänderter Hook übersprungen, bis Sie seine genaue Definition in /hooks freigegeben haben; dieses Flag, eingeführt mit 0.131.0 (18. Mai 2026), hebt diese Prüfung für Läufe ohne Oberfläche auf, etwa in der CI. In config.toml wird nichts gespeichert, deaktivierte Hooks bleiben deaktiviert, und Codex zeigt beim Start eine Warnung. OpenAIs CLI-Referenz sieht es nur für Automatisierung vor, die die Herkunft ihrer Hooks bereits selbst prüft. Ein Hook ist ein Skript, das auf Ihrem Rechner läuft: Bei einem Repository, das Sie nicht selbst geschrieben haben, lassen Sie die Prüfung an.

Wie erlaube ich Codex Netzwerkzugriff ohne Vollzugriff?

Setzen Sie network_access = true unter [sandbox_workspace_write] in config.toml, oder übergeben Sie -c sandbox_workspace_write.network_access=true für einen einzelnen Lauf. Schreibzugriffe bleiben auf den Workspace begrenzt; nur das Netzwerk öffnet sich.

Funktioniert die Codex-Sandbox unter Windows?

Ja. Aus PowerShell nutzt sie eine native Windows-Sandbox, mit oder ohne Elevation; unter WSL2 nutzt sie den Linux-Mechanismus (bubblewrap und seccomp). Die Werte von --sandbox und die Schlüssel in config.toml sind auf allen Plattformen gleich.

Stoppt die Sandbox Prompt Injection?

Sie grenzt ein, was ein eingeschleuster Befehl anfassen kann; die Injection selbst stoppt sie nicht. Eine bösartige README kann das Modell weiterhin dazu bringen, unsicheren Code zu schreiben oder eine Eskalation anzufragen, die ein müder Mensch freigibt. Lassen Sie die Sandbox an, und ergänzen Sie eine Schicht, die Code und Befehle prüft, nicht nur Dateipfade.