Claude Code vs Codex: sieben Arten, wie Entwickler die Arbeit zwischen beiden aufteilen, statt sich für eines zu entscheiden

Am 30. März 2026 hat OpenAI codex-plugin-cc veröffentlicht, ein Plugin, das Codex aus Claude Code heraus startet. Das README sagt, für wen es gedacht ist: für Claude-Code-Nutzer, die Codex "from the workflow they already have" verwenden wollen. OpenAI bittet diese Nutzer nicht um einen Wechsel. Es bittet um einen Platz neben dem Tool, das sie schon gewählt haben. Die Vergleichsseiten, die für „Claude Code vs Codex“ ranken, sind Feature-Tabellen mit einem Sieger in der letzten Zeile, und sie gehen davon aus, dass du dich für eines entscheidest.

Das hier ist also eine Liste, wie die Arbeit aufgeteilt wird, und kein Ranking. Unten gibt es zwei Kennzeichnungen. Dokumentiert heißt: Die Doku oder das Repository eines Herstellers beschreibt den Mechanismus. Berichtet heißt: Eine namentlich genannte Person hat ihr Setup veröffentlicht, und ich gebe es weiter, ohne es nachgebaut zu haben. Alle Versionsangaben haben den Stand Oktober 2026.

Im Mai habe ich geschrieben, dass ich Claude für das meiste nutze und Codex für ein paar Dinge, bei denen es messbar besser ist. Die Muster unten sind das, was andere um dieselbe Idee herum gebaut haben, mit einem Unterschied: Die meisten teilen nach Rolle auf und nicht danach, welches Modell bei einer Aufgabe besser ist.

Kann Codex den Code prüfen, den Claude Code gerade geschrieben hat?

Ja, und für diese Aufteilung gibt es die meiste Unterstützung. Sie ist dokumentiert: Das Plugin ergänzt Claude Code um /codex:review, das deine nicht committeten Änderungen oder deinen Branch gegen eine Basis prüft, und das README sagt, der Befehl "is read-only and will not perform any changes." Das README verspricht dieselbe Review-Qualität wie /review in Codex selbst, das laut OpenAIs Code-Review-Doku priorisierte Befunde meldet, ohne deinen Working Tree zu verändern.

Beide Tools haben bereits einen eigenen Reviewer. Claude Code hat ein lokales /code-review und ein verwaltetes GitHub Code Review für Team- und Enterprise-Pläne, das Anthropic mit durchschnittlich 15 bis 25 Dollar pro Review beziffert. Niemand holt sich den Reviewer des anderen Herstellers, weil ihm einer fehlt. Man tut es, damit eine andere Modellfamilie den Diff liest, und zwar ohne die Unterhaltung, in der er entstanden ist.

Die fehlende Unterhaltung leistet so viel wie die andere Familie. Ein Reviewer, der die ganze Session des Autors bekommt, erbt mit den Fakten auch dessen verworfene Vermutungen. Das ist dieselbe Kontamination, die ich in Dein geforkter Subagent weiß bereits zu viel beschrieben habe. /codex:review startet Codex auf dem Diff, nicht auf der Claude-Code-Session. Die Frische kommt vom Befehl und gilt bei einem anderen nicht mehr: Dasselbe Plugin hat einen Transfer-Befehl, um den es weiter unten geht und dessen ganzer Zweck es ist, die Session hinüberzutragen.

Im August habe ich argumentiert, dass der Review-Platz nach Disposition vergeben werden sollte: Dorthin gehört das Modell, das umherstreift, zweifelt und zu viel prüft. Der Text hält auch das Einzige fest, was ich aus erster Hand über Review über Modellfamilien hinweg berichten kann: Zwei Reviewer aus verschiedenen Familien haben meine erste Fassung des Arguments gelesen, und jeder fand darin einen anderen Fehler. Der Beitrag nennt die Familien nicht, und ein einzelner Fall ist keine Quote.

Kann Codex einen Plan von Claude Code angreifen, bevor Code existiert?

Das ist das erste Muster, das früher ansetzt: am Plan statt am Diff. Das Plugin hat dafür einen zweiten Review-Befehl, und Leute berichten, dass sie ihn auf Pläne richten. Der dokumentierte Teil: /codex:adversarial-review nimmt nach seinen Flags einen frei formulierten Fokus entgegen und ist laut README gedacht für "pressure-testing around specific risk areas like auth, data loss, rollback, race conditions, or reliability." Auch dieser Befehl ist read-only. Sein Ziel wählt er so wie /codex:review, aus den Änderungen im Repository. Ein Plan muss also als Datei im Working Tree liegen, damit er geprüft werden kann.

