OpenAI Codex CLI einrichten: 12 Schritte, 35 Min [2026]

Wer im Terminal bleiben will, statt zwischen Editor-Fenstern zu wechseln, testet gerade reihenweise die OpenAI Codex CLI. Das quelloffene Kommandozeilen-Tool liest Code, schlägt Änderungen vor, führt Befehle aus und lässt sich dabei genau so eng an die Kette legen, wie Sie das wollen. Für Entwicklerinnen und Entwickler in Österreich, die produktiv mit KI-Agenten wie GitHub Copilot oder Claude Code arbeiten, ist Codex CLI mittlerweile eine ernstzunehmende dritte Option. Diese Anleitung zeigt in zwölf Schritten, wie Sie die Codex CLI unter macOS, Linux oder Windows installieren, absichern und in einem echten Projekt einsetzen. Sie brauchen dafür kein Vorwissen zu Rust oder zur OpenAI-API, nur ein Terminal und rund 35 Minuten Zeit.

Der Artikel deckt neben der reinen Installation auch die Punkte ab, die in der Praxis am meisten Zeit kosten: Sandbox-Konfiguration, Netzwerkfreigaben, ein vollständiges Beispielprojekt, häufige Stolperfallen und eine ehrliche Einordnung gegenüber Claude Code und GitHub Copilot CLI. Wenn Sie eher an einer schnellen Referenz interessiert sind, springen Sie direkt zu den Schritten 6 bis 9, dort geht es um Konfiguration, Sicherheit und Automatisierung.

Was ist die OpenAI Codex CLI?

Die Codex CLI ist ein lokaler Coding-Agent, der laut offiziellem GitHub-Repository von OpenAI direkt in Ihrem Terminal läuft. Sie kann Dateien lesen, Änderungen vorschlagen und mit Ihrer Zustimmung auch Befehle im aktuellen Arbeitsverzeichnis ausführen. Anders als ein reiner Autocomplete-Assistent arbeitet sie als Agent: Sie beschreiben eine Aufgabe in normaler Sprache, Codex plant die nötigen Schritte, zeigt Diffs zur Prüfung an und wartet je nach Einstellung auf Ihre Freigabe, bevor sie etwas verändert.

Technisch ist die CLI in Rust gebaut, was laut den offiziellen Entwicklerdokumenten für kurze Startzeiten und geringen Ressourcenverbrauch sorgt. Der Code ist quelloffen und wird aktiv weiterentwickelt: Laut einer Analyse von AugmentCode zählte das Repository mit Stand April 2026 über 75.000 GitHub-Sterne und mehr als 10.700 Forks, bei 709 veröffentlichten Releases. Ein bemerkenswerter Meilenstein war Version 0.116 im März 2026, die laut demselben Bericht zusätzliche Enterprise-Funktionen brachte.

Codex CLI ist Teil einer größeren Plattform. Dieselbe Technologie steckt auch in der IDE-Erweiterung für VS Code, Cursor und Windsurf, im Desktop-Client (Befehl codex app) und im Cloud-Agenten Codex Web unter chatgpt.com/codex. Diese Anleitung konzentriert sich bewusst auf die eigenständige Terminal-Version, weil sie sich am direktesten in bestehende Skripte, CI-Pipelines und Git-Workflows einbauen lässt. Wenn Sie bereits GitHub Copilot oder Claude Code nutzen, lohnt sich der Vergleich weiter unten im Artikel, bevor Sie sich für ein drittes Tool entscheiden.

In der Praxis zeigt sich der Agent-Charakter vor allem daran, wie Codex mit größeren Aufgaben umgeht. Statt eine einzelne Codezeile zu vervollständigen, liest der Agent zuerst mehrere Dateien, leitet daraus einen Plan ab und arbeitet diesen Plan Schritt für Schritt ab, inklusive Testläufen und Git-Diffs. Wer bereits lokale Modelle mit Ollama betreibt, wird den Unterschied sofort merken: Codex CLI läuft nicht lokal als Modell, sondern schickt Anfragen an OpenAI-Server, arbeitet aber lokal auf Ihrem Dateisystem. Das kombiniert die Rechenleistung großer Cloud-Modelle mit direktem Zugriff auf Ihr Repository, ohne dass Sie Code manuell hin- und herkopieren müssen.

Voraussetzungen: Diese Systemvoraussetzungen brauchen Sie

Bevor Sie loslegen, prüfen Sie kurz, ob Ihr System die Grundanforderungen erfüllt. Die Installation selbst dauert nur wenige Minuten, aber falsche Voraussetzungen kosten später Zeit bei der Fehlersuche.

Anforderung	Details
Betriebssystem	macOS (Apple Silicon oder Intel), Linux (x86_64 oder arm64), Windows über PowerShell
Terminal / Shell	bash, zsh oder PowerShell, abhängig vom Betriebssystem
Node.js	Nur nötig, wenn Sie über npm installieren, da das npm-Paket @openai/codex heißt
Homebrew	Optional, für die Installation per brew install --cask codex unter macOS
Git	Empfohlen, damit Codex Ihr Repository erkennt und Checkpoints setzen kann
Konto	ChatGPT Plus, Pro, Business, Edu oder Enterprise, alternativ ein OpenAI-API-Key
Freier Speicherplatz	Wenige hundert MB für die Binärdatei und lokale Sitzungsdaten

Ein Hinweis zur Node.js-Frage, die häufig für Verwirrung sorgt: Die Codex CLI selbst ist keine Node.js-Anwendung, sondern eine kompilierte Rust-Binärdatei. Node.js wird nur gebraucht, wenn Sie den npm-Installationsweg wählen, weil npm das Paket lediglich als Verteilkanal nutzt. Wer den direkten Installer oder Homebrew verwendet, kommt komplett ohne Node.js aus.

