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.

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, und einer der Begriffe ist gar kein Flag. Hier die vollständige Karte:

--ask-for-approval akzeptiert untrusted (bekannte, sichere Leseoperationen laufen automatisch, alles Zustandsändernde fragt nach), on-request (der Standard: das Modell fragt, wenn es eskalieren, ins Netzwerk oder aus dem Workspace hinaus will) und never. Ä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, weshalb es heute als Kompatibilitäts-Flag überlebt.

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.

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 Aufbau-Studie führten Agenten ohne Schutzschicht achtzehnmal DROP SCHEMA gegen eine laufende Anwendungsdatenbank aus, und einer setzte rm -rf außerhalb des eigenen Projekts ab. Als wir denselben Agenten einen Befehlswächter vorschalteten, prüfte er über die Sitzungen hinweg 1.769 Shell-Befehle und stoppte siebzehn davon im Flug: ein destruktives sudo außerhalb des Projekts, ein Schema-Drop und die Installation eines Pakets, das in der Registry nicht existiert. Siebzehn von 1.769 sind unter einem Prozent, und ein Prozent von "führe jeden Befehl aus" ist genau die Zahl, die zählt, wenn der Befehl destruktiv ist.

18

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

1.769

geprüfte Shell-Befehle in den geschützten Sitzungen derselben Studie

17

im Flug gestoppte Befehle: destruktives sudo, Schema-Drop, nicht existierendes Paket

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 Blockierungen oben erzeugt hat. In unserer Studie hielten Agenten mit dieser Schicht die Sicherheitsregeln bei 89 % der Tickets ein, gegenüber 12 % bei Agenten, die nur eine Regeldatei im Repository hatten. 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 und sprechen Sie mit uns: Die Korrektur dauert etwa eine Minute.

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.

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.