ChatGPT Codex erklärt: OpenAIs Coding-Agent im Praxistest

Warum ChatGPT Codex jetzt relevant ist

Wenn du in den letzten Monaten irgendetwas zu Agentic Coding gelesen hast, ging es vermutlich um Claude Code oder Cursor. OpenAIs Antwort heißt ChatGPT Codex – und sie ist still, aber schnell zu einem ernstzunehmenden Player geworden.

Dabei ist Codex kein völlig neues Produkt. Frühe Versionen lieferten noch lückenhafte Ergebnisse und hatten mit Sandbox-Stabilität und Kontextverlust zu kämpfen. Erst mit dem letzten großen Update – verbunden mit GPT-5-class Modellen und einer überarbeiteten Agent-Loop – ist Codex auf das Niveau von Claude Code und Cursor aufgestiegen. Wer vor drei Monaten abgeschrieben hat, sollte neu bewerten.

Codex ist kein neues Modell. Codex ist eine Agent-Umgebung: Du beschreibst eine Aufgabe in natürlicher Sprache, Codex spinnt eine isolierte Sandbox auf, liest deine Codebase, schreibt Code, führt Tests aus, debuggt und öffnet am Ende einen Pull Request – meistens, ohne dass du dabei zuschaust.

Das klingt nach demselben Versprechen wie bei Claude Code. Der Unterschied liegt in der Architektur und im Workflow. Und genau darum geht es in diesem Artikel.

Was Codex eigentlich ist

Der Name „Codex" hat Geschichte. Die ursprüngliche Codex-API von 2021 war das Modell hinter GitHub Copilot – ein feinabgestimmtes GPT-3 für Code. OpenAI hat den Namen 2025 wiederverwendet, aber das Produkt dahinter ist etwas grundlegend anderes:

• Eine cloud-gehostete Agent-Runtime, kein lokales CLI im klassischen Sinn (auch wenn es einen Codex CLI gibt)
• Tief in ChatGPT integriert – du startest Tasks aus der ChatGPT-App, dem Web, dem Terminal oder direkt von GitHub aus
• Modell-agnostisch innerhalb der OpenAI-Familie – aktuell mit GPT-5-class Modellen, die auf Coding und Tool-Use optimiert sind
• Sandbox-first – jeder Task läuft in einer eigenen, isolierten Umgebung mit dem Repo als Snapshot

Wenn Claude Code das „Power-User-Terminal" ist, ist Codex eher das „Asynchrone Coding-Postfach": Du wirfst Tasks rein, gehst weg, kommst zurück und reviewst PRs.

Funktionsprinzip: Wie ChatGPT Codex arbeitet

Codex folgt einem ziemlich konsistenten Loop. Vereinfacht:

1. Task-Input         → Natürliche Sprache, Issue-Link oder Branch-Beschreibung
2. Sandbox-Spawn      → Container mit Repo-Snapshot, Dependencies installiert
3. Repo-Verständnis   → Codex grep-t, liest, baut mentales Modell
4. Plan               → Schritt-Liste, oft als Kommentar im PR sichtbar
5. Implementierung    → Code-Änderungen, in kleinen Commits
6. Verifikation       → Tests, Linter, Type-Checks ausführen
7. Self-Repair        → Fehler lesen, Hypothese, Fix, erneut testen
8. PR öffnen          → Branch pushen, PR mit Summary, Reviewer setzen

Die spannenden Punkte sind 6 und 7. Codex sieht nicht nur den Code, er sieht auch, was passiert, wenn er ausgeführt wird. Test-Output, Stack Traces, Linter-Warnings – alles fließt zurück in den nächsten Reasoning-Schritt. Das ist der Unterschied zwischen „Code generieren" und „Code abliefern, der funktioniert".

Drei Eigenschaften, die Codex prägen

Parallelität als Default. Du kannst zehn Tasks gleichzeitig starten. Jeder läuft in seiner eigenen Sandbox, sie blockieren sich nicht. Das verändert, wie du planst: nicht „was ist das nächste Ticket", sondern „welche fünf Tickets schicke ich jetzt los".

Asynchron statt synchron. Bei Cursor oder Claude Code sitzt du daneben und schaust zu. Bei Codex schickst du Tasks los und reviewst später. Das passt zu Mobile-First-Workflows – du kannst Diffs vom Handy aus approven, während ein Agent in der Cloud baut.

Cloud-Sandbox statt lokale Ausführung. Codex arbeitet nicht direkt auf deiner Maschine, sondern in einer ephemeren Container-Umgebung. Vorteil: Sicherheit, Reproduzierbarkeit, Parallelität. Nachteil: weniger Kontrolle, längere Setup-Zeit pro Task, Abhängigkeit von der OpenAI-Infrastruktur.

Codex vs. Claude Code, Cursor & Copilot: Der Vergleich

Niemand wählt Coding-Agents im Vakuum. Hier die ehrliche Gegenüberstellung mit den vier Tools, gegen die Codex tatsächlich antritt.

Codex vs. Claude Code