Zeitlich lässt sich die gesamte Anleitung in drei Blöcke teilen: Installation und Anmeldung (Schritte 1 bis 5) dauern zusammen selten länger als zehn Minuten. Konfiguration von Sandbox, Netzwerk und Automatisierung (Schritte 6 bis 10) beansprucht je nach Vorwissen weitere zehn bis fünfzehn Minuten. Das abschließende Beispielprojekt in Schritt 12 dauert erfahrungsgemäß zehn bis zwanzig Minuten, abhängig davon, wie oft Codex bei Testfehlern nachbessern muss.

Schritt 1: Codex CLI unter macOS und Linux installieren

Der schnellste Weg auf macOS und Linux ist der offizielle Standalone-Installer. Öffnen Sie ein Terminal und führen Sie folgenden Befehl aus:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Laut der offiziellen Dokumentation lädt dieser Installer standardmäßig von releases.openai.com/codex und weicht bei Problemen automatisch auf GitHub Releases aus. Wenn Sie aus Compliance-Gründen ausschließlich GitHub als Quelle nutzen möchten, erzwingen Sie das über eine Umgebungsvariable:

curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_INSTALLER_USE_RELEASES_OPENAI_COM=false sh

Derselbe Befehl dient später auch zum Aktualisieren. Es gibt keinen separaten Update-Befehl, Sie führen einfach die Installationszeile erneut aus, und der Installer ersetzt die vorhandene Version. Prüfen Sie nach der Installation, ob der Befehl im PATH gefunden wird:

codex --version

Erscheint eine Versionsnummer, war die Installation erfolgreich. Falls stattdessen “command not found” erscheint, springen Sie zum Abschnitt Fehlerbehebung weiter unten.

Schritt 2: Codex CLI unter Windows installieren

Unter Windows nutzen Sie PowerShell statt curl. Öffnen Sie PowerShell (nicht zwingend als Administrator) und führen Sie den offiziellen Installationsbefehl aus:

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

Der Parameter -ExecutionPolicy ByPass gilt nur für diesen einen Befehl und ändert keine dauerhaften Systemeinstellungen. Auch hier gilt: Zum Aktualisieren führen Sie exakt denselben Befehl erneut aus. Möchten Sie ausschließlich von GitHub statt von den OpenAI-Servern laden, setzen Sie vorher die passende Umgebungsvariable:

$env:CODEX_INSTALLER_USE_RELEASES_OPENAI_COM='false'; irm https://chatgpt.com/codex/install.ps1 | iex

Nach der Installation starten Sie ein neues PowerShell-Fenster, damit die PATH-Änderung greift, und testen mit codex --version. Windows-Nutzerinnen und -Nutzer, die lieber in einer Linux-Umgebung arbeiten, können die CLI auch unter WSL genau wie unter nativem Linux installieren.

Schritt 3: Alternative Installation über npm oder Homebrew

Wenn Sie Codex CLI lieber über einen Paketmanager verwalten, den Sie ohnehin schon im Einsatz haben, stehen zwei offizielle Alternativen bereit. Über npm installieren Sie global:

# Installation über npm
npm install -g @openai/codex

# Aktualisierung über npm
npm install -g @openai/codex

Auf macOS bietet sich alternativ Homebrew an:

# Installation über Homebrew
brew install --cask codex

# Aktualisierung über Homebrew
brew upgrade --cask codex

Wer keinen Paketmanager verwenden will oder in einer abgeschotteten Umgebung ohne Internetzugriff zur Laufzeit arbeitet, kann die Binärdatei auch manuell von der GitHub-Releases-Seite herunterladen. Für macOS mit Apple Silicon brauchen Sie das Archiv codex-aarch64-apple-darwin.tar.gz, für ältere Intel-Macs codex-x86_64-apple-darwin.tar.gz. Unter Linux entsprechen codex-x86_64-unknown-linux-musl.tar.gz und codex-aarch64-unknown-linux-musl.tar.gz den gängigen Architekturen. Nach dem Entpacken benennen Sie die Datei in codex um und verschieben sie in ein Verzeichnis, das in Ihrem PATH liegt.

Schritt 4: Anmeldung – ChatGPT-Konto oder API-Key wählen

Starten Sie Codex zum ersten Mal einfach mit:

codex

Beim ersten Start fragt die CLI nach der Anmeldemethode. OpenAI empfiehlt in der offiziellen Dokumentation die Anmeldung mit Ihrem ChatGPT-Konto, wenn Sie bereits einen Plus-, Pro-, Business-, Edu- oder Enterprise-Plan besitzen, weil die Nutzung dann in Ihrem bestehenden Abonnement enthalten ist. Wählen Sie im interaktiven Dialog “Sign in with ChatGPT”, öffnet sich ein Browserfenster zur Authentifizierung.

Alternativ funktioniert Codex CLI auch mit einem klassischen API-Key, was laut Dokumentation zusätzliche Einrichtung erfordert und nach Token-Verbrauch über die OpenAI-API abgerechnet wird statt über das ChatGPT-Abo. Für Automatisierung und CI-Pipelines ist die Umgebungsvariable CODEX_API_KEY vorgesehen, dazu mehr in Schritt 9. Wichtig für Teams: Setzen Sie den API-Key niemals als Job-weite Umgebungsvariable in einer Pipeline, die auch Fremdcode aus dem Repository ausführt, denn Build-Skripte oder kompromittierte Actions könnten den Wert mitlesen. Dieser Punkt taucht auch bei den häufigen Fehlern weiter unten wieder auf.

