Codex-Plugin für Claude Code: Installieren, Konfigurieren, Überprüfungszyklen vermeiden
Wie man Codex und Claude Code zusammen verwendet: Wählen Sie einen Host aus, installieren Sie den offiziellen Plugin, teilen Sie die AGENTS.md-Regeln, nutzen Sie die Überprüfungs- und Rettungsbefehle sowie begrenzen Sie den Überprüfungslauf.
Quellen: Codex Plugin for Claude Code: Choose, Install, and Run a Reliable Two-Agent Workflow
Jeder, der bereits zwei Programmieragenten nebeneinander betrieben hat, kennt dieses Muster. Ein Terminal plant, das andere überprüft, und man sitzt dazwischen und kopiert Text hin und her wie ein Klonkasten mit Meinungen. Versucht man, das Gespräch zu automatisieren, beginnen die beiden, sich über Kommas zu streiten, und die Sitzung, die man eigentlich vor dem Mittagessen beenden wollte, schreibt immer noch denselben Überschriftentext um vier Uhr nachmittags um.
Der offizielle Plugin von OpenAI für Claude Code, codex-plugin-cc, beseitigt den größten Teil dieses Kopierens. Es ermöglicht es Ihnen, Codex-Überprüfungen, Aufgabenzuweisungen und Sitzungstransfers direkt aus Claude Code heraus auszuführen. Der Zugang ist schnell: Installieren Sie die Codex CLI auf dem Rechner, registrieren Sie den OpenAI-Marktplatz in Claude Code, installieren Sie das Plugin, laden Sie neu und führen Sie schließlich den Einrichtungsbefehl aus. Bei der umgekehrten Konfiguration, bei der Claude als Gast innerhalb von Codex läuft, gibt es ein separates Plugin mit eigener Installationsroute. In beiden Fällen ist es sinnvoll, zunächst Anweisungen zum Projekt zu teilen und begrenzte Regeln für Überprüfungen und Weitergabe vor der Automatisierung von Schleifen festzulegen.
Der Vorteil ergibt sich aus einem kürzeren Übergang und nicht aus intelligenteren Modellen. Ein Repository mit einem Host-Terminal, bei dem der Gastagent die Überprüfung eigenständig durchführt, erspart es dem Menschen, jeden Teil des Diffs zwischen den Fenstern hin- und herzuschieben. Die unten stehenden Informationen stammen aus der Dokumentation der Plugins sowie Beiträgen der Community; Befehle oder Modellnamen könnten seit ihrer Erhebung geändert worden sein, daher sollten Sie diese vor der Verwendung mit den aktuellen READMEs abgleichen.
Wählen Sie die Richtung, bevor Sie etwas installieren
Stellen Sie sich vor, Sie steigen in ein Auto ein, in dem zwei Navigationsgeräte gleichzeitig aktiv werden. Das eine bevorzugt die Autobahn, das andere die Seitenstraßen – und keines wartet darauf, dass Sie einen Fahrer auswählen. Wenn Sie die Einfahrt verlassen, ohne zu entscheiden, wer den nächsten Richtungswechsel vornimmt, geraten Sie in die Falle, während beide Bildschirme durcheinanderreden.
Das grundlegende Problem liegt beim Host. Das Codex-Plugin für Claude Code fungiert als zusätzlicher Navigator, nicht als zusätzliches Steuerungselement – daher muss vor dem Ausführen des ersten Installierungsbefehls entschieden werden, welches Terminal die Kontrolle übernimmt.
Es gibt zwei Ansätze, und jeder erfordert seine eigene Vorgehensweise. Ein $cc:-Befehl gehört nicht in eine Claude Code-Sitzung, und ein in Codex eingefügter /plugin-Befehl ruft nicht dasselbe Plugin auf.
Offizieller Ansatz: Codex innerhalb von Claude Code
Dafür bietet OpenAI sein eigenes Produkt codex-plugin-cc an. Claude Code bleibt die Arbeitsumgebung, während Codex als zusätzlicher Agent hinzukommt, der Code überprüfen, Entwürfe hinterfragen, Korrekturen durchführen, Hintergrundaufgaben ausführen und die Sitzung fortsetzen kann.
Ein Plugin-Marktplatz ist im Grunde das Verzeichnis, auf das Claude Code zurückgreift, um Plugins zu finden, die es installieren kann. Der Ablauf besteht darin, den Marktplatz von OpenAI hinzuzufügen, codex@openai-codex zu installieren, neu zu laden und anschließend /codex:setup auszuführen. Das Plugin kommuniziert mit Ihrer lokalen Codex CLI sowie dem Codex-App-Server und startet keinen eigenen separaten Cloud-Runtime. Wählen Sie diesen Weg, wenn Claude Code bereits dort ist, wo Sie es haben möchten – um zu suchen und zu steuern. Wenn sich ein Blogbeitrag und die README-Datei des Repositoriums widersprechen, hat die README-Datei Vorrang.
Rückwärtsroute: Claude innerhalb von Codex
Sendbirds cc-plugin-codex funktioniert in die andere Richtung. Codex ist der Host, und Claude Code wird als Gast aufgerufen – normalerweise über einen neuen, nicht-interaktiven claude -p-Unterprozess pro Aufgabe. Die Installation erfolgt innerhalb von Codex:
codex plugin marketplace add sendbird/codex-marketplace
codex plugin add cc@sendbird
$cc:setup
Es gibt einen idempotenten Hilfsprogramm, npx cc-plugin-codex install, das zur Aktualisierung erneut ausgeführt werden kann. $cc:setup überprüft Hooks, den Cache sowie schreibbare Pfade, und auch die umgekehrten Hooks benötigen hooks = true unter [features] in ~/.codex/config.toml.
Eine dritte, inoffizielle Option existiert ebenfalls: ein Community-Marktplatz (yanchuk/claude-plugin-codex) mit dem Befehl $claude setup. Behandeln Sie dieses als Community-Software und vermischen Sie es nicht mit OpenAI’s Plugin.
Falls Sie eine Entscheidung darüber wollen, welches Produkt besser ist, handelt es sich dabei um einen anderen Vergleich – die Diskussion hier bezieht sich weiterhin auf die Einrichtung. Kurz gesagt, die Entscheidung hängt davon ab, wer Host und wer Gast ist sowie welche Installationsoption Sie eingeben dürfen.
Installieren des offiziellen Plugins innerhalb von Claude Code
Der Rest dieses Abschnitts folgt dem offiziellen Weg, es sei denn, eine Überschrift weist auf einen umgekehrten Weg hin. Markenvergleiche, VS Code und Cursor sind getrennte Aufgaben, und die CLI selbst – einschließlich der Plattform-Installer sowie der Flags für den ersten Ausführungs-Sandbox-Modus – verfügt über eigene Installationsdokumentationen.
Die Aktionen werden fehlschlagen, wenn Node.js älter als 18.18 ist, wenn Codex auf dem Rechner nicht authentifiziert ist oder wenn Sie das Neu laden überspringen und anschließend davon ausgehen, dass der Plugin defekt ist.
Überprüfen Sie die in den Dokumentationen angegebenen Anforderungen
Das offizielle Plugin erfordert Node.js 18.18 oder neuer. Das Reverse-Plugin von Sendbird verlangt lediglich Node.js 18+, doch wer den offiziellen Weg wählt, muss die höheren Anforderungen erfüllen. Zudem benötigen Sie eine funktionierende lokale Codex CLI sowie eine Möglichkeit zur Bezahlung – das bedeutet entweder ein ChatGPT-Abo (das kostenlose zählt laut dem offiziellen README) oder eine OpenAI-API-Schlüssel. Claude Code hat eigene Anforderungen: entweder einen Anthropic-API-Schlüssel oder ein Claude Pro- oder Max-Abo. Dadurch entstehen zwei Produkte und zwei Rechnungen, wobei das Plugin sie nicht kombiniert.
Falls die CLI fehlt, installieren Sie sie:
npm install -g @openai/codex
Dann melden Sie sich über den dokumentierten Claude Code-Flow an:
!codex login
Vermeiden Sie Spiegelseiten sowie Auflistungen von Exekutablen Dritter. Die legitimen Pakete sind das GitHub-Repository sowie die scoped npm CLI. Falls Ihr tägliches Werkzeug eine IDE-Sidebar und nicht Claude Code ist, haben Sie es mit einem anderen Host zu tun, der eigene Anweisungen bereitstellt.
Marktplatz hinzufügen, installieren, neu laden, einrichten
Die Installation des offiziellen Plugins erfordert vier Schrägstrich-Befehle. Ein Schrägstrich-Befehl ist ein /command, der in der Claude Code-Sitzung eingegeben wird und kein Binärdatei auf Ihrem Shell-Pfad ist. Führen Sie sie in dieser Reihenfolge aus:
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup
/reload-plugins aktualisiert die Liste der aktiven Plugins, und wenn man diesen Befehl überspringt, kann es dazu kommen, dass eine erfolgreiche Installation vorliegt, bei der die Befehle dennoch als fehlend angezeigt werden. /codex:setup bestätigt, dass Codex authentifiziert ist, und falls die CLI nicht vorhanden ist, kann es vorschlagen, das globale @openai/codex-Paket mit npm zu installieren. Das ist die gesamte offizielle Installation. Die meisten Probleme, die die Leute dem Plugin zuschreiben, entstehen durch die damit verbundenen Schritte.
Codex für das Projekt und nicht nur für den Rechner konfigurieren
Eine globale Installation stellt Befehle zur Verfügung. Sie weist Codex jedoch nicht an, wie mit einem bestimmten Repository umgegangen werden soll. Benutzerstandardwerte und projektbezogene Anpassungen befinden sich in verschiedenen Dateien, und die Projektdatei wird nur geladen, wenn dem Projekt Vertrauen entgegengebracht wird.
Ein häufiger Fehler besteht darin, die Benutzerdatei zu bearbeiten, um das Modell eines Projekts festzulegen, und sich anschließend zu wundern, warum ein zweites Repository dieses Modell geerbt hat. Die Vererbung ist Teil des Designs: Diese Bearbeitung konfigurierte die Maschine, nicht den Baum.
Benutzer-Einstellungen versus Überschreibungen für vertrauenswürdige Projekte
Die Konfiguration auf Benutzerebene befindet sich in ~/.codex/config.toml, der Heimverzeichnisdatei, die Codex für jedes Projekt liest. Überschreibungen für ein vertrauenswürdiges Projekt liegen in .codex/config.toml am Wurzelverzeichnis des Repositoriums. „Vertrauenswürdig“ bezieht sich auf Codex’ Projekt-Vertrauensflagge: Überschreibungen werden nur geladen, wenn das Verzeichnis als vertrauenswürdig markiert ist, und ein unvertrauenswürdiger Baum ignoriert die lokale Datei. Das ist eine Sicherheitsmaßnahme und kein Fehler – daher sollte man beim Problem mit der Projektdatei zunächst das Vertrauenslevel überprüfen, bevor man den TOML-Datei fehlerbehebt.
Eine angemessene Aufteilung bewahrt Geheimnisse sowie die Standardvorsicht im Benutzerprofil auf und platziert die für das Repository spezifischen Modelle sowie Sandbox-Einstellungen im Projektprofil, sobald dem Baum Vertrauen entgegengebracht wird.
Modell- und Reasoning-Verhalten
Hier spielen zwei Schlüssel eine Rolle: model und model_reasoning_effort. Die offizielle README-Dokumentation zeigt eine solche Projekt-Überwrite wie folgt:
model = "gpt-5.4-mini"
model_reasoning_effort = "high"
Betrachten Sie diese Werte als Beispiele, die schnell veralten. Die Modell-Tags ändern sich rasch, und ein in einem Screenshot sichtbarer String kann bereits eine Woche später veraltet sein. Kopieren Sie die Schlüssel und überprüfen Sie anschließend die Werte anhand der aktuellen Dokumentation, bevor Sie sie in ein Repository übertragen. Der Plugin akzeptiert außerdem die Abkürzung spark, die mit gpt-5.3-codex-spark übereinstimmt; diese Zuordnung ist dokumentiert, aber genauso vergänglich. Sollte ein späteres README sie nicht mehr erwähnen, folgen Sie dem README.
model_reasoning_effort = „high“ ist kein freier Qualitätsregler, denn ein höherer Wert verbraucht bei jeder Schrittfolge mehr Token. Verwenden Sie ihn nur bei Design-Herausforderungen oder schweren Testfehlern und lassen Sie ihn nicht für eine einfache Umbenennung aktiviert.
Genehmigungen und Sandboxing
Ein Leitfaden von Drittanbietern namens ShakaCode beschreibt interaktive Überschreibungen sowie Umgebungsvariablen, die im offiziellen README des Plugins nicht hervorgehoben werden, weshalb sie als Anleitung von Drittanbietern zu betrachten sind. approval_policy steuert, wann Codex vor einer Aktion nachfragt, wobei die Werte untrusted und on-request angegeben sind. sandbox_mode beschränkt, was der Prozess berühren darf; die möglichen Einstellungen sind read-only, workspace-write und danger-full-access.
approval_policy = "untrusted"
sandbox_mode = "workspace-write"
In der zitierten Anleitung ist dies das Standardprofil für die Arbeit mit Funktionen: Codex darf zwar innerhalb des Arbeitsbereichs schreiben, fragt aber dennoch vor jeder Aktion nach, als wäre dem Baum nur teilweise Vertrauen entgegengebracht. Reservieren Sie danger-full-access für Testläufer und Build-Skripte, denen Sie bereits vertrauen, und verwenden Sie es niemals beim ersten Betrachten eines unbekannten Repositoriums.
Über die CLI fragt codex --auto-edit weiterhin vor der Ausführung im Shell nach, während codex --full-auto vollständig in einer Sandbox ausgeführt wird, ohne jegliche Anfragen. Die Flags ändern das Verhalten bezüglich der Anfragen und sind keine Synonyme – greifen Sie daher nicht auf --full-auto zurück, nur weil es entschlossener klingt.
Menschen installieren oft ein zweites Plugin, um keine Funktion zu verpassen, obwohl das fehlende Element eine Entscheidung bezüglich des Hosts ist, die bereits vor dem ersten Befehl getroffen werden muss.
Eine einzige Quelle der Wahrheit für beide Agenten
Zwei Agenten auf einem Baum ohne gemeinsame Anweisungen werden bis Donnerstag zwei Hausstile erfinden. Man kann mit duplizierten Reinigungsregeln, duplizierten Testbefehlen sowie einer Überprüfung rechnen, die eine Konvention rückgängig macht, die der andere Agent gerade erst wieder eingeführt hatte. Codex bezieht seine Repository-Regeln aus der Markdown-Datei AGENTS.md, während CLAUDE.md die entsprechende Datei für Claude Code ist. Was benötigt wird, ist eine Richtlinie dafür, wie sich die beiden Agenten verhalten sollen, denn nichts hält sie im Einklang, es sei denn, jemand sorgt dafür.
Die am besten dokumentierte Übersicht der Optionen ist ShakaCodes claude-code-with-codex.md. Sie ist nach Modellnamen datiert, daher sollte man sich darauf bei der Festlegung der Dateistrategie verlassen und nicht auf die Standardmodell-Tags.
Verweis auf eine einzige Anweisungsdatei
Legen Sie die Build-Befehle, Architekturhinweise sowie Konventionen in AGENTS.md ab und nutzen Sie CLAUDE.md als Verweis:
# Project Instructions
See @AGENTS.md for build commands, architecture, and conventions.
Zwei Dateien bleiben übrig, und notespezifische Anmerkungen zu Claude können weiterhin unter dem Pointer platziert werden. Der Aufwand besteht in der regelmäßigen Wartung, da ein Vergessen beim Aktualisieren des Pointers dazu führt, dass Claude weiterhin einen Inhalt verfolgt, der nicht mehr existiert. Codex kann außerdem angewiesen werden, auf einen Ersatz zurückzugreifen, wenn AGENTS.md fehlt – und zwar über ~/.codex/config.toml:
project_doc_fallback_filenames = ["CLAUDE.md", "COPILOT.md"]
Das ist ein Lesepfad und keine Zusammenführung. Codex wird nach diesen Dateinamen suchen, aber er wird drei Dateien nicht zu einer einzigen Richtlinie verschmelzen.
Symlinken der universellen Regeln
Die schnelle Variante besteht aus einem einzigen Befehl:
ln -s AGENTS.md CLAUDE.md
Ein Inode, zwei Namen – dadurch bleiben die universellen Regeln unverändert. Der Kompromiss ist jedoch real: Man kann tool-spezifische Anweisungen nicht getrennt halten, da es keinen zweiten Datei gibt. Wenn Claude einen Hook benötigt, den Codex auf keinen Fall sehen sollte, kann das durch einen Symbollink nicht ausgedrückt werden.
Einen gemeinsamen Kern mit tool-spezifischen Ergänzungen beibehalten
Regeln, die unverändert bleiben müssen – wie der Testbefehl, die Lint-Einstellungen sowie „Formatierung nicht umschreiben“ – gehören in AGENTS.md, während nur für Claude oder nur für Codex bestimmte Anmerkungen in CLAUDE.md aufgeführt werden. Das ist die ausgereifte Option, erfordert jedoch sorgfältige Wartung; deshalb verzichten Teams darauf und geben den Modellen anschließend die Schuld für Abweichungen.
Falls beide Agenten gleichzeitig bearbeiten, reichen gemeinsame Anweisungen nicht aus. Trennen Sie ihre Arbeitsbäume voneinander – git worktrees sind hierfür das übliche Werkzeug – damit sie nicht um denselben Index konkurrieren. Gleichzeitige Schreibvorgänge an derselben Auskopie führen zu Merge-Konflikten, die von keinem der Agenten absichtlich verursacht wurden.
Überprüfungen, Herausforderungen, Rettungsmaßnahmen und Hintergrundarbeiten
Sobald das Plugin geladen ist, besteht die Versuchung, alles zu automatisieren. Besser ist es, den kleinstmöglichen Befehl zu verwenden, der zur Aufgabe passt – schließlich stellt eine nur zum Lesen geeignete Überprüfung keine Implementierung dar, und Implementierung ist kein Argument für das Design.
Einfache Überprüfung oder konfrontative Überprüfung
/codex:review startet eine nur zum Lesen geeignete Korrektheitskontrolle lokaler, noch nicht gespeicherter Änderungen oder einer angegebenen Basis. Es akzeptiert die Optionen --base <ref>, --wait und --background und schreibt niemals Dateien.
/codex:review --background
/codex:adversarial-review ist eine steuerbare Design-Herausforderung, die Entscheidungen in Frage stellt, und freier Text kann den Flaggen folgen.
/codex:adversarial-review --base main challenge whether this was the right caching and retry design
Auf dem Rückweg sind die Entsprechungen $cc:review und $cc:adversarial-review, die unter einem anderen Host dieselben Aufgaben erledigen. Verwenden Sie die Präfixe nicht durcheinander. Eine Überprüfung, die nur an der Reihenfolge der Importe herummeckert, ist keine echte Überprüfung – schreiben Sie daher die funktionale Frage in den Befehl. Wenn Sie die Frage nicht formulieren können, sind Sie noch nicht bereit, einen Überlegungsschritt einzulegen.
Übergeben eines Fixes mithilfe von Rescue
/codex:rescue überträgt die Implementierungsarbeiten an den Subagenten des Plugins codex:codex-rescue, und im Gegensatz zu den Überprüfungsbefehlen ändert dieser Dateien. Zu seinen Flags gehören --background, --wait, --resume und --fresh.
/codex:rescue fix the failing test with the smallest safe patch
Das Gegenstück ist $cc:rescue. Halten Sie die Anfrage präzise, denn der Satz „Machen Sie es besser“ führt zu einer Neuverarbeitung, die Sie nicht wollten, sowie zu einem endlosen Überprüfungszyklus.
Verfolgung und Steuerung von Hintergrundaufgaben
Unter „Hintergrund“ ist hier zu verstehen, dass die Aufgabe des Plugins weiterläuft, während Sie weiterhin Claude Code verwenden. Es handelt sich dabei nicht um einen zweiten Checkout, und es wird auch keine Garantie dafür gegeben, dass die Arbeit abgeschlossen ist.
/codex:status
/codex:result
/codex:cancel
/codex:status gibt den Status der Hintergrundaufgaben an, /codex:result zeigt deren Ausgabe und /codex:cancel stoppt sie. Überprüfen Sie gezielt und betrachten Sie Stille nicht als Erfolg. Das Gegenstück-Plugin bietet die entsprechenden Befehle als $cc:status, $cc:result und $cc:cancel an, wobei wiederum der Host das Präfix festlegt.
Kontextübertragung und Erstellung eines begrenzten Übertragungszyklus
Eine Überprüfung in Claude Code ist nicht dasselbe wie eine Codex-Sitzung, die die früheren Überlegungen anzeigen kann, und wenn ein Debugging-Thread bereits lang ist, führt Kopieren-Einfügen dazu, dass die Zusammenhänge verloren gehen. /codex:transfer ist die dokumentierte Lösung. Eine perfekte Zustandssynchronisierung wird nicht angeboten. Stattdessen erhalten Sie einen persistenten Codex-Thread sowie einen Befehl zur Ausgabe des Zusammenfassens, sodass die Kommunikation zwischen den beiden Umgebungen ohne weitere menschliche Vermittlung stattfinden kann.
Fortsetzen im Codex nach einem Transfer
/codex:transfer sucht nach der Queltdiskussion unter ~/.claude/projects, und wenn die JSONL-Datei dort nicht vorhanden ist, kann der Transfer sie nicht erzeugen. Was ausgegeben wird, soll in der Codex-App oder der TUI ausgeführt werden:
codex resume <session-id>
Nutzen Sie die von dem Befehl ausgegebene Sitzungs-ID – niemals eine erfundene oder eine kopierte URL aus einem ChatGPT-Gespräch.
Planen, umsetzen, überprüfen, zurückgeben
Der eigentliche Ablauf ist langweilig:
- Planen Sie in Claude Code und schreiben Sie zunächst die Bestätigungszeile.
- Setzen Sie die Umsetzung entweder in Claude Code oder mithilfe von
/codex:rescueum, wenn der Patch begrenzt ist. - Überprüfen Sie den Code mit
/codex:reviewoder/codex:adversarial-review, nacheinander. - Geben Sie die Kontrolle weiter, damit eine Person den Vorschlag annimmt, ablehnt oder weiterleitet.
Der Prozess muss irgendwann enden. Ein Kreislauf, der ständig zu „einer weiteren Überprüfung“ führt, verwandelt die Kontrolle in eine Qual.
Beendigung des endlosen Überprüfungszyklus: Ein Konflikt- und Budgetprotokoll
Die zur Verbesserung der Qualität gedachte Funktion kann aufgrund von Geschmackssachen das Budget übersteigen. Das Ausführen von /codex:setup --enable-review-gate fügt einen lokalen Stop-Hook hinzu, also einen Hook am Ende eines Zuges: Sobald Claude versucht, den Zug abzuschließen, wird von Codex verlangt, das Ergebnis zu überprüfen, bevor der Zug geschlossen werden darf. Wenn Codex Probleme findet, wird Claude blockiert, damit diese behoben werden können. Ohne Aufsicht kann dieser zyklische Prozess die Token schnell aufbrauchen. Die offizielle README warnt davor, bietet jedoch kein Budget-Protokoll an.
Die unten genannte Obergrenze von drei Iterationen ist eine auf dieser Lücke basierende redaktionelle Richtlinie und keine offizielle Funktion des Plugins. Es gibt kein --max-iterations 3-Flag, nach dem man suchen müsste.
Definieren Sie zunächst die funktionale Akzeptanz
Schreiben Sie die Liste der Hindernisse, bevor jemand sie überprüft, und halten Sie sie aktuell: Tests, die bestanden werden müssen, Verhaltensweisen, bei denen es nicht zu Rückschritten kommen darf, sowie Sicherheits- oder Datenergänzungen, die als automatische Ablehnung gelten. Formatierung, Kommentarton und Überschriftsebenen sind keine Hindernisse, es sei denn, die Anleitungsdokumente des Repositoriums verbieten sie bereits. Lassen Sie den Stil in die Überprüfungsregeln einfließen – dann werden zwei Agenten drei Runden lang darüber streiten, ob eine Überschrift H2 oder H3 sein soll.
Ein warnendes Beispiel: Bei einem Commit, der nur Dokumente enthält und über die Überprüfungsregel verfügt, stritten sich die beiden Agenten darüber, ob eine Überschrift H2 oder H3 sein sollte, bis die Sitzung beendet wurde – obwohl die Seite bereits korrekt war. Da es keine klare Definition für „fertig“ gab, erdachte die Regel selbst eine. Speichern Sie die Checkliste in AGENTS.md, damit beide Agenten dieselben Regeln sehen. Es ist in Ordnung, sie im Überprüfungsbefehl nochmals zu wiederholen, doch eine vage Anfrage wie „machen Sie es sauberer“ führt zu einer Neuformulierung.
Beschränken Sie die Iterationen und zwingen Sie zu einer menschlichen Entscheidung
Beschränken Sie sich auf drei Runden mit Überprüfung und Korrektur pro Änderung:
- Iteration 1: nur funktionale Hindernisse.
- Iteration 2: alle verbleibenden Hindernisse, ohne neue Stilprobleme.
- Iteration 3: die letzte Überprüfung, danach Pause.
Nach drei Runden entscheidet eine Person, ob die Änderung integriert, rückgängig gemacht oder die Spezifikation neu geschrieben wird – die Agenten dürfen nicht erneut abstimmen. Community-Beiträge zu tmux-Wrappern und benutzerdefinierten Skripten gelten als experimentelle Belege und nicht als zweiter offizieller Weg; betrachten Sie diese Skripte daher als das Werk eines anderen und nicht als Befehle von OpenAI.
Stoppen Sie, wenn sich im Grunde nichts geändert hat
Sendbirds umgekehrter Plugin erstellt einen Fingerabdruck des Arbeitsbaums und überspringt die Überprüfung am Ende einer Turnierung, wenn sich in der vorherigen Codex-Turnierung insgesamt nichts geändert hat. Diese Schutzmaßnahme ist für den umgekehrten Weg dokumentiert, während das Gate beim upstream-System diese Überspringung nicht anzeigt. Auf dem offiziellen Weg sind Sie selbst der Fingerabdruck: Wenn git status sauber ist, wird eine weitere Überprüfung übersprungen; wenn sich in der letzten Turnierung nur Kommentare geändert haben, wird geprüft, ob diese auf der Akzeptanzliste standen – falls nicht, wird die Überprüfung beendet.
Warten Sie damit, das Gate zu automatisieren, bis eine manuelle Überprüfung die Checkliste abgeschlossen hat. Schalten Sie --enable-review-gate zuletzt ein und niemals zuerst.
Fehlerbehebung nach Route, Authentifizierung, Vertrauensstatus und veralteten Aufgaben
Diagnostizieren Sie den Weg, bevor Sie etwas neu installieren. Fehler auf dem offiziellen upstream-Pfad und Fehler bei den Hooks des umgekehrten Plugins sehen in einer frustrierten Chat-Nachricht ähnlich aus, gehören aber nicht zum selben System. Eine Neuinstallation ist fast nie die erste Überprüfung.
Der offizielle upstream-Pfad
- Plugin-Befehle nicht verfügbar: Führen Sie
/reload-pluginsaus. Falls sie weiterhin fehlen, überprüfen Sie, ob/plugin install codex@openai-codextatsächlich abgeschlossen ist, und führen Sie anschließend/codex:setupaus. - Codex kann sich nicht authentifizieren: Geben Sie
!codex loginein, wie im Claude Code-Flow beschrieben. Das Plugin liest den lokalen Authenzustand – ein eingeloggtes ChatGPT-Browserfenster gilt nicht als eingeloggte CLI.
.codex/config.toml im Projektverzeichniswurzel gespeichert wurde und nicht nur in der Datei des Heimverzeichnisses.~/.claude/projects befinden; eine Sitzung, die dort noch nie etwas geschrieben hat, kann nicht übertragen werden. Starten Sie zunächst eine echte Claude Code-Projektsitzung./codex:status, anschließend /codex:result oder /codex:cancel, und starten Sie keine zweite Rettungsaktion nur deshalb, weil die erste stillgelegt wurde.node -v aus.Reverse-Plugin-Hooks und Cache-Vertrauen
Falls die umgekehrten Hooks nicht laufen, setzen Sie hooks = true unter [features] in ~/.codex/config.toml. Wenn die umgekehrte Einrichtung unvollständig erscheint, führen Sie $cc:setup aus – dieses Kommando dient dazu, Hooks zu überprüfen sowie Caches und schreibbare Pfade zu validieren. Für das Community-Plugin ist $claude setup die eigene Überprüfung dieses Projekts, und da es inoffiziell ist, sollten Fehler daraus nicht dem Projekt openai/codex-plugin-cc zugeschrieben werden. Die Windows-Unterstützung im Sendbird-Pfad ist in dessen Repository als experimentell gekennzeichnet; daher ist ein WSL-Arbeitsbereich die bessere Wahl, wenn das Ziel das umgekehrte Plugin ist.
Kurze Antworten auf die häufigsten Fragen
Gibt es eine richtige Art, sie zu kombinieren? Nicht wirklich. Die erste Entscheidung betrifft das Tool, das die Sitzung hostet. Wenn Claude Code als Host dient, reichen das OpenAI-Plugin zusammen mit gemeinsamen Anweisungsdateien und kurzen Slash-Befehlsaufgaben aus. Wenn Codex als Host genutzt wird, übernimmt Sendbirds umgekehrtes Plugin zusammen mit dem Präfix $cc: dieselbe Funktion von der anderen Seite. Halten Sie die beiden Verfahren voneinander getrennt und sorgen Sie dafür, dass beide Agenten nicht gleichzeitig in denselben Dateien vorhanden sind.
Was genau muss eingegeben werden, um den offiziellen Plugin zu installieren? Vier Zeilen im Claude Code Prompt, in dieser Reihenfolge: der Marketplace-Add für openai/codex-plugin-cc, die Installation von codex@openai-codex, ein Neuladen des Plugins und /codex:setup. Falls die Codex CLI noch nicht auf dem Rechner vorhanden ist, kann das Setup anbieten, sie herunterzuladen, oder Sie können @openai/codex vorher selbst installieren und mit !codex login einloggen.
Bietet das Plugin seinen eigenen Codex-Backend? Nein. Alles wird an die bereits auf Ihrem Computer vorhandene Codex CLI und App-Server weitergeleitet, sodass derselbe Login sowie derselbe ChatGPT-Plan oder API-Schlüssel gelten. Welchen Zugriff die CLI auch immer benötigt, den braucht sie weiterhin.
Wie ist der sauberste Weg, beiden Agenten dieselben Regeln zu geben? Drei Ansätze funktionieren: Lassen Sie CLAUDE.md auf AGENTS.md verweisen, erstellen Sie einen Symbollink zwischen den beiden Dateien oder legen Sie die gemeinsamen Grundregeln in AGENTS.md ab und speichern Sie tool-spezifische Ergänzungen in CLAUDE.md. Eine Einstellung für eine Ersatz-Datei in der Benutzerkonfiguration ermöglicht es Codex, Claudes Datei zu lesen, wenn AGENTS.md fehlt. Der Symbollink ist am schnellsten, kostet aber den Verlust von tool-spezifischen Dateien.
Wo wird die Modellwahl pro Projekt festgelegt? In einer .codex/config.toml-Datei im Wurzelverzeichnis eines als vertrauenswürdig markierten Projekts, wobei die Schlüssel model und model_reasoning_effort verwendet werden. Beispieldaten aus den Dokumenten, wie gpt-5.4-mini und high, veralten schnell, daher sollten Sie diese überprüfen. Ein unvertrauenswürdiges Projekt greift stillschweigend auf Ihre Benutzerstandardeinstellungen zurück.
Was bewirkt das Review-Gate? Wenn es aktiviert ist, wird ein lokaler Stop-Hook registriert. Wenn Claude versucht, eine Runde zu beenden, prüft Codex zunächst die bearbeiteten Inhalte – bei gefundenen Problemen wird die Runde blockiert, damit Claude sie beheben kann. Ohne Überwachung kann das Token verbrauchen. Der umgekehrte Plugin kann einen Durchlauf überspringen, wenn sich im Arbeitsbaum nichts geändert hat, doch das ist sein eigenes Verhalten und keine Zusicherung seitens des Hauptprogramms.
Wie wird eine Sitzung weitergegeben? Führen Sie in Claude Code /codex:transfer aus. Dadurch wird die unter ~/.claude/projects gespeicherte Transkription in einen dauerhaften Codex-Thread umgewandelt und eine Zeile mit codex resume sowie der Sitzungs-ID ausgegeben, die Sie anschließend in der Codex-App oder im TUI ausführen. Fehlt es in diesem Verzeichnis an einer Transkription, gibt es nichts zu übertragen.
Wie kann ich verhindern, dass die beiden Token verbrennen? Definieren Sie im Voraus ausschließlich funktionale Akzeptanzkriterien, erlauben Sie drei Runden zur Überprüfung und Korrektur, bevor ein Mensch eingebunden wird. Schalten Sie das Kontrollmechanismus erst nach einer manuellen Überprüfung ein. Wenn git status einen sauberen Zustand anzeigt oder die letzte Überprüfung nur Stilaspekte betraf, bei denen niemand als Blockierer aufgeführt wurde, beenden Sie den Prozess selbst.
Ein sicheres erstes Experiment
Wählen Sie ein Repository, das Sie bereits verstehen, sowie einen fehlerhaften Test oder eine kleine Änderung zur Überprüfung aus und führen Sie zunächst einen Commit oder ein Stash durch. Installieren Sie nur den offiziellen Weg und führen Sie /codex:review für diese Änderung aus. Lesen Sie das Ergebnis, wenden Sie es anschließend selbst an oder lehnen Sie es ab, und lassen Sie --enable-review-gate am ersten Nachmittag deaktiviert.
Falls die Übersicht nützlich ist, teilen Sie anschließend AGENTS.md und versuchen Sie einen einzigen Aufruf von /codex:transfer in einem echten Debugging-Thread. Das ist das gesamte Experiment. Die Namen der Modelle werden sich weiterhin ändern, doch die Entscheidung des Hosts sowie die Stoppsbedingungen bleiben relevant. Unklar bleibt, wie lange die Teams zwei Rechnungen sowie zwei Anleitungsdokumente ertragen werden, bevor jemand wieder nach einem einzigen Anbieter fragt. Derzeit ist die sinnvolle Variante dieses Stacks ein Türklingel-System mit Hausregeln und nicht ein Mitbewohner mit Schlüssel.