Claude Code und Codex im Selben Repo: Mein Praxis-Setup

Claude Code und Codex im Selben Repo: Mein Praxis-Setup

Ich war schon immer ein Claude Code-Loyalist. Nicht auf eine tribale Art — eher auf eine "das ist der Agent, dem ich vertraue, den ich optimiert habe, bei dem das Muskelgedächtnis aufgebaut ist" Art. Anthropic veröffentlichte ein Update, ich installierte es. Anthropic hatte einen Ausfall, ich wartete. Der Gedanke, eine zweite CLI parallel zu betreiben, fühlte sich an wie Fremdgehen an einem Tool, das sich meinen Workflow verdient hatte.

Dann ging letzten Monat, an einem Mittwochnachmittag, Claudes API-Statusseite auf Orange. Dann Rot. Aria — mein Content-Agent — war mitten in einem Vier-Post-Batch. Ich saß 47 Minuten da und beobachtete den Spinner. Als die API zurückkam, hatte ich den Vormittag verloren und die Geduld, weiter ein Ein-CLI-Entwickler zu sein.

Also tat ich das, was ich vermieden hatte. Ich öffnete ein zweites Terminal-Panel, führte codex im selben Repo aus und begann mir beizubringen, wie man tatsächlich in beiden Ökosystemen gleichzeitig lebt. Nicht die Marketing-Version, in der man die beiden Tools "vergleicht" und einen Gewinner wählt. Die langweilige, detaillierte Version, in der man beide betreibt, auf derselben Codebase, mit demselben Projektkontext, mit Skills, die in beiden CLIs größtenteils funktionieren, und einem Session-Übergabe-Trick, mit dem man Arbeit zwischen ihnen weiterreichen kann, wenn einer von ihnen steckenbleibt.

Das ist dieser Beitrag. Nicht "Claude Code vs Codex." Es ist "Claude Code und Codex, im selben Projektordner, mit einem geteilten Gehirn und einem Übergabe-Skill, der Ausfälle übersteht." Ich betreibe dieses Setup seit etwa sechs Wochen. Die ersten drei Wochen waren holprig. Die letzten drei waren die widerstandsfähigste Entwicklungsumgebung, die ich je hatte.

Lass mich dir zeigen, wie es genau verdrahtet ist.

Warum Ich Aufgehört Habe, Zwischen Claude Code und Codex zu Wählen

Vor dem Setup, ein kurzes Wort zum Mindset-Wechsel — denn die Verdrahtung ist nur wichtig, wenn die Philosophie darunter stimmt.

Für den Großteil von 2025 war die CLI-Agent-Diskussion tribal. Man war ein Claude Code-Mensch, oder ein Codex-Mensch, oder ein Cursor-Mensch, oder ein Gemini CLI-Mensch. Die Gründe waren real: Jedes Tool hatte andere Ergonomie, anderes Modellverhalten, andere Konfigurationsdateien, und das Wechseln kostete echte Zeit. Eines zu wählen und tief einzusteigen war sinnvoll.

Zwei Dinge änderten sich für mich 2026.

Das erste waren Ausfälle. Nicht speziell Anthropics Schuld — jeder große Modellanbieter hatte dieses Jahr mindestens einen harten Tag. OpenAI hatte einen mehrstündigen Vorfall im Februar. Anthropic hatte den API-Stotter, den ich oben erwähnte. Googles Gemini-Seite hatte einen Model-Routing-Bug im März, der leise die Antworten stundenlang verschlechterte, bevor es jemand bemerkte. Wenn dein gesamter Workflow hinter einem Anbieter liegt, kostet ein Ausfall deinen ganzen Tag. Das ist kein Technologieproblem — das ist ein Single-Point-of-Failure-Problem.

Das zweite war die Sackgasse. Manchmal steckt Claude Code fest. Nicht "kaputt" fest — kreativ fest. Es wählt einen Ansatz, verfolgt ihn, und wenn dieser Ansatz nicht funktioniert, verfeinert es denselben Ansatz härter. Ich habe Opus 40 Minuten dabei zugesehen, wie es versuchte, einen instabilen Test durch Hinzufügen von Wiederholungen zuverlässig zu machen, während die eigentliche Lösung war, den Test in einem anderen Stil umzuschreiben. Ein zweiter Agent — nicht als Ersatz, sondern als zweite Meinung — durchbricht die Sackgasse normalerweise in einem Prompt. CLIs zu wechseln ist der günstigste Weg, den ich gefunden habe, um eine frische Modellperspektive zu bekommen, ohne Projektkontext zu verlieren.

Also ist das Ziel nicht "wähle die beste CLI." Das Ziel ist Tool-Agnostizismus: Baue ein Setup, in dem Claude Code und Codex beide an derselben Codebase arbeiten können, mit demselben Projektwissen, und du zwischen ihnen wechseln kannst, ohne deinen Platz zu verlieren. Die CLI wird austauschbar. Der Projektkontext ist das Heilige. Das ist derselbe Instinkt, über den ich in meinem Zwei-Agent Supervisor-Builder-Workflow geschrieben habe, nur weitergeführt: nicht nur zwei Agents, sondern zwei ganze CLIs als austauschbar behandelt.