Schritt 5: Die erste Aufgabe mit Codex starten

Wechseln Sie in ein Projektverzeichnis, idealerweise ein Git-Repository, und starten Sie Codex erneut. Ein einfacher erster Test zeigt, ob alles korrekt läuft:

cd ~/projekte/mein-projekt
codex

Geben Sie im interaktiven Prompt einfach ein:

Tell me about this project

Codex durchsucht daraufhin das Verzeichnis, liest relevante Dateien und fasst zusammen, worum es im Projekt geht. Die offizielle Anleitung empfiehlt, vor und nach größeren Aufgaben einen Git-Checkpoint zu setzen (also einfach zu committen), damit Sie Änderungen bei Bedarf rückgängig machen können. Das ist besonders am Anfang sinnvoll, wenn Sie noch ein Gefühl dafür entwickeln, wie aggressiv Codex im gewählten Freigabemodus vorgeht.

Ein zweiter guter Testprompt, der sich in der Praxis bewährt hat, bittet Codex, einen konkreten, kleinen Fehler zu beheben oder eine einzelne Funktion zu dokumentieren. So sehen Sie schnell, wie der Agent mit echtem, gewachsenem Code umgeht, statt nur mit einer Zusammenfassung zu antworten. Bricht Codex eine Aufgabe vorzeitig ab oder liefert eine unvollständige Antwort, hilft meist eine präzisere Formulierung mit klar benannter Datei oder Funktion mehr als ein längerer, allgemeiner Prompt.

Schritt 6: Die Konfigurationsdatei config.toml einrichten

Dauerhafte Einstellungen wie das bevorzugte Modell oder das Reasoning-Niveau legen Sie in einer TOML-Datei fest. Sie liegt standardmäßig unter ~/.codex/config.toml. Legen Sie die Datei an, falls sie noch nicht existiert:

# ~/.codex/config.toml

# Bevorzugtes Modell
model = "gpt-5.4"
model_provider = "openai"

# Reasoning-Aufwand
model_reasoning_effort = "medium"    # minimal | low | medium | high | xhigh

# Zusammenfassung und Ausführlichkeit der Antworten
model_reasoning_summary = "auto"     # auto | concise | detailed | none
model_verbosity = "medium"           # low | medium | high

Der Modellname gpt-5.4 stammt als Beispielwert aus der Konfigurationsdokumentation und dient hier nur zur Veranschaulichung des Aufbaus. Das tatsächlich verfügbare Modell-Sortiment ändert sich regelmäßig, prüfen Sie daher vor der produktiven Nutzung die aktuelle Modellliste in der offiziellen Codex-Dokumentation. Für einen einzelnen Lauf lässt sich das Modell auch ohne Änderung der Konfigurationsdatei überschreiben:

# Direkter Modell-Flag
codex --model gpt-5.4

# Generischer Key-Value-Override (Wert muss gültiges TOML sein)
codex --config model='"gpt-5.4"'

Dedizierte Flags wie --model haben laut Dokumentation Vorrang vor generischen --config-Overrides, wenn beide für denselben Schlüssel gesetzt werden. Für die meisten Alltagsfälle reicht der dedizierte Flag völlig aus. Beachten Sie außerdem die Rangfolge der Konfigurationsebenen: Flags, die Sie direkt beim Aufruf übergeben, überschreiben für diesen einen Lauf immer die Werte aus ~/.codex/config.toml, während die Datei selbst die dauerhafte Grundeinstellung für alle künftigen Sitzungen liefert. Das ist besonders praktisch, wenn ein Teammitglied testweise ein anderes Modell ausprobieren will, ohne die gemeinsam genutzte Konfigurationsdatei im Repository zu verändern.

Schritt 7: Sandbox-Modus und Freigabe-Richtlinie verstehen

Bevor Codex irgendetwas automatisch verändert, sollten Sie verstehen, wie die zwei Sicherheitsebenen zusammenspielen: der Sandbox-Modus bestimmt, was Codex technisch darf, die Freigabe-Richtlinie bestimmt, wann Codex vorher nachfragen muss. Laut den offiziellen Sicherheitsdokumenten läuft der Agent standardmäßig ohne Netzwerkzugriff und mit Schreibrechten, die auf das aktuelle Arbeitsverzeichnis begrenzt sind.

Sandbox-Modus	Was Codex darf	Typischer Einsatz
read-only	Nur lesen, keine Dateien ändern, keine Befehle mit Nebenwirkungen ausführen	Planen, Chatten, Code verstehen ohne Änderungsrisiko
workspace-write	Lesen und Schreiben im aktuellen Arbeitsverzeichnis, Netzwerk standardmäßig aus	Alltägliches Coden mit Kontrolle über den Scope
danger-full-access	Volle Lese-, Schreib- und Ausführungsrechte ohne Einschränkung	Nur in isolierten CI-Runnern oder Containern

Für den interaktiven Alltag empfiehlt die offizielle Dokumentation das sogenannte Auto-Preset, das Lesen, Bearbeiten und Ausführen im Arbeitsverzeichnis automatisch erlaubt, aber bei Aktionen außerhalb dieses Bereichs nachfragt:

codex --sandbox workspace-write --ask-for-approval on-request

Möchten Sie nur planen und chatten, ohne dass Codex etwas verändert, wechseln Sie im laufenden Interface jederzeit mit dem Befehl /permissions in den read-only-Modus. Das ist besonders praktisch, wenn Sie erst eine Architekturfrage klären wollen, bevor Sie den Agenten an den Code lassen.