Der berichtete Teil: Engr Mejba Ahmed beschreibt, wie er Claude Code einen Migrationsplan entwerfen und Codex ihn vor der Umsetzung angreifen lässt. Nach seiner Darstellung fand das Review einen fehlenden Fremdschlüssel und einen Index, der bei gleichzeitigen Schreibzugriffen zu einem Deadlock führen konnte. Er begrenzt das Plan-Review auf zwei Runden, mit der Begründung, dass eine dritte Runde bedeutet, dass der Plan einen anderen Ansatz braucht und keine weitere Kritik. Diese Obergrenze ist der übertragbare Teil. Zwei Modelle können höflich uneins sein, solange du sie dafür bezahlst.

Sollte Claude Code planen und prüfen, während Codex den Code schreibt?

Manche machen es genau so herum. Die Aufteilung folgt der Rolle, und die Marke in jeder Rolle ist verhandelbar. Dieses Muster ist nur berichtet: Der plan-execute-Skill von longranger2 nimmt eine fertige Plandatei, lässt Claude Code sie zur Umsetzung an Codex schicken, lässt Claude Code dann jedes Ergebnis prüfen und die Befunde im Verzeichnis reviews/ ablegen und schickt Codex zurück, um das Gefundene zu beheben. Die erklärte Regel des Skills lautet, dass Claude Code in dieser Schleife überhaupt keinen Code schreibt oder bearbeitet. Es prüft und orchestriert.

Neben dem ersten Muster wirkt das widersprüchlich. Im einen ist Codex der Reviewer, im anderen der Implementierer. In dem Teil, auf den es ankommt, sind sie sich einig: Autor und Reviewer sind verschiedene Systeme, und was zwischen ihnen wandert, ist eine Datei. Ob Claude Code oder Codex auf dem Stuhl des Autors sitzt, ist eine Präferenz dafür, welchem Modell du zutraust, auf deiner Codebasis im Scope zu bleiben. Diese Präferenz lässt sich kaum von einer Codebasis auf die nächste übertragen, und eine Tabelle, die das behauptet, verdient Misstrauen.

Wann sollte Claude Code ein festgefahrenes Problem an Codex abgeben?

Wenn ein zweiter Versuch von einem anderen Modell billiger ist als ein fünfter vom selben. Der Mechanismus ist dokumentiert: /codex:rescue übergibt eine Aufgabe an Codex, über einen Subagenten, den das Plugin installiert, codex:codex-rescue. Das README zählt die vorgesehenen Einsätze auf: einen Bug untersuchen, einen Fix versuchen, eine frühere Codex-Aufgabe fortsetzen oder "take a faster or cheaper pass with a smaller model." Der Befehl kann im Hintergrund laufen, und /codex:status und /codex:result berichten darüber. Normale Sprache geht auch. Das Beispiel im README selbst: Claude bitten, Codex eine Datenbankverbindung neu entwerfen zu lassen.

Anders als die beiden Review-Befehle kann dieser hier Dateien ändern. Die Definition des Rescue-Agenten im Plugin weist ihn an, standardmäßig einen schreibfähigen Lauf zu starten, außer du verlangst Read-only-Verhalten oder willst nur eine Diagnose.

Mejbas berichtete Regel fürs Delegieren: Er gibt nur Arbeit ab, die er selbst beurteilen kann, weil eine falsche Antwort, die er nicht erkennt, schlimmer ist als keine. Das ist eine vernünftige Regel für jede Delegation, und über Herstellergrenzen hinweg greift sie härter, weil du dort die Gewohnheiten von zwei Tools erkennen musst statt von einem.

Kann Codex jeden Turn von Claude Code automatisch durch ein Review-Gate schicken?

Ja, und das README des Plugins warnt selbst davor. Der Schalter ist dokumentiert: /codex:setup --enable-review-gate installiert einen Stop-Hook, der ein gezieltes Codex-Review von Claudes Antwort ausführt und den Stopp blockiert, wenn das Review Probleme findet. Claude muss sie dann zuerst beheben. Die Warnung steht direkt unter dem Feature:

The review gate can create a long-running Claude/Codex loop and may
drain usage limits quickly. Only enable it when you plan to actively
monitor the session.

