Claude Code und Codex zusammen: 3 Arbeitsmuster

Praktische Materialien zur Arbeit mit Agenten und zum Vibe-Coding: Ailoot-Dokumentation.

Warum reicht 2026 ein einziges Tool nicht mehr aus?#

Im Mai 2026 drang OpenAI mit dem Modell GPT-5.5 in Codex CLI in Anthropic-Territorium vor. In aktuellen Benchmarks liegt Codex bei Terminalaufgaben und im SWE-bench-Verified-Modus klar vorn. Anthropic reagierte mit Opus 4.8 und Dynamic Workflows und behauptet seine Führung bei SWE-bench Pro (einem Test, der Datenlecks verhindern soll und bei dem das Training eines Modells mit dem Benchmark keinen Vorteil bringt). Ein ausführlicher direkter Vergleich findet sich im Leitfaden zu Codex vs. Claude Code—hier kommen wir direkt zur Kombination.

2026 gibt es keinen eindeutigen Sieger. Es zeichnet sich ein Muster ab—Teams behalten Codex für kostengünstige autonome Aufgaben und Claude Code für risikoreiche Architekturentscheidungen.

Der entscheidende Unterschied dafür, wie sich die Arbeit aufteilen lässt:

• Claude Code ist der Rechercheur. Es führt einen langen, tiefgehenden Dialog, hinterfragt Annahmen und erwägt mehrere Ansätze, bevor es eine Lösung auswählt. Es eignet sich für Situationen, in denen die richtige Vorgehensweise nicht von Anfang an klar ist.
• Codex ist der Ausführer. Es erhält eine Aufgabe und arbeitet sich in einer Sandbox zielstrebig bis zum Ergebnis vor. Es eignet sich für klar umrissene Aufgaben, die einen schnellen „Geben-und-Nehmen“-Zyklus erfordern.

Wenn du beide Tools zur Hand hast, musst du dich nicht zwischen „Nachdenken“ und „Handeln“ entscheiden. Du delegierst je nach Aufgabentyp. Falls du noch nicht entschieden hast, welches der beiden du zuerst installieren willst, findest du einen direkten Vergleich im Leitfaden zu Codex vs. Claude Code.

Muster 1: Claude Code schreibt den Code, Codex überprüft ihn#

Bei diesem Muster bleibt Claude Code der leitende Editor. Codex kommt erst auf PR-Ebene über seinen Cloud-Modus hinzu (Codex läuft direkt über ChatGPT oder die GitHub App, sodass du kein zweites Terminal brauchst).

So sieht das in der Praxis aus:

1. Schritt 1: Schreibe das Feature in Claude Code

   Öffne das Repository in VS Code, starte Claude Code, wechsle in den Plan Mode und besprich die Feature-Architektur. Du erhältst Codeentwürfe, Tests und Migrationen. Committe alles auf einem Feature-Branch.

2. Schritt 2: Erstelle einen PR in GitHub

   Erstelle einen Pull Request vom Feature-Branch zu main. Gib in der Beschreibung Folgendes ein: @codex review this PR for edge cases, security issues, and test coverage gaps.

3. Schritt 3: Codex überprüft asynchron

   Im Cloud-Modus klont Codex das Repository in seine Sandbox, liest den Diff, führt Tests und den Linter aus und sucht nach Schwachstellen. Nach 5-15 Minuten hinterlässt es direkt im PR Kommentare.

4. Schritt 4: Nimm Änderungen in Claude Code vor

   Kehre zu Claude Code zurück und gib ihm Codex’ Kommentare als Kontext: „Hier sind die Ergebnisse der Überprüfung; behebe die Punkte 1, 3 und 5.“ Claude nimmt die Änderungen vor und veröffentlicht sie im Repository.

Dieses Muster funktioniert, weil Claude und Codex mit unterschiedlichen Datensätzen trainiert wurden und verschiedene Philosophien verfolgen. Codex erkennt, was Claude aufgrund eines blinden Flecks seines Modells übersehen hat, und umgekehrt.

Risiken von Muster 1:

• Codex kann einen PR mit einer Freigabe schließen und dabei ein Architekturproblem übersehen. Überprüfe wichtige Entscheidungen selbst.
• Doppelte Tokenkosten: Claude und Codex analysieren denselben Code. Bei komplexen Features lohnt es sich, bei kleinen ist es teuer.
• Codex kann im Cloud-Modus deine lokale Umgebung nicht sehen—Umgebungsvariablen oder lokale Datenbanken. Wenn das Feature damit zu tun hat, wechsle zu einem manuellen Durchlauf.

Muster 2: Codex erstellt Entwürfe, Claude Code verbessert die Architektur#

