OpenAI Codex CLI: der Agent, der Rechte als Konfigurationsdatei behandelt

OpenAI Codex CLI ist ein Terminal-Agent fürs Programmieren: Er liest ein Repository, ändert Dateien, führt die Kommandos des Projekts aus und iteriert, bis die Aufgabe erledigt ist. Interessant ist nicht die Agentenschleife, die mehrere Wettbewerber ebenfalls haben. Interessant ist, dass das Sicherheitsmodell als zwei Einstellungen in einer TOML-Datei ausgedrückt wird, die ein Team committen, reviewen und pinnen kann, statt als Prompt oder als Kontoregel, die der Anbieter serverseitig durchsetzt.

Das macht es zum am besten steuerbaren Coding-Agent seiner Kategorie, und zugleich zu dem, in dem Konfigurationsfehler am teuersten sind. Denn ein committetes sandbox_mode = "danger-full-access" ist eine Richtlinie, die ohne Review in Produktion geht. Alles Weitere ist eine Bewertung, wie gut dieser Kompromiss trägt.

Was es ist

Die CLI wird als versionierte npm-Pakete ausgeliefert, aktuell 0.160.1, das Repository steht unter Apache-2.0 mit einem Rust-Kern. Sie ist eine Oberfläche eines breiteren Codex-Produkts, zu dem außerdem die ChatGPT-Desktop-App, eine IDE-Erweiterung und ein Cloud-Runner gehören. Die CLI ist der Teil, der auf einem Entwicklerrechner läuft, und der einzige, der quelloffen ist.

• Apache-2.0, Rust-Kern, npm-Paket @openai/codex sowie ein eigenständiges Installationsskript.
• Die Konfiguration liegt in ~/.codex/config.toml und lässt sich pro Projekt über .codex/config.toml eingrenzen.
• Zwei getrennte Anmeldewege: ChatGPT-Abonnement oder API-Key, mit unterschiedlichen Limits und unterschiedlicher Abrechnung.
• Lokale Arbeit braucht ein Git-Repository; codex exec erzwingt dieselbe Regel und bietet --skip-git-repo-check.
• MCP-Server werden in derselben Konfigurationsdatei definiert und mit IDE-Erweiterung und Desktop-App auf demselben Host geteilt.

Wie es funktioniert

Der Turn-Ablauf ist der bekannte: Ein Prompt plus Repository-Kontext gehen ans Modell, das Modell erzeugt Tool-Calls, die CLI führt sie in einer Sandbox aus, und die Ergebnisse kommen als Tool-Output für den nächsten Turn zurück. Anders als bei einem Shell-Wrapper sind Sandbox und Freigabeprüfung zwei getrennte Tore, und beide sind konfiguriert, nicht interaktiv erfragt.

Die Schleife ist nicht das Produkt, auch wenn sie interessant klingt. Was ein Team tatsächlich konfiguriert, ist die Grenze um sie herum, und die Dokumentation betont ungewöhnlich deutlich, dass beide orthogonal zueinander stehen. Ein Lauf mit Full access bearbeitet jede Datei auf dem Rechner und führt Befehle mit Netzwerk ohne Nachfrage aus, und die Doku beschreibt das als erheblich erhöhtes Risiko von Datenverlust und Leaks, statt es zu verstecken.

Erste Schritte

Installieren, anmelden, starten. Beim ersten Start bietet die CLI Sign in with ChatGPT oder einen API-Key an, und die Wahl wirkt später, weil sie entscheidet, welche Limits gelten und in welchem Abrechnungsmodus du arbeitest.

# Install on macOS or Linux; npm and Homebrew are also supported.
curl -fsSL https://chatgpt.com/codex/install.sh | sh

# Run inside a project directory, then sign in.
codex

# Pin the version in CI instead of tracking latest.
npm install -g @openai/codex@0.160.1

# The first prompt is a good place for /init, which writes AGENTS.md.
# /status, /model, /permissions and /review are the other useful commands.