Schritt 8: Netzwerkzugriff kontrolliert aktivieren

Manche Aufgaben, etwa das Installieren von Abhängigkeiten oder das Abrufen einer API-Dokumentation, brauchen Netzwerkzugriff. Standardmäßig bleibt dieser im workspace-write-Modus deaktiviert. Sie aktivieren ihn gezielt in der Konfigurationsdatei:

[sandbox_workspace_write]
network_access = true

Wer den Zugriff nicht pauschal öffnen, sondern auf bestimmte Domains einschränken möchte, aktiviert zusätzlich das Feature network_proxy und definiert eine Allow- und Deny-Liste:

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

Wichtig laut Dokumentation: Das Feature network_proxy allein schaltet keinen Zugriff frei, es erzwingt nur die konfigurierte Richtlinie, sobald Netzwerkzugriff über network_access bereits aktiv ist. Zusätzlich blockiert Codex standardmäßig Verbindungen zu lokalen und privaten Adressen (allow_local_binding = false), auch das lässt sich bei Bedarf gezielt aufweichen. Für einen einmaligen Testlauf, ohne die Konfigurationsdatei dauerhaft zu ändern, funktionieren dieselben Einstellungen auch als Flags:

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

Schritt 9: Nicht-interaktiven Modus mit codex exec für Skripte und CI nutzen

Für CI-Pipelines, geplante Jobs oder einfach schnelle Einzeiler ohne das interaktive Terminal-Interface gibt es den Unterbefehl codex exec (Kurzform codex e), ausführlich beschrieben in der offiziellen Befehlsreferenz. Er nimmt eine Aufgabe als Argument entgegen und läuft ohne Rückfragen durch:

codex exec "summarize the repository structure and list the top 5 risky areas"

Während codex exec läuft, schreibt Codex den Fortschritt nach stderr und gibt nur die endgültige Antwort auf stdout aus. Dadurch lässt sich das Ergebnis sauber weiterverarbeiten:

codex exec "generate release notes for the last 10 commits" | tee release-notes.md

Standardmäßig läuft codex exec laut offizieller Dokumentation zum nicht-interaktiven Modus im read-only-Sandbox. Für Automatisierung, die tatsächlich Dateien ändern soll, erlauben Sie das explizit:

codex exec --sandbox workspace-write "aktualisiere die README mit den neuesten API-Endpunkten"

Ein Detail, das in älteren Anleitungen noch auftaucht: Der Flag --full-auto gilt inzwischen als veraltet und funktioniert nur noch als Kompatibilitätsoption mit Warnhinweis. Verwenden Sie in neuen Skripten stattdessen explizit --sandbox workspace-write. Für Sitzungen, deren Verlaufsdaten Sie nicht dauerhaft speichern wollen, etwa in einem Wegwerf-Container, hängen Sie --ephemeral an.

Schritt 10: JSON-Ausgabe und strukturierte Antworten erzeugen

Wenn ein anderes Tool die Codex-Ausgabe automatisch weiterverarbeiten soll, reicht Freitext nicht. Mit dem Flag --json liefert codex exec stattdessen einen JSON-Lines-Stream mit jedem einzelnen Ereignis:

codex exec --json "summarize the repo structure" | jq

Eine Beispielzeile aus diesem Stream sieht laut Dokumentation so aus:

{"type":"thread.started","thread_id":"0199a213-81c0-7800-8aa1-bbab2a035a53"}
{"type":"turn.started"}
{"type":"item.completed","item":{"id":"item_3","type":"agent_message","text":"Repo contains docs, sdk, and examples directories."}}
{"type":"turn.completed","usage":{"input_tokens":24763,"cached_input_tokens":24448,"output_tokens":122}}

Brauchen Sie stattdessen ein festes Datenschema, etwa für einen automatisierten Release-Report, nutzen Sie --output-schema mit einer eigenen JSON-Schema-Datei:

{
  "type": "object",
  "properties": {
    "project_name": { "type": "string" },
    "programming_languages": {
      "type": "array",
      "items": { "type": "string" }
    }
  },
  "required": ["project_name", "programming_languages"],
  "additionalProperties": false
}

codex exec "Extract project metadata" \
  --output-schema ./schema.json \
  -o ./project-metadata.json

Die Ausgabe entspricht danach exakt Ihrem Schema, zum Beispiel {"project_name": "Codex CLI", "programming_languages": ["Rust", "TypeScript", "Shell"]}. Das eignet sich gut für Reporting-Skripte, die feste Felder erwarten, statt Freitext zu parsen.

Schritt 11: AGENTS.md für dauerhaften Projektkontext anlegen

Damit Codex nicht bei jeder Sitzung erneut fragt, wie Ihr Projekt strukturiert ist, welche Tests laufen oder welche Konventionen gelten, legen Sie eine AGENTS.md-Datei im Projekt-Root an. Die Datei wird laut offizieller Dokumentation automatisch als dauerhafter Kontext eingelesen:

# AGENTS.md

## Projektüberblick
Node.js REST-API mit Express, TypeScript und Jest.

## Befehle
- Tests ausführen: npm test
- Linting: npm run lint
- Lokalen Server starten: npm run dev

## Konventionen
- Verwende async/await statt Promise-Ketten
- Neue Endpunkte immer mit Jest-Tests absichern
- Commit-Messages auf Deutsch im Imperativ

## Nicht anfassen
- Ordner /legacy ist eingefroren und wird nicht mehr gepflegt

Je präziser diese Datei ist, desto weniger Rückfragen stellt Codex und desto seltener schlägt der Agent Änderungen vor, die gegen Ihre Projektkonventionen verstoßen. Bei größeren Monorepos lassen sich zusätzlich verschachtelte AGENTS.md-Dateien in Unterordnern anlegen, die dann nur für den jeweiligen Teilbereich gelten.