Dieses Muster kam in dem 2026 beschriebenen Projekt zum Einsatz, als an einem Abend ein Prototyp für einen Registrierungsfunnel mit E-Mail-Benachrichtigungen gebaut werden musste. In diesem Szenario hättest du eine Stunde mit Claude Code über die Architektur sprechen können. Codex lieferte in 12 Minuten einen funktionsfähigen Entwurf.

So funktioniert es:

Es läuft so ab: Codex erledigt in den ersten 15 Minuten die Routinearbeit, danach bringt Claude das Ergebnis auf Produktionsqualität.

Bittest du Codex, sofort alles auszuarbeiten, bleibt es an Mehrdeutigkeiten hängen. Bittest du Claude Code, sofort schnell zu arbeiten, beginnt es, alles zu hinterfragen. Gib jedem die Arbeit, für die es gemacht ist.

Risiken von Muster 2:

• Codex erstellt einen Entwurf mit Annahmen, die sich später nur schwer bereinigen lassen. Wenn der Entwurf in die falsche Richtung geht, ist es günstiger, ihn zu verwerfen und neu anzufangen, als ihn zu korrigieren.
• Claude Code verbringt womöglich eine halbe Stunde damit, Variablen umzubenennen, und vergisst das eigentliche Architekturproblem. Gib ihm konkrete Änderungen vor, statt „räum das auf“ zu sagen.
• Zwischen Sitzungen geht Kontext verloren. Damit Claude Code versteht, was Codex beabsichtigt hat, brauchst du eine AGENTS.md (siehe Muster 5) oder einen ausführlichen Kommentar am Dateianfang.

Muster 3: Codex für Infrastruktur, Claude Code für Geschäftslogik#

Die Idee ist einfach: Verschiedene Teile einer Codebasis erfordern unterschiedliche Arbeitsweisen.

Dieses Muster ergänzt den Ansatz, mehrere Claude-Code-Instanzen parallel auszuführen—dort bearbeitet dasselbe Modell über Git-Worktrees verschiedene Aufgaben; hier teilen zwei unterschiedliche Agenten die Verantwortungsbereiche auf.

Infrastrukturebene (Codex):

• GitHub Actions: einen neuen Job hinzufügen, Caching anpassen, CI beschleunigen.
• Tests: nach einem Refactoring eine Suite von Integrationstests schreiben.
• Prisma-Migrationen: eine Migration erzeugen und prüfen, ob sie zurückgerollt werden kann.
• Docker-/Coolify-Konfigurationen: Umgebungsvariablen hinzufügen, den Health Check aktualisieren.
• Cron-Jobs: eine Reihe von Cron-Handlern schreiben.

Codex hat hier die Nase vorn, weil Infrastrukturaufgaben oft aus vielen kleinen Dateien mit Boilerplate-Code bestehen. Codex bleibt nicht beim „Ich muss das erst durchdenken“ hängen, sondern arbeitet die Aufgabe vollständig ab.

Geschäftslogik (Claude Code):

• Registrierungsfunnel: Was dem Nutzer bei jedem Schritt angezeigt werden soll.
• Preisberechnung unter Berücksichtigung von Rabatten, Ratenzahlungen und Geschenk-Promocodes.
• Automatisierte Benachrichtigungsabläufe: welche Auslöser und Bedingungen gelten.
• Integrationen externer APIs: Fehlerbehandlung, Wiederholungsversuche, Caching.
• Finanzmodelle: Berechnungen der Stückökonomie und Umsatzprognosen.

Claude Code hat hier die Nase vorn, weil diese Aufgaben ausführliche Dialoge mit Produktdenken erfordern. Ohne die Szenarien zu besprechen, erhältst du eine technische Lösung, die die tatsächlichen Probleme der Nutzer nicht berücksichtigt.

So wird die Arbeit im Repository aufgeteilt:

project/
├── .github/workflows/      ← Codex (CI, tests)
├── infra/                  ← Codex (Docker, Coolify, migrations)
├── scripts/                ← Codex (task scripts)
├── tests/                  ← Codex (integration tests)
├── src/
│   ├── lib/                ← Claude Code (business logic)
│   ├── app/                ← Claude Code (routes, forms, pages)
│   └── components/         ← Claude Code (UI)
└── prisma/
    └── schema.prisma       ← Claude Code (data models—product decision)

Das ist keine starre Regel. Es kann Überschneidungen geben—Claude Code kann zum Beispiel eine GitHub Action bearbeiten, wenn die Action eine Produktbedeutung hat (etwa eine Benachrichtigung nach der Veröffentlichung zu senden). Aber 80% der Aufgaben passen gut in diese Aufteilung.

Wie synchronisierst du CLAUDE.md und AGENTS.md?#

