Mein erstes Problem nach der Installation war keine Freigabeabfrage. Es war npm install, das in Codex CLI nicht funktionierte.
Dateien wurden ganz normal geändert, nur die Installation der Abhängigkeiten hing. Eine ganze Weile hielt ich das für ein Problem von npm selbst.
Das Fazit vorweg: sudo ist hier nicht die Lösung.
Außerdem sind Freigabe und Sandbox zwei völlig verschiedene Achsen. Wer sie nicht trennt, landet immer wieder bei derselben Verwirrung: „Ich habe es doch erlaubt, warum klappt es nicht?“
Warum funktioniert npm install nicht in Codex CLI mit workspace-write?
Der Modus workspace-write erlaubt Schreibzugriffe auf Dateien, der Netzwerkzugriff ist aber eine eigene Einstellung. Deshalb kann ein Befehl wie npm install, der das Netzwerk braucht, blockiert werden, während Dateiänderungen durchgehen.
Anfangs dachte ich einfach, mit npm stimme etwas nicht. Die Codedateien wurden ja weiterhin problemlos geändert.
Nachdem Codex CLI installiert war, habe ich es für echte Aufgaben eingesetzt. Die Codeänderungen liefen gut.
Nur der Schritt, in dem die Abhängigkeiten installiert wurden, blieb immer wieder hängen.
Eine Zeit lang hatte ich die npm-Konfiguration im Verdacht. Die eigentliche Ursache war die Regel für den Netzwerkzugriff in der Sandbox.
Dateien schreiben dürfen und das Netzwerk nutzen dürfen: Das sehe ich seitdem als zwei völlig getrennte Berechtigungen.
Laut offizieller Dokumentation behandelt workspace-write das Schreiben ins Dateisystem und den Netzwerkzugriff als zwei verschiedene Grenzen (OpenAI-Dokumentation: Sandbox).
Den genauen Namen des Konfigurationsschlüssels konnte ich in der Dokumentation allerdings nicht bestätigen. Ich schreibe hier deshalb nur, dass der Netzwerkzugriff über eine eigene Einstellung gesteuert wird.
Hilft sudo, wenn npm install -g mit EACCES abbricht?
Nach meiner Erfahrung nicht: Mit sudo ist das Paket zwar sofort installiert, danach verheddern sich die Rechte aber noch mehr. Geholfen hat, den Node-Pfad aufzuräumen und in einer Node-Umgebung im Benutzerbereich neu zu installieren.
Das war ein anderes Problem, ganz am Anfang der Installation.
Auf demselben Rechner lagen das System-Node und eine separat installierte Node-Versionsverwaltung durcheinander. Beim globalen Installieren eines npm-Pakets kam es zu einem Berechtigungsproblem.
Mein erster Reflex war sudo npm install -g .... Da habe ich innegehalten.
Ich wusste aus Erfahrung, dass sich die Rechte nach einem erzwungenen sudo später noch weiter verheddern.
Nachdem ich den Node-Pfad aufgeräumt und im Benutzerbereich neu installiert hatte, war das Problem weg.
Mein Fazit aus diesem Hin und Her: Ein EACCES sollte nicht automatisch zu sudo führen.
Freigabe und Sandbox in Codex CLI: Was ist der Unterschied?
approval_policy legt fest, wann ein Mensch gefragt wird, und sandbox_mode, wie weit der Agent ohne Nachfrage ausführen darf. Es sind zwei unabhängige Achsen, deshalb hebt eine großzügige Freigabe die Grenzen der Sandbox nicht auf.
Diese Trennung war mir am Anfang nicht klar.
Warum ich never für „alles erlauben“ hielt
Als ich approval_policy = "never" sah, war mein erster Gedanke simpel: „Jetzt wird alles automatisch erlaubt.“
So war es nicht. Auch mit never blieben Aktionen außerhalb der Sandbox eingeschränkt.
Laut offizieller Dokumentation ist --ask-for-approval never dafür ausgelegt, mit allen --sandbox-Modi zu funktionieren.
Die Dokumentation hält auch fest, dass die Grenzen der Sandbox unabhängig von der Freigabe bestehen bleiben (OpenAI-Dokumentation: Agent approvals & security).
Stand: September 2026
Was ich hier beschreibe, habe ich im September 2026 geprüft. Optionsnamen und Konfigurationswerte von Codex CLI haben sich von Release zu Release geändert.
Optionen aus einem alten Tutorial passen deshalb womöglich nicht mehr zur aktuellen Version.
Ein Beispiel: approval_policy = "untrusted" wurde mit einem im August 2026 gemergten PR abgeschafft. Ab 0.149.0 bricht Codex beim Start mit einem Fehler ab, wenn eine Konfigurationsdatei diesen Wert noch enthält (openai/codex PR #39630).
Die offizielle Dokumentation nennt derzeit drei Werte für approval_policy: on-request, never und granular (feingranulare Steuerung). Den oft genannten Wert „unless-trusted“ konnte ich nicht bestätigen.
Bei jeder Änderung an config.toml halte ich es darum für sicherer, die CLI-Hilfe und die offizielle Konfigurationsreferenz erneut zu öffnen.
workspace-write oder danger-full-access: Wie viel Zeit kosten die Freigaben?
Bei 5 Wiederholungen desselben Refactorings brauchte workspace-write + on-request 14 bis 16 Minuten, danger-full-access in einer isolierten Umgebung 11 bis 13 Minuten. Das ist meine eigene Messung, keine allgemeine Leistungszahl.
Alles lief in einem privaten bzw. POC-Repository unter macOS auf Apple Silicon. Geändert habe ich nur zwei Bedingungen.
| Bedingung | Dauer (Durchschnitt, Bereich über 5 Läufe) | Freigaben |
|---|---|---|
| workspace-write + on-request | 14–16 Min. | 2–4 |
| danger-full-access (isolierte Umgebung) | 11–13 Min. | Keine (keine Abfrage) |
Woher kamen die 2 bis 4 Freigaben?
Mit workspace-write + on-request gab es pro Durchlauf in der Regel 2 bis 4 Freigabeabfragen. Dateiänderungen im Workspace und normale Tests liefen fast ohne Pause durch.
Die Pausen kamen meistens an ähnlichen Stellen: wenn Netzwerkzugriff nötig war oder ein Zugriff auf Dateien außerhalb des Workspace.
14–16 gegen 11–13 Minuten, und warum ich das nicht verallgemeinere
Mit danger-full-access in einer isolierten Umgebung verschwindet die Wartezeit für Freigaben fast (siehe Tabelle).
Eine allgemeine Aussage wie „danger-full-access ist 20 % schneller“ leite ich daraus nicht ab. Der echte Unterschied hing stark davon ab, wie viel Zugriff außerhalb der Sandbox die Aufgabe brauchte.
Präzise Zeitstempel habe ich auch nicht genommen. Es sind nur fünf persönliche Wiederholungen.
In welchen Umgebungen nutze ich danger-full-access?
Mein Kriterium: nur in Umgebungen, die sich komplett wegwerfen lassen, etwa Docker, eine Wegwerf-VM oder ein separater Worktree. Den vorsichtigsten Modus read-only lasse ich in diesem Vergleich weg, weil er schon das Schreiben blockiert.
Laut offizieller Dokumentation hebt danger-full-access die Grenzen für Dateisystem und Netzwerk vollständig auf (OpenAI-Dokumentation: Sandbox).
Die Option --dangerously-bypass-approvals-and-sandbox (Alias --yolo) ist in der Dokumentation nicht als „EXTREMELY DANGEROUS“ gekennzeichnet.
Ihre Kennzeichnung lautet [Elevated Risk] No sandbox; no approvals (not recommended). Dazu kommt eine Warnung, sie mit Vorsicht zu verwenden (OpenAI-Dokumentation: Agent approvals & security).
--sandbox/-s und --profile finden sich in der Dokumentation. Für --worktree und --approve-for-me habe ich bei dieser Prüfung keinen Beleg gefunden, deshalb lasse ich sie hier weg.
Privates Repository, Firmen-POC, Automatisierungsexperimente
In der Praxis unterscheide ich drei Umgebungen. Im privaten Repository nutze ich workspace-write + on-request direkt auf dem macOS-Host.
Beim Firmen-POC bleibe ich in einem Entwicklungs-Repository überwiegend bei workspace-write. Der Zugriff auf Zugangsdaten und Produktion ist komplett getrennt, in eigenen Tools und Umgebungen.
Nur risikoarme Automatisierungsexperimente bekommen weitere Berechtigungen, in Docker oder einem Wegwerf-Worktree.
Standard ist immer workspace-write.
Das Kriterium ist nicht die Geschwindigkeit. Die Frage lautet: „Ist es in Ordnung, wenn ein Fehlgriff dieses Agenten über den Workspace hinaus wirkt?“
In den meisten Fällen lautet die Antwort Nein. Auf dem Host, in meinen normalen Entwicklungs-Repositories, setze ich keine Bypass-Option als Standard, nur weil es bequem ist.
Wenige Profile, mit Absicht
Ich lege nicht zu viele Profile an. Neben einer vorsichtigen Standardkonfiguration pflege ich in der Regel nur ein zusätzliches Profil: eines für isolierte Umgebungen.
Codex CLI oder Antigravity CLI: Wo gab es weniger Freigaben?
In meinem persönlichen Vergleich brauchte Codex mit workspace-write + on-request gefühlt weniger Eingriffe als Antigravity CLI. Antigravity lag bei derselben Aufgabe im Freigabemodus bei etwa 18 und im automatischen Modus bei etwa 12 Minuten.
| Tool / Modus | Dauer | Freigaben | Blockiert |
|---|---|---|---|
| Antigravity CLI, Freigabemodus | ca. 18 Min. | 6–7 | 4 |
| Antigravity CLI, automatisch | ca. 12 Min. | – | – |
| Codex workspace-write + on-request | 14–16 Min. | 2–4 | – |
Das ist ein persönlicher Vergleich. Je nach Tool und Zeitpunkt kann es anders aussehen.
Gegenüber Antigravity hatte ich bei Codex vergleichsweise selten das Gefühl, sogar normale Befehle im Workspace einzeln freigeben zu müssen.
Für den Alltag mit einem Coding-Agenten war diese Kombination angenehmer.
Damals wie heute habe ich nach demselben Kriterium entschieden: Blast Radius (wie weit ein Fehler reicht) und Umkehrbarkeit.
Eines hat sich nicht geändert: Ohne die Trennung von Sandbox und Freigabe ist die Verwirrung bei jedem Tool dieselbe.
Welche Codex-Kombination genau dem --dangerously-skip-permissions von Claude Code entspricht, darauf gehe ich in diesem Artikel nicht näher ein.
Für mich ist die Sandbox kein Zeichen von Misstrauen gegenüber dem Agenten
Auch wenn die Modelle noch so gut werden, bleiben Fehlerpfade, die mit ihrem Schlussfolgern nichts zu tun haben. Beispiele sind ein Shell-Befehl, ein Paket-Skript, ein falscher Pfad oder ein unerwartetes Test-Cleanup.
Mein Standard ist, den Blast Radius eines Fehlers im Workspace einzuschließen, statt ein paar Freigabeklicks zu sparen.
Quellen
- OpenAI-Dokumentation: Sandbox: Trennung der Grenzen für Dateisystem und Netzwerk je Sandbox-Modus, Aufhebung dieser Grenzen durch danger-full-access
- OpenAI-Dokumentation: Agent approvals & security: Unabhängigkeit von approval_policy und sandbox_mode, Warnhinweis zur Bypass-Option und CLI-Optionen
- openai/codex PR #39630: Retire the untrusted approval policy: Abschaffung von
approval_policy = "untrusted"und Startfehler ab 0.149.0
Dieser Artikel wurde auf Basis des koreanischen Originals lokalisiert: https://jjeongil.tistory.com/3566.