Schritt 12: Komplettes Beispielprojekt – Codex CLI baut eine kleine REST-API

Zum Abschluss verbinden wir alle bisherigen Schritte in einem durchgängigen Beispiel: eine kleine Node.js-REST-API mit einem Health-Endpunkt und einer einfachen Todo-Verwaltung, komplett von Codex CLI erstellt und getestet.

Legen Sie zuerst ein leeres Projekt mit Git-Repository an:

mkdir codex-todo-api && cd codex-todo-api
git init
npm init -y
codex

Geben Sie im interaktiven Codex-Prompt eine klare, abgegrenzte Aufgabe ein:

Erstelle eine Express-API mit TypeScript. Sie soll einen GET /health Endpunkt
haben, der {"status":"ok"} zurückgibt, sowie GET/POST/DELETE /todos für eine
In-Memory-Todo-Liste. Schreibe dazu Jest-Tests für alle Endpunkte und eine
kurze README mit Startanleitung.

Codex plant daraufhin die nötigen Dateien, schlägt die Installation von Express, TypeScript und Jest als Abhängigkeiten vor und zeigt vor jeder Änderung einen Diff. Im Auto-Preset aus Schritt 7 bearbeitet der Agent Dateien innerhalb des Arbeitsverzeichnisses automatisch, fragt aber nach, sobald er Pakete installieren oder Befehle mit Netzwerkzugriff ausführen will, es sei denn, Sie haben das in Schritt 8 bereits erlaubt. Am Ende sieht die Projektstruktur typischerweise so aus:

codex-todo-api/
├── AGENTS.md
├── package.json
├── tsconfig.json
├── src/
│   ├── app.ts
│   ├── routes/
│   │   ├── health.ts
│   │   └── todos.ts
│   └── server.ts
├── tests/
│   ├── health.test.ts
│   └── todos.test.ts
└── README.md

Ein Blick in die generierte Datei src/routes/todos.ts zeigt, wie Codex typischerweise mit In-Memory-State und Fehlerbehandlung umgeht:

import { Router, Request, Response } from "express";

interface Todo {
  id: string;
  title: string;
  done: boolean;
}

const router = Router();
const todos: Todo[] = [];

router.get("/", (_req: Request, res: Response) => {
  res.json(todos);
});

router.post("/", (req: Request, res: Response) => {
  const { title } = req.body;
  if (!title) {
    return res.status(400).json({ error: "title is required" });
  }
  const todo: Todo = { id: crypto.randomUUID(), title, done: false };
  todos.push(todo);
  res.status(201).json(todo);
});

router.delete("/:id", (req: Request, res: Response) => {
  const index = todos.findIndex((t) => t.id === req.params.id);
  if (index === -1) {
    return res.status(404).json({ error: "todo not found" });
  }
  todos.splice(index, 1);
  res.status(204).send();
});

export default router;

Der Codestil orientiert sich an den Vorgaben aus Ihrer AGENTS.md, in diesem Fall an der Regel, konsequent async/await-taugliche, typisierte Handler zu schreiben und jeden Endpunkt mit einem passenden HTTP-Statuscode abzuschließen. Lassen Sie Codex anschließend die Tests direkt ausführen und das Ergebnis melden:

codex exec --sandbox workspace-write "führe npm test aus und behebe fehlschlagende Tests"

Schlagen einzelne Tests fehl, etwa weil ein Statuscode nicht passt, korrigiert Codex im selben Durchlauf den Code und wiederholt den Testlauf, bis alles grün ist oder ein manuelles Eingreifen nötig wird. Committen Sie danach wie gewohnt mit Git, prüfen Sie den Diff aber genau wie bei jedem anderen Pull Request auch. Codex ersetzt keine Code-Review, es beschleunigt nur den Weg dorthin.

Häufige Fehler beim Einstieg

Die meisten Probleme mit Codex CLI entstehen nicht durch Bugs im Tool selbst, sondern durch Fehleinschätzungen bei Sandbox, Freigaben oder Prompt-Größe. Die folgende Liste sammelt die Fehler, die in Foren, GitHub Issues und Community-Berichten am häufigsten auftauchen.

• API-Key als Job-weite Umgebungsvariable in CI setzen: Andere Skripte im selben Job können den Schlüssel mitlesen. Setzen Sie CODEX_API_KEY nur für den konkreten Codex-Aufruf und nutzen Sie für GitHub Actions besser die offizielle Codex GitHub Action.
• Den veralteten Flag –full-auto weiterverwenden: Er funktioniert zwar noch, gilt aber als Kompatibilitätsoption mit Warnhinweis. Nutzen Sie stattdessen explizit --sandbox workspace-write.
• Codex außerhalb eines Git-Repositories starten: Ohne Git-Kontext fehlt Codex die Möglichkeit, Checkpoints zu setzen und Änderungen sauber nachzuvollziehen. Arbeiten Sie grundsätzlich in einem initialisierten Repository.
• network_access pauschal aktivieren, ohne network_proxy zu konfigurieren: Dann hat jeder von Codex ausgeführte Befehl uneingeschränkten Zugriff auf beliebige Ziele im Internet. Schränken Sie den Zugriff mit einer Domain-Allowlist ein.
• Keine AGENTS.md pflegen: Ohne Projektkontext stellt Codex bei jeder Sitzung dieselben Grundfragen erneut und trifft öfter Annahmen, die nicht zu Ihren Konventionen passen.
• Nach der Installation nie aktualisieren: Da Update- und Installationsbefehl identisch sind, vergessen viele Teams, die CLI regelmäßig zu aktualisieren, und verpassen dadurch Sicherheitskorrekturen und neue Modelle.
• Zu große, unklare Aufgaben in einem einzigen Prompt bündeln: Wer Codex bittet, “die gesamte Codebasis zu modernisieren”, bekommt selten ein brauchbares Ergebnis. Zerlegen Sie große Vorhaben in klar abgegrenzte Teilaufgaben, ähnlich wie Sie es bei der Aufteilung eines Pull Requests tun würden.