Zachary Proser berichtet, dass er seine eigene Version auf codex exec gebaut hat. Sein Stop-Hook vergleicht den Working Tree mit der Branch-Basis und überspringt das Review bei kleinen Diffs, die keine Hochrisiko-Pfade berühren (er nennt Auth, Billing, Migrationen und Infrastruktur). Andernfalls schickt er den Diff und die geänderten Dateien mit einem adversarialen Auftrag und einem Timeout an codex exec und erwartet strukturiertes JSON mit einem Urteil zurück. Ein block-Urteil lässt den Hook fehlschlagen. Ein Timeout oder eine fehlerhafte Ausgabe ebenso: Sein Hook ist fail-closed. Eine Meinungsverschiedenheit zwischen den beiden Modellen behandelt er als Hinweis auf die Zeile, die er selbst lesen sollte, und nicht als Abstimmung.

Eine Warnung, bevor du es kopierst. Das veröffentlichte Skript liest die Schlussnachricht aus Events vom Typ message, während OpenAIs aktuelle Doku zum nicht-interaktiven Modus zeigt, dass sie als item.completed-Event mit einer agent_message ankommt. Ich habe seinen Hook nicht ausgeführt, aber ein Selektor, der in einem Fail-closed-Hook auf nichts passt, blockiert jeden Turn. Das ist immerhin die laute Art, es herauszufinden. Das Flag --output-schema aus der Doku ist der robustere Weg zu einem Urteilsobjekt.

Die Schwelle und die Fail-closed-Regel sind so oder so die Teile, die sich zu kopieren lohnen. Ohne die Schwelle kauft jede triviale Änderung ein Review. Ohne fail-closed zählt ein Timeout als Freigabe.

Wie teilen sich Claude Code und Codex einen gemeinsamen Satz Anweisungen?

Über AGENTS.md, mit einer Zeile Klebstoff auf der Claude-Seite. Beide Hälften sind dokumentiert. Codex baut seine Anweisungen aus ~/.codex und dann vom Projekt-Root abwärts bis zum aktuellen Verzeichnis, höchstens eine Datei pro Verzeichnis, vom Root aus aneinandergehängt, und fügt keine Dateien mehr hinzu, sobald die Summe die Voreinstellung von 32 KiB erreicht. /init in Codex legt die Datei an.

Seit v2.1.277 liest Claude Code AGENTS.md standardmäßig nur dann, wenn es im Arbeitsverzeichnis oder darüber weder CLAUDE.md noch CLAUDE.local.md gibt. Ein Repository mit beiden Dateien bekommt nur CLAUDE.md, außer du änderst die Einstellung für Projektanweisungen. Die Folgen bin ich in Claude Code liest jetzt AGENTS.md, und der Standard ist ein Fallback durchgegangen, und der Rat aus dem Beitrag gilt für alle, die beide Tools nutzen: Leg eine CLAUDE.md an, deren erste Zeile die gemeinsame Datei importiert, und setz die Regeln, die nur für Claude gelten, darunter.

Eine Einschränkung aus demselben Beitrag: Der Import holt nur die Datei, die er nennt, und sobald eine CLAUDE.md existiert, werden AGENTS.md-Dateien in Unterverzeichnissen standardmäßig nicht mehr gefunden. Eine verschachtelte AGENTS.md, die Codex auf seinem Weg aufsammelt, braucht einen eigenen Import oder die Einstellung für beide Dateien. Eines meiner eigenen Repositories hatte die umgekehrte Form, als ich den Beitrag schrieb: eine AGENTS.md mit der Überschrift „Codex Instructions“ und gar keine CLAUDE.md.

@AGENTS.md
 
## Claude Code
 
Use plan mode for changes under `src/billing/`.

Die beiden Tools behandeln die gemeinsame Datei nicht gleich. Codex hat eine Obergrenze von 32 KiB über die ganze Kette und nimmt eine Datei pro Verzeichnis. Claude Code lädt eine Anweisungsdatei bis 4 MiB vollständig, empfiehlt, unter 200 Zeilen zu bleiben, und lädt Dateien in Unterverzeichnissen bei Bedarf. Eine lange Kette von AGENTS.md-Dateien kann für den einen Leser abgeschnitten und für den anderen ganz geladen werden. Wenn die beiden Agenten unterschiedlichen Regeln zu folgen scheinen, prüf die Länge, bevor du die Modelle prüfst.

Wie zieht man eine Session oder ein ganzes Setup zwischen Claude Code und Codex um?