Bei der beschriebenen parallelen Nutzung von Claude Code und Codex trat ein unerwartetes Problem auf. Claude Code befolgte die Regeln in CLAUDE.md („Migrationen nicht ohne Bestätigung anfassen“). Codex konnte diese Regeln nicht sehen und führte Migrationen in einer Arbeitsumgebung ohne zu zögern aus. Nach der dritten beschädigten Datenbank musste geklärt werden, wie sich beide Dateien richtig synchronisieren lassen.

Beide Dateien können Projektkontext, Gesprächspräferenzen, Testbefehle, Verzeichnisausschlüsse und Commit-Standards enthalten. Übernimm Regeln, die für beide Tools gelten, und halte toolspezifische Befehle und Konfiguration getrennt. Ein Verbot, Migrationen zu ändern, gehört in beide Anweisungssätze, wenn es für beide Agenten gilt.

Was in beiden Dateien gleich ist:

• Stack: welche Frameworks, welche Datenbank, welches ORM.
• Projektbeschreibung: worum es geht, für wen es gedacht ist und welche Hauptentitäten es gibt.
• Verbote: welche Ordner nicht angefasst und welche Befehle nicht ausgeführt werden dürfen.

Was unterschiedlich ist:

• Claude-Code-spezifische Hooks, Einstellungsebenen und MCP-Konfiguration gehören in die jeweiligen Konfigurationsdateien. Beschreibender Text dazu kann aus CLAUDE.md verlinkt werden, wird durch Kopieren aber nicht zu portabler Konfiguration.
• AGENTS.md ist ein offener Standard. Codex, Cursor, Aider, Continue, Cline und Factory Droid lesen ihn—mehr als 25 Agenten. Der separate Leitfaden behandelt das Format von AGENTS.md ausführlicher. Codex-MCP-Konfigurationen sind in ~/.codex/config.toml gespeichert (TOML, nicht JSON wie bei Claude).