Fehlerbehebung: Die häufigsten Probleme lösen

Auch bei sauberer Installation tauchen im Alltag immer wieder dieselben Fehlermeldungen auf. Die folgende Liste orientiert sich an den Kategorien, die das eingebaute Diagnosewerkzeug codex doctor selbst prüft: Installation, Konfiguration, Authentifizierung, Laufzeitumgebung, Git und Terminal.

• “codex: command not found” nach der Installation: Öffnen Sie ein neues Terminal-Fenster, damit die PATH-Änderung greift, oder prüfen Sie mit echo $PATH, ob das Installationsverzeichnis enthalten ist.
• Das Anmeldefenster öffnet sich nicht: Prüfen Sie, ob Ihr Standardbrowser korrekt konfiguriert ist, oder starten Sie codex erneut und wählen Sie die alternative API-Key-Anmeldung.
• Codex fragt bei jedem Schritt nach Freigabe: Sie befinden sich vermutlich im read-only- oder im strikten Freigabemodus. Wechseln Sie mit /permissions zum Auto-Preset oder starten Sie mit --sandbox workspace-write --ask-for-approval on-request.
• Netzwerkzugriff wird trotz Konfiguration verweigert: Denken Sie daran, dass network_proxy allein nichts freischaltet. Sie brauchen zusätzlich sandbox_workspace_write.network_access = true.
• Ein MCP-Server startet nicht und codex exec bricht ab: Ist der Server mit required = true markiert, beendet sich codex exec bei einem Initialisierungsfehler komplett statt ohne den Server weiterzulaufen. Setzen Sie den Server testweise auf optional oder prüfen Sie dessen Logs.
• PowerShell blockiert das Installationsskript: Das liegt an der Standard-Execution-Policy von Windows. Der offizielle Befehl umgeht das bereits mit -ExecutionPolicy ByPass, prüfen Sie aber, ob eine Unternehmensrichtlinie diesen Parameter zusätzlich sperrt.
• Rate-Limit- oder Kontingent-Meldungen: Bei ChatGPT-Konten ist die Nutzung an das jeweilige Abo-Kontingent gekoppelt, bei API-Keys an Ihr OpenAI-Nutzungslimit. Prüfen Sie in beiden Fällen zuerst den aktuellen Verbrauch in Ihrem OpenAI-Konto, bevor Sie das Kontingent erhöhen.
• codex exec liefert in einer Pipe keine Ausgabe: Denken Sie daran, dass Fortschrittsmeldungen auf stderr laufen und nur die finale Antwort auf stdout erscheint. Leiten Sie testweise beide Streams um, um zu prüfen, ob der Lauf überhaupt durchläuft.
• Git-Integration erkennt das Repository nicht: Prüfen Sie mit git remote -v, ob ein Remote gesetzt ist, und richten Sie bei Bedarf die GitHub-CLI mit gh auth login ein, bevor Sie Codex erneut starten.

Kosten und Abrechnung im Überblick

Eine der häufigsten Fragen vor dem Einstieg betrifft die Kosten. Codex CLI selbst ist als Software kostenlos, laut offizieller Dokumentation entstehen Kosten ausschließlich über die gewählte Zugangsmethode. Melden Sie sich mit einem ChatGPT-Konto an, ist die Nutzung der CLI in Ihrem bestehenden Plus-, Pro-, Business-, Edu- oder Enterprise-Abonnement enthalten, es fällt also keine separate Rechnung an. Für Einzelentwickler ist das oft der einfachere Weg, weil ein Kontingent im Abo bereits eingepreist ist und sich nicht ständig neu abschätzen lässt.

Die Alternative über einen API-Key rechnet dagegen nach tatsächlichem Token-Verbrauch ab, ähnlich wie bei anderen OpenAI-API-Produkten. Das lohnt sich vor allem für Teams, die Codex CLI ausschließlich in CI-Pipelines oder Batch-Jobs einsetzen und dort ein planbares, nutzungsbasiertes Abrechnungsmodell bevorzugen, statt Lizenzen pro Kopf zu kaufen. Da sich konkrete Preise pro Token regelmäßig ändern, prüfen Sie die aktuellen Tarife direkt in Ihrem OpenAI-Konto, bevor Sie ein Budget für ein Team festlegen. Für Unternehmen mit GitHub-Copilot-Enterprise-Lizenzen oder bereits laufendem Amazon Q Developer-Einsatz lohnt sich vorher ein interner Kostenvergleich, weil Doppellizenzierung für dieselbe Aufgabe selten sinnvoll ist.

Datenschutz und Sicherheit für Teams in Österreich

Für österreichische Unternehmen, die Codex CLI an Firmen-Repositories heranlassen, sind die Sandbox- und Netzwerkeinstellungen aus den Schritten 7 und 8 mehr als nur eine technische Fußnote. Sie bestimmen direkt, welche Daten das Tool überhaupt verlassen und wohin. Laut den offiziellen Sicherheitsdokumenten läuft der Agent lokal standardmäßig ohne Netzwerkzugriff, Prompts und Code-Ausschnitte werden also nur dann an OpenAI übertragen, wenn eine Anfrage tatsächlich an das Modell geschickt wird, nicht bei jedem lokalen Dateizugriff.