Jetzt zur Verdrahtung.

Das Geteilte Gehirn: CLAUDE.md und AGENTS.md Enthalten (Fast) Dasselbe

Das erste, was ich lernte, als ich ernsthaft begann, beide Agents im selben Repo zu betreiben, ist dies: Die zwei Ökosysteme stimmen bereits mehr überein, als das Marketing impliziert. Sowohl Claude Code als auch Codex lesen beim Start eine Markdown-Datei auf Projektebene. Claude Code liest CLAUDE.md. Codex liest AGENTS.md. Die Inhalte sind fast austauschbar. Das Format ist einfaches Markdown. Die Absicht ist dieselbe: Sage dem Agent, was dieses Projekt ist, was die Konventionen sind, welche Tools zu verwenden sind, welche Tests auszuführen sind, und was nicht angefasst werden soll.

Als ich den parallelen Workflow zum ersten Mal einrichtete, machte ich den Anfängerfehler, zwei separate Dateien zu schreiben und sie von Hand synchron zu halten. Das hielt etwa vier Tage, bevor die Drift die Agents dazu brachte, sich über Grundlegendes zu streiten — Codex dachte, wir verwenden pnpm, Claude Code dachte, wir verwenden npm, und ein Münzwurf entschied, welcher zu einem bestimmten Zeitpunkt Recht hatte.

Die Lösung ist eines von zwei Mustern, und beide funktionieren:

Muster A — Symlinke eines auf das andere. Wähle die Datei, die du als Quelle der Wahrheit willst (ich wählte AGENTS.md, weil es zum Cross-Vendor-Standard wird), und symlinke die andere darauf:

# vom Projektstamm aus, mit AGENTS.md als kanonisch
mv CLAUDE.md AGENTS.md   # wenn du von CLAUDE.md aus startest
ln -s AGENTS.md CLAUDE.md

Jetzt lesen beide Agents dieselbe Datei. Bearbeite AGENTS.md, beide CLIs sehen das Update beim nächsten Start. Dies empfiehlt der Onur Solmaz Migrationsguide und das betreibe ich in den meisten meiner Repos.

Muster B — Halte sie getrennt, aber erzwinge Synchronisation. Wenn du willst, dass jede Datei ein paar tool-spezifische Zeilen hat (manche Skills verhalten sich unterschiedlich in der einen vs. der anderen), behalte beide Dateien und schreibe einen Pre-Commit-Hook, der den gemeinsamen Abschnitt vergleicht und warnt, wenn sie auseinander gedriftet sind. Das ist aufwändiger, aber es erlaubt dir, einen # Claude Code-spezifisch-Block am Ende der einen zu haben und nicht der anderen.

Ich begann mit Muster B und migrierte alles innerhalb von zwei Wochen zu Muster A. Die Wartungskosten für die Synchronhaltung zweier Dateien waren höher als der Wert einiger tool-spezifischer Zeilen.

Welches Muster du auch wählst, hier ist, was tatsächlich in dieser geteilten Datei stehen sollte. Dies ist der Abschnitt meiner echten AGENTS.md für das Repo, in dem ich all diesen Content schreibe:

# Projekt: my-ai-crew

## Was das ist
Multi-Marken Content-Generierungssystem. Vier Marken, jede mit einer
eigenen Stimme. Beiträge werden in content/{marke}/[slug].md gespeichert.
Kein Build-System, keine Tests — der Workflow ist Agent-gesteuert.

## Konventionen
- Alle Artikeldateien beginnen mit `**BRAND:**` — niemals YAML Frontmatter.
- META DESCRIPTION muss 150-160 Zeichen lang sein. Vor dem Speichern zählen.
- Mindestwortzahl: 3.000.
- Markenstimmen sind definiert in .claude/agents/aria.md (nicht bearbeiten
  ohne explizite Anweisung).