Ein verbreitetes Muster im Jahr 2026 ist eine kanonische Regelquelle im Ordner /context/ des Monorepos, aus der ein Synchronisierungsskript CLAUDE.md, .cursor/rules/*.mdc und AGENTS.md generiert. Die tool-spezifischen Dateien werden als schreibgeschützt markiert; bearbeitet wird nur die Quelle.

Führe das Synchronisierungsskript über einen Pre-Commit-Hook oder eine GitHub Action aus. Werden Änderungen direkt an CLAUDE.md vorgenommen, schlägt CI fehl. So wird verhindert, dass sich die Regeln zwischen den Tools auseinanderentwickeln.

Eine weitere Möglichkeit ist das offizielle Codex Plugin für Claude Code (angekündigt am 30. März 2026, Version 1.0.4). Es fügt Claude Code die Befehle /codex:review, /codex:adversarial-review und /codex:rescue hinzu. Codex läuft als Sub-Agent mit seiner eigenen ~/.codex/config.toml und AGENTS.md. Dadurch entfällt ein zweites Terminal, AGENTS.md bleibt jedoch erforderlich.

Was kostet es, beide zu behalten, und wo liegen die Einsparungen?#

Hier sind die Zahlen für Juni 2026 (Daten von den offiziellen Abo-Seiten von Anthropic und OpenAI und der offiziellen Codex-Seite):

Günstigste funktionierende Kombination: Claude Pro ($20) + ChatGPT Plus ($20) = $40/Monat. Ausreichend für Solo-Projekte mit ein paar Sitzungen am Tag.

Eine passende Kombination für aktive Vibe-Coder: Claude Max 5x ($100) + ChatGPT Plus ($20) = $120/Monat. Im beschriebenen Erfahrungsbericht wurde diese Kombination während der letzten 2 Monate genutzt: In dieser Zeit gingen drei Projekte live, und die Claude-Limits wurden nie erreicht.

Eine Kombination für ein Team: Claude Max 20x ($200) + Codex Pro ($200) = $400/Monat. Das ergibt Sinn, wenn regelmäßig PR-Prüfungen und Cloud-Aufgaben parallel zur lokalen Arbeit anfallen.

Wo die Einsparungen herkommen:

• Weniger Zeit pro Feature. Die Messung des Autors: Bei 12 Features im Mai-Juni sank die Zeit von „eine Idee kam auf“ bis „in Produktion“ von 4 Stunden (mit Claude Code allein) auf 2.5 Stunden (mit der Kombination). Gemessen an den Aufgaben des Autors; bei dir können andere Zahlen herauskommen.
• Weniger Fehler. Den beschriebenen Beobachtungen zufolge finden Codex-PR-Prüfungen 2-3 von 10 Problemen, die Claude übersieht. Jedes solche Produktionsproblem bedeutet ein oder zwei Stunden für die Behebung sowie mögliche Ausfallzeit.
• Parallelität. Codex arbeitet im Cloud-Modus an Feature A, während der Nutzer mit Claude an Feature B arbeitet. Dadurch verdoppelt sich der Durchsatz.

Es lohnt sich nicht, wenn du 1-2 Features pro Woche schreibst. In diesem Fall reicht Claude Code Pro allein.

Wann brauchst du kein zweites Tool?#

Die Kombination ist nicht für jeden gedacht. Oft sorgt sie nur für zusätzliches Rauschen. Hier sind vier Situationen, in denen du kein zweites Tool brauchst:

1. Solo-Projekt am Anfang. Hast du eine Idee und testest sie gerade erst, reicht Claude Code mit Plan Mode einen Monat lang aus. Ergänze die Kombination, wenn du an eine Geschwindigkeitsgrenze stößt.

2. Striktes Budget. Wenn $20/Monat die Obergrenze sind, nimm Claude Pro und mach dir keine Gedanken darum. Claude allein deckt 80% der Aufgaben eines Vibe-Coders ab.

3. Einfache Architektur. Eine Website mit einem Formular, ein Bot mit ein paar Szenarien, ein Skript als API-Wrapper—eine Aufteilung nach Ebenen bringt hier nichts. Claude Code allein kommt damit zurecht.

4. Alles funktioniert bereits. Wenn du Claude Code schon verwendest und es im letzten Monat bei keiner einzigen Aufgabe festhing oder scheiterte, ändere nichts, was funktioniert. Ergänze Codex, wenn der Bedarf offensichtlich wird.

Und umgekehrt—klare Anzeichen dafür, dass es Zeit für ein zweites Tool ist:

• Claude Code ist zum Engpass geworden: Du wartest darauf, statt zu arbeiten.
• Es gibt viel Routinearbeit an der Infrastruktur (Migrationen, CI, Tests), die du ungern mit Claude erledigst.
• Verschiedene Personen im Team verwenden bereits unterschiedliche Tools—eine gemeinsame Sprache ist erforderlich.
• Benchmarks zeigen, dass Codex deine Art von Aufgaben schneller erledigt (zum Beispiel Terminaloperationen).

So richtest du die Kombination an einem Abend ein#

Ein konkreter Plan für deinen ersten Abend:

1. Schritt 1: Installiere Codex CLI

   Gib im Terminal npm install -g @openai/codex ein. Melde dich mit codex login an—ein Browser öffnet sich und du meldest dich mit deinem ChatGPT-Konto an. Codex erkennt dein Abo (Plus / Pro) und nutzt dessen Limits.

2. Schritt 2: Verfasse AGENTS.md als Betriebsdokument

   Prüfe CLAUDE.md und übernimm für beide Tools geltende Regeln in AGENTS.md: Test- und Lintbefehle, Commit-Format, verbotene Ordner und Stackbeschreibung. Auch Gesprächspräferenzen dürfen gemeinsam sein. Passe toolspezifische Befehlsverweise an und halte ausführbare Hook- und MCP-Einstellungen in der jeweiligen Toolkonfiguration. Kopiertes Markdown allein richtet sie nicht ein.

3. Schritt 3: Wähle ein Muster für dein Projekt

   Wenn du allein mit CI programmierst, nutze Muster 1 (Claude schreibt, Codex überprüft). Ist es ein neues Projekt und brauchst du Tempo, nutze Muster 2 (Codex entwirft, Claude räumt auf). Ist es ein etabliertes Projekt mit Infrastrukturebene, nutze Muster 3 (Aufteilung nach Ebenen).

4. Schritt 4: Experimentiere eine Woche lang

   Arbeite bei 5-7 Features mit dem gewählten Muster. Miss die Zeit. Halte fest, welches Tool die einzelnen Aufgaben besser erledigt hat. Nach einer Woche hast du ein realistisches Bild deiner Nutzung.

5. Schritt 5: Richte die Regelsynchronisierung ein

   Füge ein Skript scripts/sync-agent-rules.sh hinzu (siehe Abschnitt zur Synchronisierung). Binde es als Pre-Commit-Hook oder über eine GitHub Action ein. Danach werden die Regeln automatisch auf beide Dateien übertragen.

Die Kombination ist keine Magie. Es sind einfach zwei Köpfe statt eines, die jeweils die Schwachstellen des anderen ausgleichen. Entscheidend ist, nicht bei der Frage „Claude oder Codex“ hängen zu bleiben, wenn die richtige Antwort längst „Claude und Codex—für unterschiedliche Aufgaben“ lautet.

Praktische Materialien zur Arbeit mit Agenten: Ailoot-Dokumentation.

Weitere Materialien und Tools: Ailoot.