AGENTS.md ist die dauerhafte Instruktionsdatei. Die CLI liest eine globale ~/.codex/AGENTS.md und geht danach vom Projektwurzelverzeichnis bis zum aktuellen Verzeichnis, eine Datei pro Ebene, wobei AGENTS.override.md über AGENTS.md gewinnt. Die Gesamtlänge ist über project_doc_max_bytes begrenzt, standardmäßig 32 KiB. Für ein Team ist diese Datei das Wertvollste, was man schreiben kann, weil sie der Teil des Agentenverhaltens ist, der durch ein Code-Review geht.

Sandbox und Freigaben

Dieser Teil lohnt zweimaliges Lesen. Die Sandbox ist die Grenze, die Freigaberichtlinie ist die Pause. Der Standard, Ask for approval, ist sandbox_mode = "workspace-write" mit approval_policy = "on-request" und menschlichem Prüfer. Die Doku weist darauf hin, dass der Wechsel des Prüfers auf auto_review die Sandbox nicht erweitert. Das ist das richtige Design und zugleich der Detailpunkt, den die meisten Werkzeuge falsch machen.

# ~/.codex/config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"

# Boundary: read-only | workspace-write | danger-full-access
sandbox_mode = "read-only"

# Pausing: on-request | never | granular table
approval_policy = "on-request"

# Reviewer: user | auto_review
approvals_reviewer = "user"

# Extra roots and network, only used when sandbox_mode = workspace-write
[sandbox_workspace_write]
writable_roots = ["~/code"]
network_access = false

Die Konfigurationsdatei geht deutlich tiefer. Es gibt einen Netzwerk-Proxy mit Allow- und Deny-Regeln pro Domain, eine Shell-Umgebungsrichtlinie, die Variablen mit Namen wie Keys oder Tokens filtert, schreibbare Wurzeln und Hooks, die vor einem Tool-Aufruf laufen. Das ist viel Oberfläche, und der Versuchung, alles zu konfigurieren, sollte man widerstehen. Jeder Regler ist eine Entscheidung, die jemand für andere treffen muss.

Automatisierung und codex exec

Der nicht-interaktive Modus ist der Grund, diese CLI einer chatgetriebenen Agentenlösung vorzuziehen. codex exec läuft standardmäßig in einer read-only Sandbox, schreibt den Fortschritt nach stderr, druckt nur die letzte Nachricht nach stdout und startet außerhalb eines Git-Repositories nicht. Diese letzte Regel ist eine Bremse gegen einen Agenten, der ein Verzeichnis umschreibt, für das er keinen Diff zeigen kann.

# Progress on stderr, final message on stdout: safe to pipe.
codex exec "summarise the repository structure" | tee summary.md

# Machine-readable: one JSON object per event.
codex exec --json "triage the open bug reports" | jq

# Escalate the sandbox explicitly, never implicitly.
codex exec --sandbox workspace-write "add a regression test and run it"

# Structured final answer against a schema, written to a file.
codex exec "extract project metadata" \
  --output-schema ./schema.json -o ./metadata.json

Zwei Details machen das produktionsreif. Mit --json trägt der Ereignisstrom die Nutzung einschließlich gecachter Eingabetokens, eine Pipeline kann Kosten also pro Lauf statt pro Monat zuordnen. Und ein MCP-Server mit required = true lässt den Start scheitern, statt still weiterzulaufen. Das ist der Unterschied zwischen einem kaputten CI-Lauf und einem unauffällig falschen.

MCP und Projektkontext

MCP-Server stehen in derselben Konfigurationsdatei und werden zwischen CLI, IDE-Erweiterung und Desktop-App auf demselben Host geteilt. Unterstützt sind stdio und Streamable HTTP, OAuth inklusive Dynamic Client Registration.

[mcp_servers.docs]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env_vars = ["CONTEXT7_TOKEN"]
required = true          # fail startup instead of running without it
enabled_tools = ["search", "summarize"]
default_tools_approval_mode = "prompt"
tool_timeout_sec = 45

MCP kostet Kontext, und die Preisdokumentation sagt das deutlich: Jeder Server vergrößert die Nachricht und verbraucht mehr vom Kontingent. Ein vernünftiges Team lässt zwei oder drei aktiv, deaktiviert den Rest und behandelt die Serverliste als Teil des Budgets pro Turn statt als Bequemkeitsliste.

