Codex soll Dateien ändern, Befehle ausführen und einfach weiterarbeiten, statt bei jedem Schritt auf eine Bestätigung zu warten. Doch selbst mit aktivem „Full Access“ tauchen oft weiter Rückfragen auf. Der Grund: Vollautomatik ist in Codex kein einzelner Schalter. Hier kommt zuerst die getestete Kurzlösung für Codex CLI v0.145.0, danach die Details.
Warum das passiert: Codex trennt drei Dinge voneinander: Die Sandbox legt fest, worauf der Agent zugreifen darf, die Approval Policy bestimmt, wann er anhält und nachfragt, und der Netzwerkzugriff ist eine weitere separate Schranke. Wer nur eine davon lockert, öffnet nicht automatisch die anderen. Außerdem kann ein Codex-Update die laufende Sitzung unbemerkt wieder auf die Standardrichtlinie zurücksetzen.
Ohne Rückfragen in der CLI: Nur --yolo hebt alle Schranken zugleich auf. Soll die Sandbox erhalten bleiben, müssen beide Achsen explizit gesetzt werden. Am besten gleich beim Start der Sitzung – und nach jedem Update erneut kontrollieren.
# Wirklich ohne Eingriffe — keine Sandbox, keine Rückfragen (nur in einer Wegwerf-Umgebung):
codex --yolo
# Sicherer — freie Änderungen im Projekt, Rückfrage beim Verlassen des Projekts:
codex --sandbox workspace-write --ask-for-approval on-requestOhne Rückfragen in der App: Im Freigabemenü Full access auswählen und die Einstellung nach jedem Update erneut setzen – Upgrades setzen den Modus zurück.
Das ist die Kurzantwort. Der Rest des Leitfadens ordnet alle Modi ein, zeigt ihre Zuordnung unter der Haube und hilft bei der Auswahl.
Die drei Codex-Modi im Vergleich
Die Sandbox bestimmt, auf welche Dateien und Netzwerkressourcen der Agent zugreifen darf. Die Approval Policy regelt dagegen, wann er um Erlaubnis bittet. Auto Mode kombiniert lediglich beides; Desktop-App und CLI bezeichnen dieselben Kombinationen nur unterschiedlich.
| Bezeichnung in der App | Verhalten | Entsprechung in der CLI |
|---|---|---|
| Ask for approval | Bearbeitet Dateien im Workspace und führt übliche lokale Befehle aus; fragt vor Internetzugriffen oder Aktionen außerhalb des Workspaces | sandbox_mode = "workspace-write" + approval_policy = "on-request" |
| Approve for me (aktueller Standard der App) | Gleiche Grenzen, aber zulässige Freigabeanfragen gehen an einen KI-Reviewer statt an dich (das ist Auto-review) | wie oben + approvals_reviewer = "auto_review" |
| Full access | Keine Sandbox, keine Freigabeanfragen, uneingeschränkter Datei- und Netzwerkzugriff | sandbox_mode = "danger-full-access" + approval_policy = "never" |
Wer hauptsächlich mit der CLI arbeitet, setzt diese Werte direkt über --sandbox und --ask-for-approval oder wechselt während einer Sitzung über die Auswahl /permissions zwischen Voreinstellungen. Falls die Wahl zwischen Clients grundsätzlich noch offen ist: Hier haben wir Codex und Claude Code verglichen. In diesem Beitrag geht es um die Einstellungen selbst.
Warum „Full Access“ trotzdem nach einer Freigabe fragt
Dafür gibt es drei Ursachen, die auch zusammen auftreten können.
Sandbox und Freigaben sind getrennte Einstellungen. workspace-write + on-request erlaubt Codex freie Änderungen innerhalb des Projekts, lässt den Agenten aber an dessen Grenzen anhalten: etwa bei Netzwerkzugriffen, Dateien außerhalb des Repos oder sudo. Wird nur die Sandbox gelockert, während Freigaben weiter auf Anfrage stehen, erscheinen an diesen Grenzen weiterhin Prompts.
Das Netzwerk hat seine eigene Schranke. Full Access kann den Internetzugriff weiterhin getrennt vom Dateisystem behandeln. Wie @mxcl am 16. Juli 2026 schrieb, kann Codex „without full access“ nicht ins Internet und beendet die Aufgabe, bis der Nutzer Full Access aktiviert. Schreibzugriff auf Dateien und Netzwerkzugriff sind also nicht dieselbe Berechtigung.
Updates setzen den Modus zurück. Mehrere Nutzer berichteten Ende Juli 2026 davon, dass ein Codex-Upgrade aktive Sitzungen stillschweigend auf die Standardrichtlinie zurückstellt. @s_rafcon schrieb am 22. Juli, Threads würden „switch their Full access flag to the default flag“ und dann bei jeder einzelnen Bearbeitung wieder nach einer Freigabe fragen. Den Modus deshalb zu Beginn jeder Sitzung setzen und nach jedem Update prüfen.
CLI-Umstellung: --full-auto gibt es nicht mehr
codex --full-auto war früher die Abkürzung für „ohne Nachfragen in meinem Projekt arbeiten“: approval_policy = "on-request" plus sandbox_mode = "workspace-write". Der interaktive Befehl akzeptiert das Flag inzwischen nicht mehr. Getestet mit v0.145.0:
$ codex --full-auto
error: unexpected argument '--full-auto' foundStattdessen beide Achsen explizit setzen – genau das hat das frühere Flag getan:
# Moderner Ersatz für --full-auto
codex --sandbox workspace-write --ask-for-approval on-request
# Oder nicht interaktiv: keine Rückfragen, Sandbox bleibt aktiv:
codex -a never -s workspace-write exec "your task"Für Skripte akzeptiert codex exec --full-auto das Flag weiterhin; nur der interaktive Befehl schlägt fehl. Laut codex --help akzeptiert --ask-for-approval die Werte untrusted / on-request / never; für --sandbox stehen read-only / workspace-write / danger-full-access bereit. Jeder App-„Modus“ ist letztlich eine Kombination dieser beiden Werte.
--yolo: Wann der komplette Bypass sinnvoll ist
--yolo ist die Kurzform von --dangerously-bypass-approvals-and-sandbox. Das ist der echte „einfach laufen lassen“-Schalter: danger-full-access plus never, also keine Dateisystemgrenze und keine Freigabeprüfung. Anders als --full-auto blieb das Flag erhalten – gerade weil der Name das Risiko unmissverständlich signalisiert. Auf v0.145.0 funktioniert codex --yolo problemlos, während codex --full-auto einen Fehler ausgibt.
Viele erfahrene Nutzer verwenden es standardmäßig – und für die passende Aufgabe ist das durchaus nachvollziehbar. Entscheidend ist, dass die Umgebung selbst die Schutzgrenze bildet. Der Rechner sollte als entbehrlich gelten:
- In einer Wegwerf-VM oder einem Dev Container ausführen, nicht auf dem täglichen Arbeitsrechner.
- Produktiv-Credentials vorher aus der Umgebung entfernen.
- Die Aufgabe eng eingrenzen und vor dem Weiterarbeiten
git diffprüfen.
Weil --yolo sämtliche Schranken entfernt, laufen auch ein versehentliches rm -rf, git push oder DROP TABLE ohne Rückfrage durch – das ist der Preis für die Geschwindigkeit. (Ob Codex über einen benutzerdefinierten Model Provider auf einen selbst gehosteten oder Anthropic-kompatiblen Endpoint zeigt, ändert daran nichts: Der Sandbox ist egal, welches Modell hinter der API arbeitet.)
„Approve for me“ und Auto-review: Freigaben durch eine KI
Der neueste Modus und aktuelle Standard der App heißt Auto-review. Geeignete Eskalationen gehen an einen separaten Reviewer-Agenten – einen kleinen Codex auf Basis von GPT-5.4 Thinking (low) –, der mit Begründung zustimmt oder ablehnt. OpenAI bezeichnet das als „reviewer swap, not a permission grant“: Schreibbare Verzeichnisse werden nicht erweitert und das Netzwerk nicht geöffnet; nur die Instanz, die „Ja“ sagt, ändert sich.
Die Zahlen aus OpenAIs eigener Auswertung vom 30. April 2026: Auto-review benötigt menschliche Unterbrechungen ungefähr 200x seltener als manuelle Freigaben und genehmigt etwa 99.1% der Eskalationen, die es prüft (99.93% über alle Aktionen hinweg). In der beispielhaften Momentaufnahme mit 10.000 Aktionen liefen 9.280 unverändert innerhalb der Sandbox, 720 erreichten den Reviewer und nur 7 wurden abgelehnt.
Schutzmechanismen sollen eine Kette von Ablehnungen verhindern: Der Turn wird nach 3 aufeinanderfolgenden Ablehnungen oder nach 10 Ablehnungen innerhalb eines rollierenden Fensters der letzten 50 Reviews unterbrochen. Wenn Codex anhält, öffnet /approve die Auswahl Auto-review Denials, über die sich eine Aktion für einen erneuten Versuch freigeben lässt.
Der Haken: Bei langen Läufen können diese Sicherheitsprüfungen den Ablauf ausbremsen. Nutzer berichteten Ende Juli 2026 bei mehrstündigen /goal-Aufgaben, dass die regelmäßige Frage „keep waiting?“ Workflows unterbrach, die zuvor tagelang unbeaufsichtigt liefen. OpenAI sagt außerdem ausdrücklich, Auto-review solle „not be treated as a guarantee of security“: Der Recall bei Red-Team-Tests ist hoch, aber nicht perfekt (90.3% overreach, 99.3% prompt injection, 96.1% misaligned-model). Als Standard ist der Modus sinnvoll, bei kritischen Aufgaben aber kein Ersatz für eine Sandbox.
So wird die Funktion in der Konfiguration statt über die UI aktiviert:
approvals_reviewer = "auto_review"
[auto_review]
policy = """
Describe what the reviewer should allow or block here.
"""Welcher Modus passt zu welchem Einsatz?
- Alltägliche lokale Entwicklung:
workspace-write+on-request(„Ask for approval“). Damit bleibt das Vetorecht bei allem erhalten, was das Repository verlässt – dort liegt das eigentliche Schadenspotenzial. - Lange unbeaufsichtigte Läufe: „Approve for me“ (Auto-review). Der Modus hält bei auffälligen Aktionen weiterhin an; vollständig berührungslos ist er also nicht.
- Einmalige, riskante Arbeit in einer Wegwerf-Umgebung:
--yolo. Am schnellsten und am gefährlichsten – vertretbar nur, wenn die Umgebung keinen Schaden nehmen kann. - Codebase lesen oder reviewen:
read-only. Keine Schreibzugriffe, keine Überraschungen.
Die ehrliche Zusammenfassung: Es gibt keine Einstellung, die zugleich vollständig autonom und vollständig sicher ist. Jeder Schritt in Richtung Hands-off ersetzt das eigene Urteil durch das eines Klassifikators. Für Routineaufgaben kann sich das lohnen, auf Produktionsinfrastruktur ist es eine schlechte Idee. Den Modus deshalb pro Aufgabe wählen, nicht ein für alle Mal.
FAQ
Gibt es einen Auto Mode für Codex?
Ja, aber nicht als einzelnen Schalter, sondern als مجموعة von Voreinstellungen. In der App sind „Ask for approval“, „Approve for me“ und „Full access“ die Auto-Modi. In der CLI lässt sich dasselbe Verhalten mit --sandbox und --ask-for-approval zusammensetzen oder über /permissions auswählen.
Wie lässt Codex alle Befehle automatisch freigeben?
Dafür approval_policy = "never" setzen. Zusammen mit workspace-write beendet das die Rückfragen innerhalb der Sandbox; mit danger-full-access – also --yolo – entfallen Rückfragen vollständig. Letzteres entfernt alle Schutzmechanismen und gehört deshalb nur in eine isolierte Umgebung.
Was ist der Codex-Modus Auto-review?
Auto-review (approvals_reviewer = "auto_review", in der App als „Approve for me“ angezeigt) leitet Freigabeentscheidungen an einen KI-Reviewer-Agenten statt an dich weiter. Er genehmigt rund 99% der geprüften Aktionen und benötigt etwa 200x seltener einen Menschen, ist aber keine Sicherheitsgarantie.
Funktioniert --full-auto noch?
Nicht in der interaktiven CLI. Im Test mit v0.145.0 liefert codex --full-auto „unexpected argument“. codex exec --full-auto akzeptiert es für Skripte weiterhin als veralteten Alias. Für die interaktive Nutzung stattdessen --sandbox workspace-write --ask-for-approval on-request setzen.
Ist der Modus --yolo sicher?
Nein – genau darauf spielt der Name an. Er deaktiviert Sandbox und alle Freigaben gleichzeitig. Vertretbar ist er nur in einer entbehrlichen VM oder einem Container, aus dem Produktiv-Credentials entfernt wurden und in dem die Aufgabe eng begrenzt ist.