Bei Codex Cloud, dem gehosteten Gegenstück zur CLI, beschreibt OpenAI ein zweiphasiges Modell: Eine Setup-Phase darf auf das Netzwerk zugreifen, um Abhängigkeiten zu installieren, danach läuft die eigentliche Agenten-Phase standardmäßig offline, sofern Sie den Internetzugriff für diese Umgebung nicht ausdrücklich aktivieren. In Cloud-Umgebungen konfigurierte Zugangsdaten sind laut Dokumentation nur während der Setup-Phase verfügbar und werden vor dem Start der Agenten-Phase entfernt. Für Unternehmenskunden mit strengeren Compliance-Anforderungen bietet OpenAI zusätzlich Workload-Identity-Föderation an, damit keine dauerhaften API-Keys in CI-Systemen hinterlegt werden müssen, sowie ein separates Sicherheits-Whitepaper mit Details zur Enterprise-Sicherheitsarchitektur. Wer in einem regulierten Umfeld arbeitet, sollte dieses Dokument vor dem produktiven Einsatz mit der eigenen Rechtsabteilung abstimmen, statt sich allein auf die technischen Standardeinstellungen zu verlassen.

Codex CLI im Vergleich: GitHub Copilot CLI und Claude Code

Codex CLI ist nicht der einzige Terminal-Agent auf dem Markt. Wer bereits Claude Code eingerichtet hat oder mit GitHub Copilot in VS Code arbeitet, stellt sich zu Recht die Frage, ob ein drittes Tool im selben Terminal überhaupt Sinn ergibt. Die grundlegenden Konzepte ähneln sich: Alle drei Tools lesen Code, schlagen Änderungen vor und laufen mit einstellbaren Freigabestufen. Die Unterschiede liegen im Detail, etwa bei der Frage, wie granular sich Netzwerkzugriff und Freigaben konfigurieren lassen, wie offen der Quellcode ist und wie gut sich das jeweilige Tool in bestehende Automatisierung einbauen lässt. Auch neuere Werkzeuge wie Windsurf spielen in diesem Vergleichsfeld eine Rolle, konzentrieren sich aber stärker auf den Editor als auf das reine Terminal.

Kriterium	Codex CLI	GitHub Copilot CLI	Claude Code
Anbieter	OpenAI	GitHub / Microsoft	Anthropic
Lizenz	Quelloffen (Apache-2.0)	Proprietär	Proprietär
Implementierung	Rust	Node.js-basiert	Node.js-basiert
Abrechnung	Über ChatGPT-Abo oder API-Key	Über GitHub-Copilot-Abo	Über Claude-Abo oder API-Key
Nicht-interaktiver Modus	codex exec mit JSON-Streaming und Schema-Output	Eingeschränkter, primär interaktiv ausgelegt	Eigener nicht-interaktiver Modus für CI vorhanden
Sandbox-Kontrolle	Granular über config.toml, drei Sandbox-Stufen	Einfacher gehalten	Granular über eigene Berechtigungsstufen

Für Teams, die bereits stark in ein Ökosystem investiert haben, etwa in GitHub-Copilot-Lizenzen für die gesamte Organisation, überwiegt oft der Aufwand eines Tool-Wechsels den Nutzen. Wer dagegen ohnehin ein ChatGPT-Business- oder -Enterprise-Abo hat, bekommt Codex CLI faktisch ohne Zusatzkosten dazu und kann es risikofrei parallel zu Cursor oder anderen Editoren testen, da die CLI unabhängig vom gewählten Editor läuft. Ein Praxistipp aus der Community: Viele Teams nutzen Codex CLI gezielt für Aufgaben mit klar abgegrenztem Scope, etwa Testabdeckung erhöhen oder Migrationsskripte schreiben, und lassen komplexere Architekturentscheidungen weiterhin manuell im Review laufen. Einen breiteren Überblick über aktuelle Entwicklertools und KI-Coding-Assistenten finden Sie in der Software-Rubrik von shattered.io.

Erweiterte Tipps für den produktiven Alltag

Sobald die Grundinstallation steht, lohnen sich ein paar fortgeschrittene Funktionen, die im Alltag viel Zeit sparen. Die meisten davon sind in der Standarddokumentation etwas versteckt, weil sie erst nach den ersten produktiven Wochen relevant werden, wenn die Basis-Workflows bereits sitzen und Sie anfangen, Codex CLI enger in bestehende Tools und Teamprozesse einzubinden.

• Sitzungen fortsetzen: Mit codex resume öffnen Sie die letzte Unterhaltung im aktuellen Repository erneut oder durchsuchen ältere lokale Sitzungen, statt jedes Mal von vorne zu erklären.
• Screenshots als Kontext: Der Flag --image erlaubt es, einen Fehler-Screenshot oder ein Architekturdiagramm direkt in den ersten Prompt einzubinden, ohne den Sachverhalt komplett in Textform zu beschreiben.
• Live-Websuche aktivieren: Standardmäßig nutzt Codex einen zwischengespeicherten Suchmodus. Für Aufgaben, die von aktuellen Release-Notizen oder externer Dokumentation abhängen, schaltet --search auf Live-Browsing um.
• Arbeit an Subagenten delegieren: Bei größeren Untersuchungen kann Codex laut Dokumentation Teilaufgaben an spezialisierte Subagenten auslegen und deren Ergebnisse anschließend in der Hauptsitzung zusammenführen.
• MCP-Server verbinden: Über codex mcp binden Sie lokale oder entfernte MCP-Server ein und sehen vorab, welche Werkzeuge der aktiven Sitzung zur Verfügung stehen, etwa eine interne Ticket-API oder eine Datenbankanbindung.
• Code-Review ohne Commit: Der Befehl codex review prüft unkommittierte Änderungen, einen bestimmten Commit oder einen ganzen Branch gegenüber einer Basis, ohne selbst etwas am Arbeitsverzeichnis zu verändern, und meldet priorisierte Befunde zurück.
• Shell-Completions einrichten: Mit codex completion zsh oder der passenden Variante für Ihre Shell generieren Sie Autovervollständigung für alle Unterbefehle, was gerade bei der Vielzahl an Flags spürbar Zeit spart.