Beide Hersteller liefern inzwischen einen Importer für die Konfiguration des jeweils anderen, und OpenAI liefert einen für eine laufende Session. All das ist dokumentiert. /codex:transfer im Plugin, im Juni hinzugekommen, macht Folgendes:

Creates a persistent Codex thread from the current Claude Code session
and prints a `codex resume <session-id>` command.

Für das Setup als Ganzes hat die Codex CLI seit dem 11. August 2026 /import. OpenAIs Import-Doku zählt auf, was der Import mitbringen kann: Anweisungsdateien, Einstellungen, Skills, Plugins, MCP-Server-Konfiguration, Hooks, Slash-Befehle und Subagenten. Die CLI importiert außerdem bis zu 50 Chats aus den letzten 30 Tagen. Dieselbe Seite rät, Tool-Einschränkungen, MCP-Authentifizierung und Hooks danach erneut zu prüfen, weil sie sich anders verhalten können.

Claude Code hat das Spiegelbild. Die Befehlsreferenz führt /import codex auf, verfügbar ab v2.1.213. Es übernimmt Anweisungsdateien, MCP-Server, Befehle, Subagenten und Skills, mit --dry-run zur Vorschau. /init bietet an, es auszuführen, wenn es eine Codex-Konfiguration findet.

Jeder Importer erstellt eine Kopie. Keiner verknüpft die beiden Setups, mit einer Ausnahme: Die ChatGPT-Desktop-App kann einen Import mit automatischen Updates synchron halten, und die CLI-Doku beschreibt keine solche Option. Ein kopiertes Setup driftet vom Original weg, sobald du eine der beiden Seiten bearbeitest. Nutz den Import, um das andere Tool mit deiner echten Konfiguration auszuprobieren. Um zwei Konfigurationen gleich zu halten, ist er das falsche Werkzeug, und für Anweisungen erledigt die gemeinsame AGENTS.md von oben das besser.

Laufen Claude Code und Codex unter derselben Sandbox, wenn man sie kombiniert?

Nein, und das Plugin vereinheitlicht sie nicht.

Die Security-Doku von Codex hält fest, dass der Agent standardmäßig mit abgeschaltetem Netzwerkzugriff läuft, und die Doku zum nicht-interaktiven Modus, dass codex exec in einer Read-only-Sandbox startet, bis du --sandbox workspace-write übergibst. Die Sandboxing-Seite von Claude Code sagt, dass die Bash-Sandbox standardmäßig aus ist und nur Shell-Befehle abdeckt: Die Datei-Tools, MCP-Server und Hooks laufen außerhalb. Keine der beiden Sandboxes deckt das ganze Tool ab. Der Netzwerkfilter von Codex gilt für Befehle in der Sandbox und laut derselben Doku nicht für die Websuche, für Verbindungen zu MCP-Servern oder für Connector-Aufrufe. Im Auslieferungszustand stützt sich Claude Code auf Permission-Regeln und Modi vor jedem Tool-Aufruf, Codex auf eine Betriebssystemgrenze um die Befehle, die es ausführt. Dieselbe Aufgabe hat ein anderes Risiko, je nachdem, welches Tool sie ausführt.

Für ein aufgeteiltes Setup hat das eine konkrete Folge, und im README findest du sie nicht. Das README sagt, das Plugin nutze "the same local authentication state" und "the same repository checkout and machine-local environment" wie ein direkt gestartetes Codex, und es wende deine Codex-Konfiguration an. Der Quelltext des Plugins ist genauer. Mit Stand des Commits vom 8. Juli startet es Codex-Threads mit der Approval-Policy never und der Sandbox read-only, und sein Task-Runner schaltet die Sandbox auf workspace-write, wenn eine Aufgabe mit --write gestartet wird. Genau das tut der Rescue-Agent standardmäßig. Ein delegierter Fix läuft also ohne Rückfragen innerhalb der Workspace-Sandbox von Codex. Die Freigabe der Delegation in Claude Code ist die einzige Freigabe, die es gibt. Für einen Hintergrundjob ist das ein vernünftiges Design, und das heißt, dass die Sandbox die ganze Arbeit macht: Prüf, welches Verzeichnis der Workspace ist, bevor du einen Schreibvorgang delegierst.

Welche Integrationen zwischen Claude Code und Codex funktionieren seit 2026 nicht mehr?