Dimension	ChatGPT Codex	Claude Code
Primäre Umgebung	Cloud-Sandbox, ChatGPT-Integration	Lokales Terminal (CLI-first)
Modell	GPT-5-class	Claude Sonnet / Opus
Parallelität	Nativ, viele Tasks gleichzeitig	Via Wrapper (Worktrees, Session Manager)
Mobile-Workflow	Stark – Review aus ChatGPT-App	Schwach – Terminal-gebunden
Lokale Kontrolle	Begrenzt – Sandbox-Abstraktion	Hoch – läuft auf deiner Maschine
Ökosystem	Wachsend, OpenAI-zentriert	Reif, viele Wrapper und ADEs
Pricing	Im ChatGPT-Abo enthalten (Limits)	Pro-Plan oder API-Token

Wann Codex: Du arbeitest viele kleine, unabhängige Tasks parallel ab. Du willst PR-zentriert reviewen. Du bist eh in ChatGPT.

Wann Claude Code: Du willst maximalen Zugriff auf deine lokale Umgebung (Docker, lokale Services, eigene Tools). Du hast bereits in das Tooling-Ökosystem investiert. Du arbeitest stark interaktiv.

Codex vs. Cursor

Cursor ist eine IDE mit aufgeschraubtem Agent. Codex ist ein Agent ohne IDE. Beides funktioniert – aber für unterschiedliche Persönlichkeiten.

• Cursor fühlt sich an wie VS Code, das mitdenkt. Du bleibst im Editor, der Agent unterstützt.
• Codex fühlt sich an wie ein Junior-Entwickler, dem du Tickets gibst. Du verlässt den Editor und kommst nur zum Review zurück.

Teams, die Code-Reviews ohnehin asynchron machen, sind bei Codex schneller produktiv. Teams, die in Pair-Programming-Mustern denken, bleiben bei Cursor glücklicher.

Codex vs. GitHub Copilot Workspace

Copilot Workspace ist Microsofts Antwort auf genau dasselbe Problem – inklusive sehr ähnlicher PR-zentrierter UX. Die Frage ist hier weniger technisch als strategisch:

• Du bist tief in der Microsoft-/GitHub-Welt → Copilot Workspace integriert sich nahtloser
• Du nutzt ChatGPT eh täglich → Codex hat den kleineren Context-Switch
• Du willst Multi-Modell-Optionen → beide sind Single-Vendor, hier hilft eher eine Abstraction Layer

Codex vs. autonome Agent-Teams

Die nächste Stufe oberhalb von Codex sind autonome Agent-Plattformen wie Agent Orchestrator oder Squad – Tools, die Codex (oder Claude Code) als Execution Layer nutzen und darüber Planning, Dispatch und Review orchestrieren. Codex ist hier ein Baustein, nicht der Endpunkt.

Wenn du mehr als eine Handvoll Tasks pro Tag delegierst, lohnt sich der Blick auf die Agentic Coding Tools Landschaft – Codex allein ist dann schnell zu manuell.

Wann Codex die richtige Wahl ist

Drei Szenarien, in denen Codex aktuell glänzt:

1. Bug-Backlogs abarbeiten. Klar umrissene Issues, gute Tests, viel davon. Codex eignet sich hervorragend für „lies das Ticket, fix den Bug, öffne PR".
2. Refactorings mit hoher Test-Coverage. Wenn die Tests gut sind, fängt Codex Regressionen selbst ab.
3. Asynchrone Teams. Wenn dein Team eh PR-basiert arbeitet, fügt sich Codex nahtlos ein.

Und drei, in denen ich aktuell zu Alternativen greifen würde:

1. Architektur-Arbeit. Wenn das Problem unscharf ist, brauchst du Dialog – nicht einen Agent, der drei Stunden später einen PR liefert.
2. Stark lokale Setups. Wenn dein Dev-Environment aus einem Dutzend lokaler Services besteht, ist die Sandbox-Abstraktion mehr Reibung als Hilfe.
3. Experimentelle Codebases ohne Tests. Codex' Self-Repair-Loop lebt von Feedback. Ohne Tests fehlt die wichtigste Signalquelle.

Fazit: Der beste Coding-Agent für deinen Workflow

Codex ist nicht „besser" oder „schlechter" als Claude Code oder Cursor. Es ist ein anderer Punkt auf der Achse zwischen Kontrolle und Delegation. Je weiter rechts du dich auf dieser Achse bewegst, desto mehr verschiebt sich deine Arbeit von „Code schreiben" zu „Tasks formulieren und Outputs reviewen".

Mein praktischer Rat:

• Nicht auf ein Tool committen. Die meisten produktiven Teams, die ich sehe, nutzen zwei bis drei dieser Agents parallel – jedes für den Workflow, in dem es am stärksten ist.
• PR-Hygiene priorisieren. Codex glänzt nur, wenn deine PR-Templates, CI-Pipelines und Test-Suites stabil sind. Schwacher CI = schwacher Agent-Output.
• Beim Modell-Anbieter mitlesen. OpenAI iteriert schnell. Was heute eine Schwäche von Codex ist, kann in zwei Monaten gelöst sein. Setze keine Architektur-Wetten auf den aktuellen Feature-Stand.

Der beste Coding-Agent ist der, der zu deinem Workflow passt – nicht der mit den lautesten Demos.

---

Du baust mit Agentic Coding Tools und brauchst Orientierung, welcher Agent zu welchem Workflow passt? Lass uns reden →