Ein Diagnosewerkzeug, das viele erst spät entdecken: codex doctor erstellt einen lokalen Statusbericht zu Installation, Konfiguration, Authentifizierung, Laufzeitumgebung, Git-Integration und Terminal, bevor Sie überhaupt einen Support-Kanal kontaktieren müssen. Führen Sie den Befehl direkt nach der Installation einmal aus, um einen sauberen Ausgangszustand zu dokumentieren, gegen den Sie spätere Probleme vergleichen können.

Häufig gestellte Fragen

Ist die OpenAI Codex CLI kostenlos?

Die Software selbst ist quelloffen und kostenlos herunterladbar. Für die eigentliche Nutzung brauchen Sie aber entweder ein bestehendes ChatGPT-Abo (Plus, Pro, Business, Edu oder Enterprise), in dem die Nutzung laut offizieller Dokumentation enthalten ist, oder einen OpenAI-API-Key, der nach tatsächlichem Token-Verbrauch abgerechnet wird.

Brauche ich Node.js, um Codex CLI zu installieren?

Nur wenn Sie sich für den npm-Installationsweg entscheiden. Der offizielle Standalone-Installer über curl beziehungsweise PowerShell sowie die Homebrew-Variante kommen ohne Node.js aus, da die CLI selbst in Rust geschrieben ist.

Kann Codex CLI versehentlich Dateien löschen oder Befehle ausführen, die ich nicht wollte?

Im Standardmodus ist das Risiko gering, weil Codex ohne Netzwerkzugriff läuft und Schreibrechte auf das aktuelle Arbeitsverzeichnis begrenzt sind. Aktionen außerhalb dieses Bereichs erfordern laut Sicherheitsdokumentation eine ausdrückliche Freigabe, es sei denn, Sie wählen bewusst den Modus danger-full-access, der nur in isolierten Umgebungen sinnvoll ist.

Wie unterscheidet sich Codex CLI von der ChatGPT-Codex-App oder Codex Web?

Codex CLI läuft lokal in Ihrem Terminal und arbeitet direkt mit Dateien auf Ihrem Rechner. Codex Web (unter chatgpt.com/codex) ist der Cloud-Agent, der in isolierten, von OpenAI verwalteten Containern arbeitet und keinen direkten Zugriff auf Ihr lokales System hat. Die Desktop-App, gestartet über codex app, bietet eine grafische Oberfläche für dieselbe zugrunde liegende Technologie.

Funktioniert Codex CLI auch mit privaten Firmen-Repositories?

Ja, die CLI arbeitet mit jedem lokal geklonten Git-Repository, unabhängig davon, ob es öffentlich oder privat ist. Für Team- und Unternehmenseinsätze bietet OpenAI zusätzliche Enterprise-Funktionen, etwa verwaltete Konfigurationen und Workload-Identity-Föderation, damit keine dauerhaften Zugangsdaten in CI-Systemen gespeichert werden müssen.

Lässt sich Codex CLI in eine GitHub-Actions-Pipeline einbauen?

Ja. Für GitHub Actions empfiehlt OpenAI ausdrücklich die eigene Codex GitHub Action statt der manuellen Installation und Authentifizierung der CLI, weil die Action die API-Key-Exponierung reduziert, indem sie einen eigenen Proxy für die Responses-API startet und Codex mit einer konfigurierbaren Sicherheitsstrategie ausführt. Für andere CI-Systeme ohne fertige Action bleibt der manuelle Weg über codex exec und eine sauber gescopte CODEX_API_KEY-Variable die gängige Alternative, solange Sie die Hinweise zu Job-weiten Umgebungsvariablen aus dem Abschnitt zu häufigen Fehlern beachten.

Was ist der Unterschied zwischen workspace-write und danger-full-access?

Im Modus workspace-write darf Codex nur innerhalb des aktuellen Arbeitsverzeichnisses lesen und schreiben, Netzwerkzugriff bleibt standardmäßig deaktiviert. Der Modus danger-full-access hebt diese Einschränkungen komplett auf und sollte laut offizieller Empfehlung ausschließlich in kontrollierten, isolierten Umgebungen wie einem CI-Runner oder Container zum Einsatz kommen, niemals auf einem produktiven Arbeitsplatzrechner.

Lohnt sich ein API-Key oder reicht das ChatGPT-Abo für den Einstieg?

Für den Einstieg und für Einzelpersonen reicht in der Regel ein bestehendes ChatGPT-Abo völlig aus, weil die CLI-Nutzung dort bereits enthalten ist und Sie kein separates API-Budget verwalten müssen. Ein API-Key lohnt sich vor allem, sobald Codex CLI in automatisierten Pipelines ohne menschliche Interaktion läuft, etwa in nächtlichen CI-Jobs, weil dort ein nutzungsbasiertes Abrechnungsmodell transparenter ist als ein geteiltes Abo-Kontingent mehrerer Teammitglieder.