## Verfügbare Tools
- WebSearch — für Faktenverifizierung verwenden, niemals Versionen/Preise raten
- Glob — content/{marke}/*.md vor dem Schreiben scannen
- Read, Write, Edit — Standard-Dateioperationen

## Was NICHT zu tun
- Keinen git commit ausführen, es sei denn, explizit gebeten.
- Keine Co-Authored-By-Zeilen hinzufügen ohne Anweisung.
- Keine Platzhalter-Metriken generieren — echte Zahlen verwenden oder weglassen.

## Markenverzeichnisse
- content/mejba.me/ — persönliche Praktikerstimme
- content/ramlit.com/ — Agentur, geschäftsorientiert
- content/colorpark.io/ — Designagentur, meinungsstark
- content/xcybersecurity.io/ — Sicherheit, autoritativ

Beide CLIs lesen dies. Beide Agents kennen jetzt die Konventionen. Das erste Mal, wenn du diese Datei richtig schreibst, ist das erste Mal, dass dein Zwei-CLI-Setup tatsächlich kohärent statt schizophren wirkt.

Es gibt eine Feinheit, die erwähnenswert ist. Claude Code unterstützt verschachtelte CLAUDE.md-Dateien in Unterverzeichnissen — wenn der Agent eine Datei in content/colorpark.io/ liest, kann er zusätzliche Anweisungen aus einer CLAUDE.md aufnehmen, die in diesem Unterordner platziert ist. Codex hat einen ähnlichen Mechanismus: Wenn du in ein Unterverzeichnis cd'st, verkettet es die AGENTS.md-Dateien vom aktuellen Ordner bis zum Repo-Stamm, wobei nähere Dateien frühere überschreiben (dies ist im Codex AGENTS.md-Guide dokumentiert). Wenn du auf Root-Ebene symlinkst, kannst du auch auf Unterordner-Ebene symlinken. Beide Ökosysteme spielen gut zusammen.

Die Datei- und Ordnerübersicht: Wo Jede CLI Nachschaut

Sobald das geteilte Gehirn verdrahtet ist, ist die nächste Frage: Wo lebt alles andere? Skills, Agents, Konfiguration, Slash-Befehle. Beide CLIs haben ihre eigene Ordnerstruktur, und du brauchst eine mentale Karte.

Hier ist die, die ich in meinen eigenen Notizen angepinnt halte:

Ein paar Anmerkungen zu dieser Tabelle, weil sie mich beim ersten Mal stolpern ließen:

Das Konfigurationsformat ist die größte Formatlücke. Claude Code verwendet JSON für settings.json. Codex verwendet TOML für config.toml. Wenn du noch nie TOML geschrieben hast, es ist halb zwischen YAML und INI — Schlüssel, Werte, Abschnitte in eckigen Klammern. Nicht schwer, aber du kannst deine settings.json nicht in config.toml einfügen und erwarten, dass es funktioniert. Die Konvertierung ist mechanisch, aber manuell. (Oder, wie ich gleich zeige, lässt du Claude Code das für dich erledigen.)

Slash-Befehle und Skills konvergieren in Codex. OpenAIs offizielle Dokumentation sagt jetzt, dass Custom Prompts zugunsten von Skills veraltet sind. In 2026 also, wenn du wiederverwendbare Anweisungen für Codex schreibst, schreibst du sie als Skills, nicht als Custom Prompts. Claude Code unterscheidet weiterhin zwischen Befehlen (in .claude/commands/) und Skills (in .claude/skills/), aber die Lücke schließt sich. Beide Ökosysteme landen bei "ein Skill ist eine Markdown-Datei mit Frontmatter, die beschreibt, wann er feuern soll." Gute Nachrichten für die Portabilität.

Sub-Agents weichen stärker ab, als man erwarten würde. Claude Codes Sub-Agents dispatchen automatisch — der Haupt-Agent liest die Beschreibungen jeder .claude/agents/*.md-Datei beim Start und routet Arbeit dorthin, wenn eine Aufgabe passt. Codex erfordert explizite Aufrufe. Du kannst Agents in .codex/agents/ erstellen, aber Codex routet nicht automatisch zu ihnen; du sagst Codex, welchen Agent er verwenden soll. Ich komme auf diesen Unterschied zurück, weil er am meisten verändert, wie du arbeitest.

Skills Sind Größtenteils Portierbar. Agents Brauchen eine Konvertierung.

Der Grund, warum dieses ganze Setup funktioniert, ist, dass die meisten Markdown-Dateien in .claude/ und .codex/ strukturell gleich sind. Ein Skill ist ein Ordner mit einer SKILL.md darin. Die SKILL.md hat YAML-Frontmatter mit name und description, dann einen Markdown-Body mit Anweisungen. Diese Spezifikation ist auf beiden Seiten gleich. Was bedeutet, dass ein Skill, den ich für Claude Code geschrieben habe, meistens ohne Änderungen in Codex funktioniert.

Ich habe das direkt getestet. Mein caveman-Skill — der ultrakomprimierte Kommunikationsmodus, der den Token-Verbrauch um ~75% reduziert (ich habe früher über das Erstellen des Caveman-Skills für Claude Code geschrieben) — wurde ursprünglich für Claude Code geschrieben. Ich kopierte den caveman/-Ordner von .claude/skills/ nach .codex/skills/, startete Codex neu, und der Skill feuerte beim ersten Prompt korrekt. Keine Formatänderungen. Keine Frontmatter-Umschreibungen. Es funktionierte einfach.

Die Skills, die nicht sauber portiert werden, sind diejenigen, die auf Claude-Code-spezifische Tool-Namen verweisen. Wenn dein Skill "verwende das Glob-Tool" sagt — Codex hat kein Tool namens Glob. Es hat Shell-Zugang, also kann der Agent immer noch Dateien globben über find oder ls, aber du musst den Skill entweder umschreiben, um auf Shell-Operationen zu verweisen, oder akzeptieren, dass der Skill weniger zuverlässig funktioniert. Etwa 80% der Skills, die ich migriert habe, brauchten keine Änderungen. Die anderen 20% brauchten leichte Bearbeitungen an Tool-Verweisen.

Sub-Agents sind der Punkt, an dem die Konvertierung ernst wird. Das Frontmatter ist ähnlich (name, description, model, tools), aber das Dispatch-Modell ist anders — und das verändert, wie du den Body des Agents schreibst. Ein Claude Code-Agent wird in der Annahme geschrieben, dass er automatisch aufgerufen wird, wenn eine Aufgabe zu seiner Beschreibung passt. Ein Codex-Agent wird in der Annahme geschrieben, dass du ihn explizit aufrufst. Also:

• Claude Code-Agentbeschreibungen werden für das dispatchende Modell zum Lesen geschrieben. Sie sagen "verwende diesen Agent, wenn X benötigt wird", weil der Haupt-Agent wissen muss, wann er delegieren soll.
• Codex-Agentbeschreibungen werden für den menschlichen Benutzer zum Lesen geschrieben. Sie sagen "dieser Agent behandelt X", weil der Mensch derjenige ist, der Arbeit routet.

Wenn du einen Agent von einem zum anderen migrierst, kopierst du nicht einfach die Datei. Du schreibst die Beschreibung aus der richtigen Perspektive um. Der Body — der eigentliche System-Prompt — überträgt sich normalerweise ohne Änderungen.

Das ist der größte praktische Unterschied zwischen den beiden Ökosystemen, und es ist der Grund, warum ich beide nebeneinander betreibe, anstatt sie als Drop-in-Ersatz zu behandeln. Claude Code ist besser in Multi-Agent-Orchestrierung, weil das Dispatching automatisch ist — ich habe die Dispatch-Mechanik im Detail in meinem Claude Code Agent Teams Playbook behandelt. Codex ist besser in kontrolliertem, deterministischem Agent-Einsatz, weil du entscheidest, welcher Agent läuft. Verschiedene Stärken, dieselben Bausteine.

Der Konvertierungs-Prompt, Den Ich in Claude Code Einfüge, um Codex zu Bootstrappen

Wenn ich ein neues Repo starte und beide CLIs von Tag eins an bereit haben will, konvertiere ich nichts manuell. Ich schreibe zuerst das Claude Code-Setup (weil das das Muskelgedächtnis ist) und dann füge ich diesen Prompt in Claude Code ein und lasse es das Codex-Äquivalent generieren.

Das ist der tatsächliche Prompt. Kopiere ihn, füge ihn in Claude Code ein, und er erledigt die Konvertierung für dich:

Ich möchte, dass dieses Repo in sowohl Claude Code als auch Codex CLI
nebeneinander funktioniert. Im Moment ist das Claude Code-Setup komplett.
Ich brauche dich, um das parallele Codex-Setup zu generieren. Konkret:

1. Lies CLAUDE.md und erstelle AGENTS.md mit demselben Inhalt, ersetze
   dann CLAUDE.md durch einen Symlink auf AGENTS.md. Verwende:
     mv CLAUDE.md CLAUDE.md.bak
     # kopiere CLAUDE.md.bak Inhalte in AGENTS.md
     ln -s AGENTS.md CLAUDE.md
     rm CLAUDE.md.bak  (erst nach Überprüfung, dass der Symlink funktioniert)

2. Lies .claude/settings.json und erstelle .codex/config.toml, das die
   relevanten Einstellungen spiegelt. Konvertiere JSON-Syntax zu TOML.
   Überspringe Claude-Code-spezifische Schlüssel, die kein Codex-Äquivalent
   haben (z.B. permissions, hooks) und füge einen Kommentar hinzu, der
   auflistet, was übersprungen wurde.

3. Kopiere für jede Datei in .claude/skills/<name>/SKILL.md nach
   .codex/skills/<name>/SKILL.md. Überprüfe den Body auf Verweise
   auf Claude-Code-spezifische Tools (Glob, Read Tool, etc) und schreibe
   sie entweder als Shell-Äquivalente um oder markiere sie in einem
   Kommentar oben in der Datei.

4. Portiere NICHT automatisch für jede Datei in .claude/agents/<name>.md
   nach .codex/agents/. Liste stattdessen die Agents auf und frage mich,
   welche ich in Codex verfügbar haben möchte. Für die ausgewählten
   schreibe das description-Feld so um, dass es für menschliches Routing
   geeignet ist (Codex erfordert expliziten Aufruf, kein Auto-Dispatch)
   und kopiere den Body unverändert.

5. Schreibe nach allen Konvertierungen eine CONVERSION_LOG.md im
   Repo-Stamm, die jede erstellte oder geänderte Datei auflistet, jeden
   übersprungenen Schlüssel und jeden umgeschriebenen Tool-Verweis. Ich
   möchte das in 30 Sekunden auditieren können.

Committe nichts. Erstelle nur die Dateien und das Log.

Das erste Mal, als ich das ausführte, brauchte Claude Code etwa vier Minuten. Das meiste davon war der Agent, der jeden Skill las und entschied, ob jeder Claude-Code-spezifische Tool-Verweise hatte. Das Konvertierungslog war nützlich, weil es zwei Skills auffing, die das Glob-Tool namentlich referenzierten — ich schrieb diese um, um Shell find zu verwenden, und jetzt funktionieren beide Versionen des Skills in ihren jeweiligen CLIs ohne weitere Änderungen.

Du kannst auch die umgekehrte Konvertierung durchführen, von einem Codex-Setup zu einem Claude Code-Setup. Der Prompt ist symmetrisch — tausche einfach Quelle und Ziel. Normalerweise habe ich eine Konvertierungsrichtung als die kanonische Setup-Pipeline und die andere als einmaliges Bootstrapping.

Der Session-Übergabe-Skill: Kontext Zwischen Agents Verschieben

Hier ist das Stück, über das niemand spricht: Selbst mit einer geteilten AGENTS.md teilen die Agents selbst keinen Gesprächszustand. Wenn du mitten in einer Aufgabe von Claude Code zu Codex wechselst, weiß der neue Agent nicht, was du gerade gemacht hast. Er kennt die Projektkonventionen, aber nicht die aktive Absicht.

Das ist der Moment, in dem die meisten Leute das parallele CLI-Setup aufgeben. Sie probieren es einen Tag, stoßen an eine Kontextwand beim Tool-Wechsel und schließen, dass beide zu betreiben "mehr Aufwand ist, als es wert ist." Das stimmt nicht — aber nur, wenn du eine bewusste Übergabe hast.

Ich habe einen Skill gebaut, der das löst. Er erfasst die vier Dinge, die beim Übergeben von Arbeit zwischen Agents wirklich wichtig sind: die aktiven Dateien, an denen du gearbeitet hast, die aktuelle Absicht (was du versuchst zu tun), die Blocker (was feststeckt oder gescheitert ist), und den nächsten Schritt (was der empfangende Agent als Erstes tun soll). Er schreibt diese vier Felder in eine .handoff.md-Datei im Repo-Stamm. Der empfangende Agent liest diese Datei beim nächsten Prompt und weiß genau, wo er weitermachen soll.

Das ist der tatsächliche Skill, der sich unter .claude/skills/session-handoff/SKILL.md befindet:

---
name: session-handoff
description: Erfasse den aktiven Sitzungszustand in .handoff.md, damit ein anderer CLI-Agent (Codex, Gemini, etc.) die Arbeit übernehmen kann. Verwende, wenn der Benutzer "Übergabe", "weiter an Codex", "Agents wechseln" oder "Kontext für nächsten Agent" sagt.
allowed-tools: Read, Write, Bash
---

# Session-Übergabe

Wenn dieser Skill feuert, schreibe `.handoff.md` im Repo-Stamm mit diesen
exakten vier Abschnitten. Sei knapp. Der empfangende Agent liest dies und
muss sofort darauf reagieren.

## Format

```markdown
# Session-Übergabe — [ISO-Zeitstempel]
Von: [claude-code | codex | andere]

## Aktive Dateien
- [pfad/zur/datei:zeilenbereich] — [einzeilige Begründung]
- [pfad/zur/datei] — [einzeilige Begründung]

## Aktuelle Absicht
[1-3 Sätze: was wir in dieser Arbeitssession zu erreichen versuchen]

## Blocker
- [Konkretes Ding, das feststeckt. Fehlermeldung einschließen, falls vorhanden.]
- [Oder "keine", wenn nicht feststeckt — wechseln nur für frische Perspektive.]

## Nächster Schritt
[Genau ein Satz. Die einzelne Aktion, die der empfangende Agent als
Erstes ausführen sollte.]

Regeln

• KEINE vollständigen Dateiinhalte einschließen. Nur Pfade und Zeilenbereiche.
• Das Gespräch NICHT zusammenfassen. Zustand erfassen, nicht Geschichte.
• Wenn .handoff.md bereits existiert, überschreiben (nicht anhängen).
• Nach dem Schreiben "Übergabe geschrieben nach .handoff.md" ausgeben und beenden.
• Dem empfangenden Agent sollte (vom Menschen) gesagt werden, .handoff.md als erste Aktion zu lesen.

Der Spiegel-Skill in `.codex/skills/session-handoff/SKILL.md` ist identisch, bis auf eine Änderung — die Beschreibung ist umgeschrieben, weil Codex nicht automatisch dispatcht. Die Beschreibung der Codex-Version liest sich eher wie ein Nutzungshinweis als ein Routing-Signal. Hier ist der Unterschied in einfacher Sprache: Claude Codes Beschreibung sagt "feuere dies, wenn der Benutzer X sagt." Codex' Beschreibung sagt "verwende diesen Skill, um eine Übergabedatei zu schreiben."

Um eine Übergabe in Claude Code auszulösen, tippe ich einfach "Übergabe an Codex" — der Skill erkennt das Schlüsselwort und schreibt die Datei. Um sie in Codex auszulösen, tippe ich `$session-handoff` (Codex' explizite Aufrufsyntax) und es tut dasselbe. Dann wechsle ich den Tab, und das Erste, was ich dem empfangenden Agent sage, ist: "Lies .handoff.md und mach weiter."

Die Übergabedatei hat normalerweise 15 bis 30 Zeilen. Der empfangende Agent liest sie, hat in fünf Sekunden vollen Kontext und beginnt zu arbeiten. Ich habe diesen Skill wahrscheinlich 200 Mal in den letzten sechs Wochen verwendet. Es ist das einzige Stück Kleber, das das parallele CLI-Setup kohärent statt fragmentiert wirken lässt.

Wenn du nur eine Sache aus diesem ganzen Beitrag baust, baue diesen Skill. Er ist klein. Er spart Stunden. Wenn du noch nie einen Claude Code-Skill von Grund auf gebaut hast, führt mein [Guide für fortgeschrittene Claude Code-Skills](https://www.mejba.me/blog/agent-skills-advanced-claude-code) durch das Format und die Fallstricke.

## Wie das Nebeneinander-Setup Tatsächlich Aussieht: VS Code Split-Panel

Die Verdrahtung oben ist das statische Setup. Hier ist die Dynamik — wie mein Bildschirm während einer Arbeitssession tatsächlich aussieht.

VS Code, geteiltes Terminal-Panel, vertikale Ausrichtung. Linkes Panel: Claude Code, läuft mit Opus 4.7, im Projektstamm. Rechtes Panel: Codex CLI, läuft mit GPT-5.4, derselbe Projektstamm. Beide Agents haben dieselbe `AGENTS.md`. Beide haben Zugang zu denselben Skills. Beide können dieselben Dateien bearbeiten (sie koordinieren über das Dateisystem, nicht über Cross-CLI-Nachrichten — Git ist die Quelle der Wahrheit für den Festplattenzustand).

Ich starte standardmäßig mit Claude Code für den Beginn jeder Session. Das ist der Agent, den ich am meisten optimiert habe, und er hat meinen vollständigen Satz von `.claude/agents/`-Sub-Agents verfügbar. Ich plane, ich scaffolde, ich mache die ersten 60% der Änderungen dort.

Ich wechsle zu Codex in bestimmten Szenarien:

**Claude Code steckt in einem Ansatz fest.** Vierzig Minuten drin, es dreht sich um dieselbe Idee. Ich führe den Übergabe-Skill aus, wechsle zu Codex und bitte es, dasselbe Problem mit frischem Blick zu betrachten. Etwa 70% der Zeit wählt Codex einen anderen Ansatz und entsperrt die Arbeit. Die verbleibenden 30% stimmt es Claude Codes Ansatz zu, schlägt aber eine spezifische Anpassung vor, die ihn zum Funktionieren bringt. So oder so, die Sackgasse bricht auf.

**Lange, mechanische Refactoring-Arbeit.** Die Terminal-Bench-Leistung von Codex CLI ist bei routinemäßigen shell-lastigen Aufgaben genuinerweise stärker als die von Claude Code, laut dem [DeployHQ 2026-Vergleich](https://www.deployhq.com/blog/comparing-claude-code-openai-codex-and-google-gemini-cli-which-ai-coding-assistant-is-right-for-your-deployment-workflow) (Codex CLI erreichte 77,3% auf Terminal-Bench 2.0 vs. Claude Codes 65,4%). Wenn die Aufgabe ist "benenne 30 Variablen über 12 Dateien nach diesem Muster um" oder "führe die Testsuite aus, parse die Fehler, schreibe Fixes," ist Codex schneller und verbraucht weniger Token.

**Claude API ist down.** Das ist der ursprüngliche Grund, warum ich das parallele Setup gebaut habe. Wenn Anthropic einen Vorfall hat, wechsle ich vollständig zum Codex-Panel und arbeite weiter. Die Skills übertragen sich. Der Projektkontext überträgt sich. Das Einzige, was ich verliere, ist der Aria-Agent (weil Aria Claude-Code-spezifisches Sub-Agent-Verhalten hat, das sich nicht vollständig übersetzt), und ich habe Aria ohnehin nicht für die Arbeit verwendet, zu der ich zu Codex wechsle.

**Adversariale Review.** Wenn ich eine Code-Review will, die *nicht* vom selben Modell kommt, das den Code geschrieben hat, erledige ich die Arbeit in Claude Code und bitte dann Codex, den Diff zu reviewen. Andere Modelllinie, andere Trainingsdaten, andere blinde Flecken. Ich fange so Bugs, die keiner der beiden Agents findet, wenn er seine eigene Arbeit reviewt. Ich habe ausführlich über dieses Muster im [Codex Plugin Adversarial Review Beitrag](https://www.mejba.me/blog/codex-plugin-claude-code-adversarial-review) geschrieben — dieselbe Idee, engere Integration, wenn du sie willst.

Das Muster, das nach ein paar Wochen entstand: Claude Code ist mein Primärer, Codex ist mein Paralleler. Ich bin 70-80% der Zeit in Claude Code. Codex ist 20-30%, plus 100%, wenn Claude down ist.

## Die Zwei Setups Synchron Halten (Die Disziplin)

Das ganze System bricht, wenn die zwei Setups auseinander driften. Der häufigste Fehlermodus, den ich sehe — auch in meinem eigenen Setup, wenn ich faul werde — ist, dass du `CLAUDE.md` bearbeitest (was jetzt der Symlink ist) und versehentlich Änderungen schreibst, die nur Claude Code versteht. Oder du fügst einen neuen Skill zu `.claude/skills/` hinzu und vergisst, ihn in `.codex/skills/` zu spiegeln. Zwei Wochen später wechselst du CLIs und entdeckst, dass die Hälfte deiner Tooling fehlt.

Die Disziplin, die tatsächlich für mich funktioniert, nach einigen Iterationen:

**Bearbeitungen an der kanonischen Datei werden standardmäßig als "tool-agnostisch" betrachtet.** Wenn ich etwas in `AGENTS.md` schreibe, das nur eine CLI wissen sollte, setze ich es in einen klar markierten Abschnitt am Ende: `# Nur Claude Code` und `# Nur Codex` Blöcke. Beide CLIs lesen die gesamte Datei, aber die Abschnittsüberschriften sagen mir (dem Menschen), welche Zeilen wo gelten. Reduziert die Wartungsarbeit erheblich.

**Skill-Änderungen gehen durch ein Sync-Skript.** Ich habe ein kleines Shell-Skript, das neue oder geänderte Dateien von `.claude/skills/` nach `.codex/skills/` kopiert (und umgekehrt), wobei Tool-Name-Überschreibungen, die ich bereits gemacht habe, erhalten bleiben. Ich führe es manuell nach dem Bearbeiten eines Skills aus, vor der nächsten Session. Fünf Sekunden Arbeit, verhindert die schleichende Drift.

**Sub-Agent-Änderungen synchronisieren nicht automatisch.** Ich lasse Agents in `.claude/agents/` für die Claude Code-Nutzung und portiere nur die manuell, die ich aktiv in Codex haben will. Die meisten meiner Agents sind nur für Claude Code, weil das automatische Dispatch-Verhalten der ganze Sinn ist. Die zwei oder drei, die ich zu Codex portiere, halte ich manuell synchron, weil die Beschreibungen ohnehin anders sein müssen.

**Konfigurationsdateien (`settings.json` und `config.toml`) werden nie automatisch synchronisiert.** Sie driften natürlich, weil sie verschiedene Einstellungen freilegen. Ich behandle sie als unabhängig und überprüfe sie einmal im Monat, um sicherzustellen, dass ich kein unbeabsichtigtes Verhaltensunterschied eingeführt habe.

Das ist der operative Overhead, ehrlich gesagt. Etwa zehn Minuten pro Woche an expliziter Synchronisierungsarbeit. Im Gegenzug bekomme ich zwei CLIs, die beide mein Projekt kennen und beide austauschbar daran arbeiten können.

## Wann das Nebeneinander-Setup Es Nicht Wert Ist

Ich würde lügen, wenn ich sagte, dieses Setup sei für jeden richtig.

Wenn du neu bei Claude Code bist, mach das noch nicht. Optimiere zuerst Claude Code. Bringe deine `CLAUDE.md` in Ordnung, baue eine Handvoll Skills, gewöhne dich daran, wie Sub-Agents funktionieren. Codex am ersten Tag hinzuzufügen bedeutet, dass du zwei CLIs gleichzeitig lernst, und du wirst verwirrt darüber, welches Verhalten von welchem Tool kommt. Wähle eines, gehe tief, füge dann das andere hinzu.

Wenn deine Arbeit hauptsächlich innerhalb der Tooling eines Ökosystems liegt — intensiver Claude Skills-Einsatz, viele MCP-Server speziell an Claude angeschlossen, Sub-Agents, die von Auto-Dispatch abhängen — zahlt sich das parallele Setup möglicherweise nicht aus. Die portierbare Schicht ist für dich kleiner als für jemanden, der beide Tools hauptsächlich über einfache Markdown-Skills verwendet.

Wenn du ein Solo-Entwickler bist, der ein Nebenprojekt am Wochenende baut, spielt das Widerstandsfähigkeitsargument weniger eine Rolle. Ein Ausfall kostet dich den Samstagnachmittag. Ärgerlich, nicht katastrophal. Das parallele Setup zahlt sich am meisten aus, wenn dein Lebensunterhalt davon abhängt, dass der Agent verfügbar ist — wenn ein Ausfall bedeutet, dass Kundenarbeit nicht ausgeliefert wird.

Und wenn du kostenbewusst bist, bedeutet das Betreiben zweier CLIs, dass du Abonnements oder API-Zugang bei zwei Anbietern hast. Ich betreibe beide über Pro-Pläne, was mehr pro Monat kostet als eines zu betreiben. Es lohnt sich für mich, weil der Widerstandsfähigkeitswert hoch ist. Wahrscheinlich lohnt es sich nicht für jemanden mit geringer Nutzung.

## Der Echte Gewinn: Widerstandsfähigkeit und Frische Perspektive

Das Setup lohnt die Arbeit aus zwei Gründen, die leicht zu unterschätzen sind, bis man ohne sie gelebt hat.

Widerstandsfähigkeit zuerst. In den sechs Wochen, seit ich beide CLIs betreibe, habe ich zwei separate Anthropic-Vorfälle und einen langwierigen Claude Code CLI-Update-Bug erlebt. In allen drei Fällen verlor ich ungefähr null Arbeitszeit, weil ich innerhalb von fünf Minuten zu Codex wechselte und weiterarbeitete. Verglichen mit den Pre-Setup-Tagen, als ein schlechter Nachmittag mich eine komplette Kundenlieferung kosten konnte, hat sich die parallele CLI-Investition beim ersten Vorfall bereits bezahlt gemacht.

Frische Perspektive an zweiter Stelle. Selbst an Tagen, an denen keiner der beiden Agents kaputt ist, ist das Wechseln der CLI mitten in einer Aufgabe das günstigste Kreativitätswerkzeug, das ich je benutzt habe. Andere Modelllinie. Anderes RLHF. Anderer Trainingsdaten-Schwerpunkt. Derselbe Prompt, an Claude Code und an Codex gesendet, wird manchmal Lösungen produzieren, die sich im Ansatz grundlegend unterscheiden. Ich bin dazu übergegangen, beide bewusst am selben schweren Problem laufen zu lassen und die besten Ideen zusammenzuführen. Es ist, als hätte man zwei Senior-Entwickler an derselben Aufgabe, außer dass einer von ihnen fast nichts extra kostet und nie müde wird.

Das tool-agnostische Mindset ist die echte Verschiebung. Die CLI ist austauschbar. Das Projektwissen ist das, was zählt. Behandle `AGENTS.md` (oder was auch immer deine geteilte Anweisungsdatei ist) als die wichtigste Datei in deinem Repo. Behandle Skills als portable Assets, nicht als tool-spezifische Skripte. Behandle Sub-Agents als das, was jede CLI auf ihre Weise macht, und versuche nicht, sie über Anbieter hinweg identisch zu erzwingen.

Wenn Anthropic morgen einen Konkurrenten zu Codex veröffentlichen würde, würde mein Workflow ihn an einem Nachmittag absorbieren. Wenn OpenAI etwas veröffentlichen würde, das Claude Code obsolet macht, genauso. Die Agents kommen und gehen. Das Projektwissen bleibt.

Das ist der Gewinn.

## Häufig Gestellte Fragen

### Können Claude Code und Codex gleichzeitig dieselben Dateien bearbeiten?
Ja, beide CLIs können gleichzeitig Dateien im selben Projekt bearbeiten, aber sie koordinieren nicht auf In-Memory-Ebene — sie koordinieren über das Dateisystem. Wenn beide Agents dieselbe Datei in derselben Minute berühren, bekommst du ein Stale-Read-Problem. Praktische Regel: Betreibe sie parallel an verschiedenen Dateien oder übergib explizit mit dem Session-Übergabe-Skill oben.

### Muss ich für sowohl Claude Code als auch Codex separat bezahlen?
Ja. Claude Code ist Anthropics CLI und verwendet Anthropic-Abrechnung (Pro-Plan oder API). Codex ist OpenAIs CLI und verwendet OpenAI-Abrechnung (ChatGPT Plus/Pro oder API). Es gibt kein gemeinsames Abonnement. Die Kosten für das Betreiben beider sind ungefähr 2x die Kosten für eines, aber die Widerstandsfähigkeit und der frische Perspektivgewinn machen es für arbeitende Fachleute lohnenswert.

### Was ist der tatsächliche Unterschied zwischen CLAUDE.md und AGENTS.md?
Funktional nichts — beide sind einfache Markdown-Dateien, die der Agent beim Start liest, um Projektkonventionen zu lernen. Der Unterschied ist, welche CLI standardmäßig welche liest. AGENTS.md wird zum Cross-Vendor-Standard, unterstützt von Codex und anderen, während CLAUDE.md Claude Codes nativer Dateiname ist. Das sauberste Setup ist, AGENTS.md als die echte Datei zu behalten und CLAUDE.md darauf zu symlinken.

### Funktionieren meine Claude Code-Skills in Codex ohne Änderungen?
Die meisten, ja. Beide Ökosysteme verwenden dasselbe SKILL.md-Format (YAML-Frontmatter mit name/description, Markdown-Body). Die Skills, die Bearbeitung brauchen, sind diejenigen, die auf Claude-Code-spezifische Tool-Namen wie Glob oder spezifische MCP-Server verweisen, die nicht in deinem Codex-Setup installiert sind. Ungefähr 80% portieren in meiner Erfahrung ohne Änderungen; die anderen 20% brauchen 5-10 Zeilen Bearbeitungen.

### Hat Codex Sub-Agents wie Claude Code?
Codex unterstützt jetzt Skills (den modernen Ersatz für Custom Prompts) und Sub-Agents über `.codex/agents/`, aber das Dispatch-Modell ist anders: Codex erfordert, dass du einen Sub-Agent explizit aufrufst, während Claude Code automatisch basierend auf der Agentbeschreibung dispatcht, die zur Aufgabe passt. Wenn du auf Auto-Routing über viele Sub-Agents angewiesen bist, ist Claude Code immer noch der stärkere Orchestrator. Wenn du deterministische Kontrolle darüber bevorzugst, welcher Agent läuft, ist Codex' explizites Aufrufmodell sauberer.

## Lass Uns Zusammenarbeiten

Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe gerne.

* **Fiverr** (maßgeschneiderte Builds & Integrationen): [fiverr.com/s/EgxYmWD](https://www.fiverr.com/s/EgxYmWD)
* **Portfolio**: [mejba.me](https://www.mejba.me)
* **Ramlit Limited** (Enterprise-Lösungen): [ramlit.com](https://www.ramlit.com)
* **ColorPark** (Design & Branding): [colorpark.io](https://www.colorpark.io)
* **xCyberSecurity** (Sicherheitsdienste): [xcybersecurity.io](https://www.xcybersecurity.io)