Mehrere, und ältere Tutorials beschreiben sie noch. Die größte ist die MCP-Brücke. Eine Zeit lang war es üblich, Codex von einem anderen Agenten aus zu erreichen, indem man es als MCP-Server startete. Der Codex-Changelog-Eintrag vom 5. September 2026 beendet das:

The codex mcp-server command and standalone codex-mcp-server binary
have been removed after their deprecation on August 24, 2026. Update
integrations that launch either command before upgrading Codex. Use
the Codex app server for integrations.

Jedes Community-Setup, das codex mcp-server in die MCP-Konfiguration von Claude Code einträgt, funktioniert nach dem Upgrade nicht mehr. Das offizielle Plugin ist nicht betroffen, denn laut README kapselt es den Codex App Server. Derselbe Changelog-Eintrag beschreibt den App-Server-Befehl als experimentell und nicht für Produktions-Workloads unterstützt. Das sollte man wissen, bevor man ein unbeaufsichtigtes Gate daran hängt.

Drei kleinere Änderungen betreffen alte Skripte und Tutorials:

• codex exec --full-auto ist ein veraltetes Kompatibilitäts-Flag, das eine Warnung ausgibt. Die Doku sagt, du sollst --sandbox workspace-write ausdrücklich übergeben.
• approval_policy = "untrusted" ist in Codex abgeschafft, und laut Doku kann die übrig gebliebene Einstellung verhindern, dass der Client startet.
• In Claude Code ist /review seit v2.1.223 ein Alias von /code-review. Davor war es ein eigener Befehl zum Prüfen eines GitHub-Pull-Requests. Ein Tutorial, in dem „führe /review aus“ steht, beschreibt also womöglich einen anderen Befehl.

Die umgekehrte Brücke existiert nur auf dem Papier: Claude Code dokumentiert weiterhin claude mcp serve, aber das stellt einem MCP-Client die Tools von Claude Code bereit, nicht den Agenten, und kein hier zitierter Bericht verdrahtet es mit Codex.

Mit welcher Aufteilung zwischen Claude Code und Codex solltest du anfangen?

Fang mit dem Review auf Abruf an, /codex:review auf einem fertigen Diff, und bleib dabei, bis du ein paar Dutzend Befunde gelesen hast. Das ist meine Lesart der Quellen, keine Messung.

Von den sieben ist es die Aufteilung, aus der du am billigsten wieder herauskommst. Der Befehl ist read-only, er läuft, wenn du ihn aufrufst, und nichts in deinem Workflow hängt davon ab. Das README des Plugins sagt, ein ChatGPT-Abo genüge, der Free-Plan eingeschlossen, wobei die Nutzung auf deine Codex-Limits angerechnet wird. Der erste Versuch muss also kein zweiter bezahlter Plan sein. Und beim Lesen der Befunde lernst du, ob das zweite Modell in deinem Code Dinge sieht, die das erste übersieht. Das ist die einzige Frage, die es rechtfertigt, zwei Tools zu betreiben. Wenn die Befunde großteils wiederholen, was dir /code-review schon gesagt hat, hast du deine Antwort, und sie hat dich einen Nachmittag gekostet.

Schalte das Gate zuletzt ein, wenn überhaupt, und nur mit einer Größenschwelle und einer Entscheidung darüber, was bei einem Timeout passiert. Delegiere Schreibvorgänge erst, nachdem du geprüft hast, welches Verzeichnis Codex als seinen Workspace behandelt.

Wer das zweite Tool auslassen sollte: alle, deren Änderungen so klein sind, dass sie ohnehin jede Zeile lesen, und alle, die einen guten Befund noch nicht von einem selbstsicher falschen unterscheiden können. Ein zweites Modell vergrößert den Stapel, den du beurteilen musst. Es beurteilt ihn nicht für dich.

In allen sieben Mustern ist das, was zwischen den Tools wandert, ein Artefakt: ein Diff, eine Plandatei, eine Datei mit Befunden, eine AGENTS.md, eine exportierte Session. Keines teilt eine laufende Unterhaltung, und die Brücken der Hersteller enden alle bei Dateien und Threads. Wenn die Artefakte gut sind, kann jedes der beiden Tools auf jeder Seite davon sitzen. Die Freigabe wandert nicht mit dem Artefakt. Wer den Stift hält, schreibt unter seiner eigenen Sandbox. Die Plätze zu tauschen ist deshalb auf der Dateiseite eine Konfigurationsänderung und auf der anderen eine Berechtigungsprüfung.