Kosten und Limits

Zwei Abrechnungssysteme teilen sich dieselbe Binärdatei, und sie sind nicht vergleichbar. Ein ChatGPT-Abo zählt Nachrichten in Fünf-Stunden-Fenstern, und die veröffentlichten Zahlen sind Schätzungen, keine Obergrenzen: rund 15 bis 160 lokale Nachrichten je fünf Stunden im Plus-Tarif für die mittleren Modelle, gegenüber 350 bis 3.000 beim günstigsten. Ein API-Key zählt Tokens zu veröffentlichten Raten, und das macht ihn zum richtigen Credential für Automatisierung.

Der praktische Rat ist kurz. Nimm das Abo für interaktive Arbeit, bei der ein Mensch da ist und bemerkt, wenn das Kontingent knapp wird, und den API-Key für alles Unbemannte, weil nur dort eine vorhersagbare Position pro Lauf entsteht. Der Befehl /status zeigt die verbleibende Kapazität in der Sitzung, und die Doku stellt klar, dass allein die Promptlänge kein verlässlicher Prädiktor für den Verbrauch einer Aufgabe ist.

Wo es zu kurz kommt

Drei Probleme, sortiert nach ihrer Tragweite. Erstens ist die Konfigurationsoberfläche riesig für ein Werkzeug, dessen Kernschleife unspektakulär ist, und es gibt keine Möglichkeit, es mit absichtlich kleiner Konfiguration zu betreiben, die man in einem Durchgang prüfen kann. Zweitens ändert sich das Produkt um die CLI schnell: Modelle werden zu festen Terminen abgekündigt, mehrere wurden innerhalb eines Jahres stillgelegt, und ein committeter Modellname in einer Config oder einem CI-Skript wird zur Last. Drittens meldet der Review-Befehl Funde, ohne den Arbeitsbaum zu ändern. Das ist das richtige Verhalten und deutlich weniger nützlich als die Varianten, die ihre Funde gleich beheben.

Der Vergleich ist so knapp, dass der entscheidende Faktor selten der Agent selbst ist. Es ist, wie eure Berechtigungsgeschichte bereits aussieht. Wenn im Team bereits eine committete Agent-Konfiguration im Review liegt, passt Codex. Wenn nicht, ist die Stärke der CLI eine Last, bis jemand diese Datei schreibt.

Urteil

Codex CLI ist die stärkste Wahl für Teams, die einen Coding-Agenten wollen, dessen Verhalten ein reviewbares Artefakt ist. Die Trennung von Sandbox und Freigabe ist gut durchdacht, der read-only-Standard für die Automatisierung ist der richtige Standard, und Apache-2.0 heißt, dass die Konfiguration vendored und gepinnt werden kann. Für eine einzelne Person, die einen Agenten ausprobieren will, bevor sie eine Richtlinie schreibt, ist es die schwächere Wahl.

1. Nimm es, wenn die Rechte des Agenten in einer Datei liegen sollen, die durch ein Code-Review geht, und pinne in CI die npm-Version.
2. Nutze für alles Unbemannte einen API-Key. Eine Abrechnung über Abo-Credits verträgt sich nicht mit einem geplanten Job.
3. Schreibe AGENTS.md, bevor du irgendetwas anderes einstellst. Es verändert das Verhalten stärker als jede Flag in der config.toml.
4. Lass sandbox_mode für die Automatisierung auf workspace-write und reserviere danger-full-access für einen Container, den du kontrollierst.
5. Lass es weg, wenn du über ein Jahr eine stabile Modellkennung brauchst. Die Abkündigungstakte ist schneller, als die meisten Teams verkraften.

Quellen

1. Codex CLI documentation
2. Codex: configuration
3. Codex: sample configuration
4. Codex: permissions
5. Codex: non-interactive mode
6. Codex: authentication
7. Codex: Model Context Protocol
8. Codex: pricing
9. Codex: open-source components
10. Codex changelog