Claude Code zu Codex: Migrationsleitfaden 2026

Am 3. Mai 2026 inventarisierte ich 744 lokale Agentenkonfigurations-Einträge und bewertete anschließend 691 davon nach ihrem operativen Gewicht.¹ Die Zahl wirkte groß. Die Form war wichtiger: Rund 20 Dateien trugen das System.

Eine Migration von Claude Code zu Codex sollte Betriebsverträge portieren, nicht den Dateibaum kopieren. Verschiebe CLAUDE.md-Regeln in geschichtete AGENTS.md, wiederverwendbare Verfahren in Codex-Skills, deterministische Prüfgrenzen in fokussierte Hooks, Risikohaltung in Profile und Browser-/Quellenwerkzeuge in explizites MCP. Kopiere kein Claude-Hook-Gitter nach Codex; verschiebe die Nachweispflichten.

TL;DR

Der private Schreib- und Prüfungsstapel existiert in meiner Codex-Welt bereits. Es fehlte nicht der Skill-Inhalt. Es fehlte das öffentliche Betriebshandbuch: wo wiederverwendbare Skills liegen sollten, wie Codex sie auswählen sollte, welches Profil für öffentliches Schreiben laufen sollte und welche Prüfgrenzen aus der Claude-Ära zu Codex-nativen Regeln werden sollten, ohne private Arbeitsablaufdetails offenzulegen.

Der erste echte Codex-Durchlauf änderte die Migrationsregel: Mache einen privaten Arbeitsablauf nicht schon in dem Moment zur Umgebungsvorgabe, in dem er portiert wird. Stufe ihn. Mein site-spezifischer Schreibpfad startet jetzt nur auf ausdrücklichen Aufruf, während der Migrationsablauf als Benutzer-Skill für aktive lokale Nutzung und als privater Codex-Paketkandidat für lokale Tests lebt. Dieses Paket ist nicht quelloffen oder allgemein verfügbar; wenn du den Migrationsablauf testen willst, kontaktiere mich. Das Paket sollte nicht nur deshalb zum Standardpfad der Ausführungsumgebung werden, weil ein lokaler Installations-Eintrag existiert. Ein echter Installationspilot braucht weiterhin Paketvalidierung, Plugin-Installationsprüfung, namensraumgebundene Skill-Erkennung, Dublettenbereinigung und eine frische Codex-Sitzung, bevor er etwas bedeutet. So kann das System aus echter Arbeit lernen, bevor ein Arbeitsablauf zum Standardverhalten wird.¹⁸¹⁰¹⁴

Beginne nicht damit, jeden Claude-Hook in Codex zu klonen. Beginne damit, den Codex-Vertrag zu schreiben:

• Lege dauerhafte repo-übergreifende Richtlinien in ~/.codex/AGENTS.md ab.
• Lege Repository-Richtlinien in AGENTS.md ab und platziere engere Überschreibungen nahe an der Arbeit.
• Lege wiederverwendbare Verfahren in .agents/skills oder $HOME/.agents/skills ab.
• Hebe öffentliches Schreiben auf careful-review oder ein eigenes public-writing-Profil.
• Behalte deterministische Prüfgrenzen als Hooks, aber behandle Hooks als eine Leitplanke, nicht als das ganze Sicherheitsmodell.

Das erste erfolgreiche Migrationsartefakt sollte ein selbsterklärender Beitrag sein. Dieses Artefakt beweist, dass das System sich selbst beschreiben, aktuelle Dokumentation zitieren, eine bereinigte lokale Inventur nutzen und öffentliche Arbeit unter Codex-Kontrolle erzeugen kann, ohne die private Maschinerie dahinter zu veröffentlichen.

Die Claude-Seite des Stapels habe ich in Claude Code as Infrastructure behandelt, die Seite der Instruktionsdateien in AGENTS.md Patterns und das Problem verfallender Skills in Static Skills Are Dead Skills. Die folgende Migration verbindet diese Fäden mit der Codex-Ausführungsumgebung, die ich tatsächlich benutze.

Für angrenzenden Kontext lies den Codex CLI guide, Claude Code vs Codex, Codex vs Claude Code 2026, Claude Code Hooks Tutorial, Building Custom Skills und Jiro Quality Philosophy. Diese Beiträge erklären die Teile, die die Migration hier zusammensetzt.

Was zeigte die Migrationsinventur?

Das lokale System hatte drei Schwerpunkte.

Die Nutzungsdaten zeigten auf dieselbe Schlussfolgerung. Meine Profilweiterleitungsprotokolle zeigten, dass prüfungsintensive Arbeit die Routineausführung dominierte.¹ Das eigentliche Herz war nicht die längste Datei oder das raffinierteste Skript. Das Herz war die Entscheidungsschicht, die Risikoniveau wählte, Doktrin lud und Nachweise vor dem Abschluss erzwang.

Diese Erkenntnis verändert die Portierung.

Wenn das Wichtige wäre: „Claude hat viele Hooks“, würde die Migration Hooks kopieren. Wenn das Wichtige wäre: „Das System hat eine Philosophie“, würde die Migration Prosa kopieren. Die Inventur zeigte eine andere Antwort: Das Wichtige ist ein kleiner Vertrag, der zur richtigen Zeit auslöst.

Was haben wir vor der Veröffentlichung getan?

Der Artikel selbst wurde zur ersten Migrationsübung.

Zuerst kartierte ich die Form des ausgereiften Claude-Code-Setups: welche Teile Verhalten steuerten, welche Teile nur Vorlieben dokumentierten und welche Teile privat bleiben sollten. Dann prüfte ich aktuelles Codex-Verhalten gegen offizielle Dokumentation und die lokale CLI, weil Migrationsleitfäden schnell verfallen, wenn sie alte Flags oder nicht unterstützte Konfigurationsformen erben. Dann entwarf ich diesen Artikel mit der echten Migration im Kopf, reduzierte das öffentliche Detail aber auf bereinigte Architektur, nicht private Umsetzung.

Der nächste Schritt geschieht vor der Veröffentlichung: diesen Leitfaden nutzen, um das Codex-Setup auszubauen, und den Artikel anschließend anhand dessen überarbeiten, was tatsächlich geändert wurde. Der öffentliche Artikel sollte das Migrationsmuster und die Akzeptanzkriterien zeigen. Er sollte keine privaten Prompts, privaten Schreibabläufe, exakten Hook-Interna, sensiblen Pfade oder irgendetwas veröffentlichen, womit ein Leser das private System rekonstruieren könnte.

Der Live-Durchlauf erzeugte eine öffentlich sichere Nachweistabelle. Ich veröffentliche nur Vertrag, Aktivierungszustand und Akzeptanzsignal, nicht die privaten Prompts, exakten Hook-Körper oder Interna des Schreibablaufs.

Solltest du eine Codex-Migration mit Hooks beginnen?

Claude brachte mir bei, in Lebenszyklusereignissen zu denken. Ein UserPromptSubmit-Hook kann Projektkontext einfügen. Ein PreToolUse-Hook kann sensible Pfade blockieren. Ein Stop-Hook kann schwachen Abschluss verweigern. Dieses Muster funktioniert in Claude, weil mein lokaler Stapel um Dispatcher gewachsen ist, die viele kleine Skripte in eine geordnete Ereignispipeline verwandeln.¹¹

Codex hat ebenfalls Hooks, aber aktuelles Codex behandelt sie als feature-gesteuertes Lebenszyklussystem statt als immer aktives Hook-Verzeichnis. OpenAIs Hook-Dokumentation zeigt [features] codex_hooks = true in config.toml, und mein lokales codex features list meldet hooks in Codex CLI 0.130.0 als stabil und aktiviert.²⁸ OpenAI dokumentiert Hook-Eingaben als JSON über stdin, mit gemeinsamen Feldern wie Sitzungs-ID, Arbeitsverzeichnis, Ereignisname und aktivem Modell.² Codex unterstützt Ereignisse wie SessionStart, PreToolUse, PermissionRequest, PostToolUse, UserPromptSubmit und Stop; PreToolUse kann Bash-, apply_patch- und MCP-Werkzeugaufrufe abfangen.²

Dieselbe Dokumentation gibt auch die Warnung, die für Migration zählt: PreToolUse bleibt eine Leitplanke, keine vollständige Durchsetzungsgrenze. Die Dokumentation weist darauf hin, dass das Abfangen nicht jeden Shell-Pfad abdeckt und Websuche oder andere Nicht-Shell-, Nicht-MCP-Werkzeugaufrufe nicht abfängt.²

Diese Einschränkung macht Codex-Hooks nicht schwach. Sie bedeutet, dass Hooks nicht die ganze Portierung tragen sollten. OpenAI merkt außerdem an, dass mehrere passende Befehls-Hooks für dasselbe Ereignis parallel starten; eine Codex-Portierung, die Reihenfolge verlangt, braucht also weiterhin einen Dispatcher oder einen kombinierten Hook-Befehl.²

Für Codex will ich Hooks für enge deterministische Prüfungen:

• Offensichtlich destruktive Shell-Befehle blockieren.
• Vor zugangsdatenförmigen Pfaden warnen.
• Kleinen Sitzungskontext beim Start hinzufügen.
• Nachweise aus öffentlichen Schreibläufen aufzeichnen.
• Ein Stop-Ereignis fehlschlagen lassen, wenn ein erforderliches Artefakt oder ein Verifikationsbefehl fehlt.

Ich will nicht, dass Hooks Schreibstimme, Zitierpolitik, Philosophie, Weiterleitung oder Projektdoktrin tragen. Codex hat dafür bereits bessere Orte.

Wie ordnen sich Claude-Artefakte Codex zu?

Die Migration wird sauberer, wenn jedes Claude-Artefakt dem Codex-Grundelement zugeordnet wird, das am besten zu seiner Aufgabe passt.

OpenAIs AGENTS.md-Dokumentation macht die erste Zeile zum Rückgrat der Migration. Codex liest AGENTS.md-Dateien vor der Arbeit, schichtet globale Anleitung aus dem Codex-Home-Verzeichnis und läuft dann vom Projektstamm zum aktuellen Verzeichnis, wobei nähere Dateien frühere Anleitung überschreiben dürfen.³ Dieses Verhalten passt zu dem, was ich tatsächlich von CLAUDE.md brauche: dauerhafte Arbeitsvereinbarungen plus projektspezifische Details.

Der wichtige Schritt: Schreibe die Regeln als Operationen um. „Schreibe sorgfältig“ gehört nicht in AGENTS.md. „Für öffentliche Beiträge zuerst Zitate sammeln, URLs verifizieren, Prüfungen auf verbotene Phrasen ausführen und alle unverifizierten Behauptungen melden“ gehört dorthin.

Wie sollten private Schreib-Skills zu Codex wechseln?

Der Blog-Writer-Stapel lässt sich sauber portieren, weil er bereits die richtige Form hat. Ein Codex-Skill ist ein Ordner mit einer SKILL.md-Datei, die Frontmatter und Anweisungen enthält. Codex kann Skills aktivieren, wenn der Benutzer sie ausdrücklich aufruft oder wenn die Aufgabe zur Skill-Beschreibung passt.⁴ Codex liest Skills aus Repository-, Benutzer-, Admin- und Systemorten, darunter Repo-.agents/skills, $HOME/.agents/skills und /etc/codex/skills.⁴

Hier kann eine Claude-Code-Migration subtil falsch werden. Codex-Skills sind keine Claude-Slash-Befehle. Der offizielle Codex-Skill-Pfad für ausdrücklichen Aufruf ist der Skill-Selektor oder eine $skill-name-Erwähnung, während Codex-CLI-Slash-Befehle eine getrennte interaktive Bedienoberfläche für eingebaute Aktionen wie Status, Berechtigungen, Modellwechsel, Plugins und Sitzungssteuerung sind.⁴¹⁵ Ein Prompt wie /cave kann weiterhin als Kurzform nützlich sein, wenn die Skill-Beschreibung ihn erkennt oder ein Wrapper ihn in Use $cave ... verwandelt, aber der Slash-Text selbst ist nicht der dauerhafte Vertrag. Für Migrationsnachweise teste $skill-name; teste /name danach separat nur, wenn du diese Kompatibilität versprichst.

Das bedeutet, dass ich neue Codex-native Schreib-Skills in die offiziellen Skill-Pfade normalisieren sollte, ohne die privaten Skill-Namen oder Inhalte zu veröffentlichen:

$HOME/.agents/skills/source-verifier/SKILL.md
$HOME/.agents/skills/public-post-writer/SKILL.md
$HOME/.agents/skills/site-specific-writer/SKILL.md

Meine lokale Ausführungsumgebung hat auch funktionierende Benutzer-Skills an einem älteren Ort.¹ Ich sollte diese nicht löschen, nur weil die öffentliche Dokumentation .agents/skills nennt. Die sichere Migration ist:

1. Einen Skill nach $HOME/.agents/skills kopieren oder verlinken.
2. Codex neu starten.
3. Bestätigen, dass Codex den Skill auflistet und aktiviert.
4. Den Skill während des Piloten nur ausdrücklich aktivierbar machen.
5. Den Rest erst verschieben, nachdem Erkennung und Pilotnutzung funktionieren.
6. Den alten Pfad belassen, bis bestehende Sitzungen und Skripte nicht mehr davon abhängen.

Diesen Pfad nahm ich für den ersten privaten Schreibablauf. Ich stufte einen site-spezifischen Writer als privaten Skill nur für ausdrücklichen Aufruf ein, statt ihn zum Standard-Writer für jede Inhaltsaufgabe zu machen. Das gab der Migration einen besseren Test: Wenn der Skill diesen Artikel und den nächsten öffentlichen Schreiblauf verbessert, ohne private Prozesse offenzulegen, kann er vom ausdrücklichen Aufruf in den Pilotbetrieb wechseln. Wenn er Verwirrung stiftet, bleibt er eingegrenzt.

Markenspezifische Writer sollten keine Standard-Site-Writer werden. Ein privater Produkt-Writer kann dieselben Zitier- und Prüfstandards teilen, aber seine Zielgruppe, Produktfakten, Handlungsaufrufe und Stimmregeln sollten auf dieses Produkt begrenzt bleiben. Die richtige Portierung hält Markenadapter getrennt und erstellt einen dünnen site-spezifischen Writer für blakecrosley.com.

Dieser Site-Skill sollte dünn bleiben:

---
name: site-specific-writer
description: Write public technical posts for a specific site. Use for articles that need verified sources, internal links, site voice, and publication checks.
---

# Site-Specific Writer

Nutze die privaten Schreib-, Quellenprüfungs- und KI-Auffindbarkeits-Skills für jeden öffentlichen technischen Artikel.

Erforderlicher Nachweis vor Abschluss:
- Externe technische Behauptungen haben Zitate.
- Aktuelle Codex-Behauptungen zitieren OpenAI-Dokumentation.
- Interne Behauptungen verlinken auf bestehende Beiträge oder Autorenanalyse.
- Der Beitrag enthält, wenn nützlich, ein TL;DR, rollenbezogene Kernpunkte und Leserfragen.

Codex-Skill-Dokumente zeigen name und description als Frontmatter-Felder für manuelle Skills und machen die Beschreibung zum Auslöser für implizite Aktivierung.⁴ Der Körper kann Codex anweisen, private Begleit-Skills zu nutzen; Komposition gehört in Anweisungen, sofern keine lokale Werkzeugkette zusätzliche Metadaten hinzufügt. Der allgemeine Stapel besitzt die Schreibregeln. Der Site-Wrapper besitzt Stimme, Linkmuster und Nachweis.

Dieselbe Trennung gilt für den Migrationsablauf selbst. OpenAIs Plugin-Dokumentation empfiehlt, mit einem lokalen Skill zu beginnen, wenn man noch an einem persönlichen Arbeitsablauf iteriert, und erst dann ein Plugin zu bauen, wenn man ein stabiles Paket über Teams teilen oder mehr Integrationen bündeln will.¹⁰ Das machte den aktiven Pfad offensichtlich: zuerst Benutzer-Skill, danach privater Paketpilot. Ich habe den Migrations-Skill nicht quelloffen gemacht und keine öffentliche Veröffentlichung versprochen; wenn du ihn testen willst, kontaktiere mich. Eine Plugin-Cache-Prüfung zeigte, dass ein installierter Plugin-Skill unter einem Plugin-Namensraum erscheint statt unter dem bloßen Skill-Namen; Paketdokumentation sollte also direkte Skill-Nutzung von plugin-installierter Skill-Nutzung unterscheiden.⁸

Das private Paket braucht einen Validator, bevor es eine Veröffentlichungsgeschichte braucht. Im neuesten Durchlauf fügte ich einen Validator hinzu, der Marketplace-JSON, Plugin-Manifest, Skill-Frontmatter, erforderliche Referenzen, Syntax des Zitierprüfers, Installationsrichtlinie, Abwesenheit aktiver Hook- oder MCP-Manifeste, generierte Dateien und offensichtliche private Pfad- oder Geheimnis-Fixture-Lecks prüft. Diese Prüfung gehört vor jede breitere Aktivierung, weil OpenAIs Plugin-Dokumentation den Marketplace zur Installationsoberfläche macht, nicht zu einer Experimentierfläche für instabile private Arbeitsabläufe.⁸¹⁰

Wie sollte AGENTS.md Regeln für öffentliches Schreiben tragen?

Die stärkste Codex-Migrationsänderung gehört in AGENTS.md, nicht in einen Hook. Öffentliches Schreiben braucht eine Standard-Risikoklasse.

Diese Regel will ich weit oben in der globalen oder projektbezogenen Datei:

## Öffentliches Schreiben ist Produktarbeit

Öffentliche Artikel, Leitfäden, Landingpages, Dokumentation, die Nutzerverständnis prägt, und Produkttexte nutzen mindestens das Profil `default`. Wechsle zu `careful-review`, wenn Behauptungen, Zitate, Marke, Geld, Sicherheit, Schutz oder Nutzervertrauen auf dem Spiel stehen.

Vor Abschluss öffentlichen Schreibens:
- Zitate vor dem Entwurf sammeln.
- Offizielle Produktdokumentation für aktuelles Werkzeugverhalten zitieren.
- Autorenanalyse klar kennzeichnen.
- Eine Prüfung auf verbotene Phrasen ausführen.
- Interne Links verifizieren.
- Jede Behauptung melden, die nicht verifiziert werden konnte.

Diese Regel behebt den Fehler, den ich in der Router-Inventur fand. Manche Inhaltsarbeit war in Richtung schneller Ausführung abgedriftet, weil der Router „Content“ als billige Arbeit behandelte. Öffentliches Schreiben ist keine billige Arbeit, wenn es verändert, was Menschen glauben, kaufen, installieren oder ausführen. Blogentwürfe, Leitfäden und Produktseiten verdienen mehr Prüfung als Routine-Codeänderungen, weil der Fehlermodus öffentliches Vertrauen ist, nicht ein lokaler Testfehler.

Der Beitrag, den du liest, ist das Beispiel. Er zitiert aktuelle Codex-Dokumentation für aktuelles Codex-Verhalten. Er kennzeichnet lokale Inventurbehauptungen als Autorenanalyse. Er nutzt einen echten Stapel, statt so zu tun, als beginne die Migration auf einer leeren Maschine, hält aber private Umsetzungsdetails aus dem öffentlichen Artikel heraus.

Wie sollten Codex-Profile Risiko codieren?

OpenAIs Konfigurationsreferenz definiert profile als Standardprofil beim Start und unterstützt profilbezogene Überschreibungen für unterstützte Konfigurationsschlüssel.⁵ Dieselbe Referenz definiert model_reasoning_effort, approval_policy und sandbox_mode als ausdrückliche Konfigurationssteuerungen.⁵

Damit hat Codex einen natürlichen Ort, um Risiko zu kodieren.

[profiles.public-writing]
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
web_search = "live"

Das genaue Modell kann sich ändern. Die Richtlinie sollte es nicht. Öffentliches Schreiben braucht höheres Reasoning, Live-Quellenprüfung, wenn Fakten sich ändern können, arbeitsbereichsbegrenzte Ausführung und menschliche Freigabe für Aktionen, die den sicheren Arbeitspfad verlassen.

Der Router sollte Aufgaben wie diese auf public-writing oder careful-review abbilden:

• Ein Blogbeitrag, Leitfaden oder eine Homepage-Änderung.
• Jeder Artikel mit Zitaten.
• Jeder Inhalt, der Werkzeuge oder Anbieter vergleicht.
• Jeder Beitrag, der aktuelles Codex, Claude Code, OpenAI, Anthropic, Apple, Google oder ein anderes schnelllebiges Produkt nennt.
• Jede Arbeit an Schema, llms.txt, SEO, Analytics oder öffentlichen Metadaten.

Das Profil ist keine Stimmung. Das Profil ist ein Risikobudget.

Welche Codex-Hooks sind noch wichtig?

Codex-Hooks sollten die kleinen Dinge erzwingen, die zur Laufzeit geschehen müssen.

Ein Stop-Hook für öffentliches Schreiben könnte die geänderten Dateien prüfen und Abschluss verweigern, wenn ein öffentlicher Markdown-Beitrag Fußnotenverweise ohne Definitionen enthält. Ein Pre-Tool-Hook könnte warnen, wenn der Agent versucht, .env, Analytics-Zugangsdaten oder generierte Übersetzungscaches zu bearbeiten, während er einen Artikel schreibt. Ein Sitzungsstart-Hook könnte das aktuelle Datum hinzufügen und Codex daran erinnern, dass „neueste“ Behauptungen Verifikation brauchen.

Halte die Hook-Nutzlast klein. OpenAI dokumentiert JSON-Ausgabeformen für Hooks, darunter systemMessage, continue und ereignisspezifische Felder.² Nutze diese Felder, um exakte Fehler zu blockieren oder davor zu warnen. Baue nicht das ganze Claude-Dispatcher-Gitter neu, solange die Codex-Fehlerdaten nicht beweisen, dass du es brauchst.

Einrichtungstests verdienen keine Beförderung. Ein Hook verlässt den Piloten erst, nachdem eine Beobachtung im echten Einsatz drei Dinge zeigt: Er löst in den beabsichtigten Situationen aus, lässt gewöhnliche Arbeit passieren und zeichnet sichere aggregierte Telemetrie statt privater Inhalte auf. Wenn eine Blockade auslöst, muss der Grund dem Benutzer sagen, was als Nächstes zu tun ist.²⁸

Nach den ersten Live-Durchläufen sieht der praktische Hook-Rückstand so aus:

1. SessionStart: kompakten Kontext zu aktuellem Datum, Aktualität, Projekt und Öffentlich/Privat-Grenze im Piloten halten.
2. PreToolUse:Bash: die enge Leitplanke gegen destruktive Befehle und Zugangsdaten-Lesen im Piloten halten.
3. PostToolUse:apply_patch: den nicht blockierenden Qualitätsschatten auf geänderten Code-/Konfigurations-Patch-Zeilen halten.
4. Stop: die Zitierprüfung für geändertes öffentliches Markdown im Piloten halten.
5. Stop: den Endverifikationsvertrag in den vorhandenen Qualitäts-Stop-Piloten falten; keinen separaten Zusammenfassungs-Hook erstellen, bis echte Fehler den Bedarf beweisen.

Diese Menge portiert das Sicherheitsverhalten, ohne Monate Claude-spezifischer Zeremonie zu importieren.

Wie sollten MCP und Browser-Tools passen?

Mein aktuelles Codex-Setup nutzt bereits einen privaten MCP-gestützten Browserautomationspfad.¹ Codex unterstützt MCP-Server außerdem sowohl über die CLI als auch über config.toml: codex mcp add kann einen stdio-Server registrieren, und [mcp_servers.<server-name>]-Tabellen können Befehl, Argumente, Umgebung, URLs, enabled_tools, disabled_tools und Zeitüberschreitungen definieren.⁶

Für öffentliches Schreiben gehört MCP an zwei Stellen:

• Browserautomation zum Prüfen live gerenderter Seiten, Screenshots und lokaler Vorschauen.
• Quellenfindung oder Dokumentationsabruf, wenn ein bestimmter Anbieter einen verlässlichen MCP-Server bereitstellt.

MCP sollte die Quellenspur nicht verstecken. Ein Blog-Writer braucht Zitate, die ein Leser anklicken kann, nicht ein privates Werkzeugergebnis, das nur innerhalb der Sitzung existierte. MCP kann helfen, die Tatsache zu finden. Der endgültige Beitrag braucht weiterhin eine öffentliche Quelle.

Wie startest du eine Migration von Claude Code zu Codex?

Das erste Codex-native Artefakt sollte die Portierung beschreiben, während es die Portierung nutzt.

Hier ist die interaktive Bootstrapping-Schleife:

codex -p careful-review --search \
  "Inventory the local Codex and Claude migration surface, then create a citation bank for a sanitized post about moving the setup to Codex."

codex -p careful-review \
  "Draft content/blog/claude-code-to-codex-migration.md using the local inventory, official Codex docs, and existing internal posts. Label author analysis clearly."

codex -p careful-review \
  "Review the draft for unsupported claims, stale Codex flags, broken internal links, and AGENTS.md operational value."

Für nicht interaktive Arbeit nutze codex exec und mache Live-Suche zu einer Konfigurations- oder Profilfrage, statt das interaktive Flag --search zu kopieren. OpenAI dokumentiert codex exec für skriptartige oder CI-nahe Läufe, mit Überschreibungen für --profile, --sandbox und --config; meine lokale Hilfe für Codex CLI 0.130.0 bestätigt diese Flags und weist codex exec --search zurück.⁷⁸

codex exec -p careful-review -c 'web_search="live"' \
  "Create a citation bank for content/blog/claude-code-to-codex-migration.md from official Codex docs and sanitized local inventory."

codex exec -p careful-review \
  "Review content/blog/claude-code-to-codex-migration.md for unsupported Codex claims, stale flags, broken internal links, and AGENTS.md operational value."

Die Befehlszeilendetails zählen. OpenAI kennzeichnet --full-auto als veraltetes Kompatibilitätsflag und empfiehlt stattdessen --sandbox workspace-write.⁷ Alte Leitfäden, die --full-auto ins Zentrum stellen, sollten neue Automation nicht steuern.

Der Beitrag wird zum Akzeptanztest. Wenn Codex Folgendes kann:

• Die Schreib-Skills laden.
• careful-review nutzen.
• Aktuelle OpenAI-Dokumentation zitieren.
• Lokale Inventur nutzen, ohne private Umsetzungsdetails offenzulegen.
• Erklären, was sich in AGENTS.md, Skills, Hooks, Profilen und MCP ändert.
• Einen sauberen Markdown-Artikel im Site-Repo erzeugen.

Dann funktioniert die Schreibportierung.

Checkliste für die Migration von Claude Code zu Codex

Für die Codex-Konfiguration:

• ~/.codex/AGENTS.md mit globalen Arbeitsvereinbarungen hinzufügen oder aktualisieren.
• Repository-AGENTS.md-Regeln für öffentliches Schreiben hinzufügen.
• public-writing erstellen oder öffentliches Schreiben auf careful-review routen.
• Sicherstellen, dass careful-review für öffentliche Behauptungen tatsächlich hohes oder xhigh Reasoning nutzt.
• Eine Router-Regel hinzufügen, die Leitfäden, Blogbeiträge, Dokumentation und Produkttexte als öffentliche Oberfläche behandelt.

Für Skills:

• Private Schreib-Skills einzeln nach $HOME/.agents/skills verschieben oder spiegeln.
• Aktiv getestete Migrationsabläufe als Benutzer-Skills halten, bevor ein Plugin-Paket als Laufzeitpfad behandelt wird.
• $skill-name als kanonischen ausdrücklichen Aufruftest nutzen; /name als Komfort-Wrapper oder Auswahlgewohnheit behandeln, nicht als Beweis, dass ein Codex-Skill geladen wurde.
• Einen Paketbereitschafts-Validator vor Marketplace-Aktivierung hinzufügen.
• Eine Zustandsprüfung für das lokale Agentensystem hinzufügen, die AGENTS-Verweise, Profile, Skills, Hooks, Paketstatus, Registry-Form und Aktivierungszustand vor Beförderung beweist.
• Für Installationspiloten Marketplace-Add, Plugin-Lesen/-Installieren, Plugin-Listing, Skill-Listing, Skill-Sichtbarkeit in frischer Sitzung und Dublettenbereinigung im Marketplace verifizieren.
• Pilot-Skills nur ausdrücklich aktivierbar halten, bevor implizite Aktivierung erlaubt wird.
• Allgemeine Schreibstandards von site-spezifischer Stimme trennen.
• Quellenprüfung als harte Fakten-Prüfgrenze halten.
• KI-Auffindbarkeitsprüfungen von Autorenstimme trennen.
• Einen dünnen site-spezifischen Writer-Skill erstellen, statt einen markenspezifischen Writer wiederzuverwenden.
• Nach jeder Verschiebung bestätigen, dass Codex Skills entdeckt.

Für agentenübergreifende Zusammenarbeit:

• Codex als Eigentümer der Schleife halten.
• Reviews an echte Dateien oder Kontextartefakte ankern.
• Sicher schließen, wenn Anker fehlen, Ausgabe leer ist oder der zweite Agent zeitlich ausläuft.
• Nicht belegte Befunde des zweiten Agenten mit lokalen Nachweisen zurückweisen.
• Nur belegte Befunde akzeptieren, die kleinste Korrektur anwenden, statische Prüfung erneut ausführen und dann Codex-eigene Prüfungen laufen lassen.

Für Hooks:

• Zuerst nur deterministische Prüfungen portieren.
• SessionStart, PreToolUse, PostToolUse und Stop für enge Prüfgrenzen nutzen.
• Fehler protokollieren, bevor weitere Prüfgrenzen hinzugefügt werden.
• Für Schatten-Hooks Kategorien statt roher privater Inhalte protokollieren.
• Vor Beförderung ein bekannt schlechtes Fixture und ein bekannt lautes Fixture testen.
• Saubere Fehler von Bereinigungsschuld trennen, bevor eine migrierte Prüfung erzwungen wird.
• Hooks als Laufzeitprüfungen behandeln, nicht als kanonischen Doktrinspeicher.

Für den Schreibablauf:

• Zitate vor dem Entwurf sammeln.
• Offizielle Dokumentation für aktuelles Codex-Verhalten nutzen.
• Autorenanalyse für lokale Inventur und Erfahrung nutzen.
• Interne Beiträge verlinken, wo sie ein Konzept bereits erklären.
• Vor Abschluss Verifikation ausführen.
• Für Leitfadenpflege Quell- und Laufzeitbehauptungen verifizieren, abgeleitete öffentliche Oberflächen synchronisieren, Discovery-Dateien neu generieren und übersprungene Übersetzungs-, Deployment- und Live-Prüfungen benennen.
• Für übersetzte Leitfäden den ausgewählten Übersetzungsanbieter, Differenzbatch- oder Abschnittszahl, Zugangsdatenzustand ohne Werte, ob Schreibungen/Uploads erfolgten, Locale-Verifikation und den Nicht-Schreib-Grund bei blockierter Ausführung festhalten.
• Für Geheimnis- und Protokollhygiene ausführbaren Quelltext, Dokumentation, generierte Caches, Sitzungstranskripte, Shell-Schnappschüsse, Protokolle und absichtliche Geheimnisspeicher trennen; Historie redigieren und Helfer auf umgebungsabhängige Konfiguration umstellen, bevor ein migrierter Arbeitsablauf als sicher gilt.
• Nach Deployment kanonische URL, strukturierte Daten, Sitemap, llms-full.txt, Deployment-Zustand, CDN-Frische und geänderte Inhaltsmarker in Produktion verifizieren.
• Wenn ein CDN-Cache veraltete Inhalte ausliefert, nur die betroffenen öffentlichen URLs über den vorhandenen Deployment-Pfad purgen und dann die geänderten Marker erneut prüfen.

FAQ

Müssen private Schreib-Skills öffentlich sein?

Nein. Ein Migrationsartikel kann die Form des Schreibsystems beschreiben, ohne die privaten Skill-Namen, Prompts, Bewertungsdetails oder markenspezifischen Adapter zu veröffentlichen. Die öffentliche Lehre ist, wohin diese Skills gehören und wie Codex sie aktivieren sollte.

Für den Migrations-Skill gilt dieselbe Regel. Er ist heute privat, kein Open-Source-Paket. Wenn du den Arbeitsablauf testen willst, kontaktiere mich.

Sollte eine Claude-Code-zu-Codex-Migration markenspezifische Writer wiederverwenden?

Nein. Markenspezifische Writer sollten markenspezifisch bleiben. Eine persönliche oder Unternehmensseite braucht einen dünnen Site-Adapter, der Verifikationsstandards teilt, ohne Zielgruppe, Fakten oder Handlungsaufrufe eines anderen Produkts zu erben.

Sollte ich jeden Claude-Code-Hook nach Codex kopieren?

Nein. Kopiere Verhalten erst, nachdem du den Vertrag dahinter identifiziert hast. Eine Zugangsdaten-Blockade gehört in einen Hook. Eine Schreibrubrik gehört in einen Skill. Eine Risikoregel gehört in ein Profil oder einen Router. Eine Philosophie gehört in AGENTS.md plus einen fokussierten Skill.

Wo sollten Codex-Skills liegen?

Für neue Codex-native Arbeit nutze die offiziellen Skill-Orte: Repo-.agents/skills für Projekt-Skills und $HOME/.agents/skills für Benutzer-Skills.⁴ Wenn ein bestehendes lokales Setup auch ~/.codex/skills nutzt, behalte es, bis Codex-Erkennung bestätigt, dass der neue Ort funktioniert.

Warum scheitern /skill-Prompts in Codex manchmal?

Weil /skill nicht der kanonische Codex-Skill-Aufrufvertrag ist. Codex-Skills aktivieren sich, wenn du den Skill ausdrücklich auswählst oder erwähnst, einschließlich $skill-name, oder wenn die Aufgabe zur Skill-Beschreibung passt.⁴ Codex-CLI-Slash-Befehle sind ihre eigene eingebaute Befehlsoberfläche.¹⁵ Nutze $skill-name, wenn du deterministische Skill-Aktivierung brauchst. Behalte /name nur als Komfort-Wrapper, Auswahlgewohnheit oder Prompt-Phrase, die weiterhin eigenen Nachweis braucht.

Was ist das Herz einer Migration von Claude Code zu Codex?

Das Herz sind nicht Hooks, Skills oder Profile allein. Das Herz ist die Entscheidungsschicht, die vor Arbeitsbeginn vier Fragen beantwortet: Welche Art von Arbeit ist angekommen, welches Risikoprofil sollte sie ausführen, welche Anweisungen regeln sie und welcher Nachweis muss vor Abschluss existieren?

Kernpunkte

Für Codex-Nutzer: Portiere Verträge, nicht Verzeichnisse. AGENTS.md, Profile, Skills, MCP und Hooks haben jeweils eine Aufgabe. Lege jede Regel dort ab, wo Codex sie am direktesten beachtet.

Für Claude-Code-Nutzer, die wechseln: Behandle Codex-Hooks als Leitplanken, nicht als vollständigen Ersatz für ein ausgereiftes Claude-Dispatcher-System. Beginne mit AGENTS.md und Skills, füge dann Hooks dort hinzu, wo Laufzeitdurchsetzung zählt.

Für öffentliche Schreiber: Blogschreiben gehört in ein Profil mit hoher Prüfung. Aktuelle Behauptungen brauchen aktuelle Quellen. Ein polierter falscher Artikel beschädigt Vertrauen schneller als ein kaputtes lokales Skript.

Für meinen eigenen Stapel: Das private Schreibsystem ist nicht mehr nur inhaltlich portiert; der erste site-spezifische Writer ist nur für ausdrücklichen Aufruf gestuft, der Migrationsablauf ist als Benutzer-Skill aktiv, und das private Plugin-Paket hat einen lokalen Installationspiloten bestanden, ohne zur öffentlichen Veröffentlichung zu werden. Die Codex-Doktrin macht Qualität und Geschmack jetzt zur Betriebsregel. Die Endverifikationszusammenfassung blieb eine manuelle Schattenprüfung, deren enge deterministische Prüfung in den vorhandenen Qualitäts-Stop-Piloten gefaltet wurde, statt einen separaten Hook zu erzeugen. Ein kompakter SessionStart-Kontext-Hook ist im Piloten, der erste aktive Qualitäts-Hook beobachtet apply_patch-Änderungen im Schattenmodus, die erste Pre-Bash-Sicherheitsleitplanke läuft als enger blockierender Pilot, der Zitierprüfer läuft jetzt als Stop-Pilot für geändertes öffentliches Markdown, Leitfadenpflege-Durchläufe bewiesen die Quellen-bis-Render-Schleife an echten öffentlichen Dokumenten, ein Durchlauf korrigierte veraltete exakte Zählbehauptungen, statt alte Zahlen zur Quellinfrastruktur zu bewahren, ein weiterer fing eine Abweichung zwischen generierter und ausgelieferter KI-Auffindbarkeitsroute ab, jüngere Durchläufe korrigierten Modell-/Parameterkompatibilität, Benchmark-/Model-Card-Abweichung, schnelllebige Plugin-Veröffentlichungsabweichung, gerenderte FAQ-Strukturdaten-Abweichung, Kreditabrechnungs-Abweichung, ausschließlich drittanbieterbezogene API-/Rechts-/Feature-Mindestbehauptungen und Frontmatter-Slug-Routenabweichung, und die neuesten Codex-Leitfaden-Durchläufe machten Leitfadenübersetzung anbieterwählbar, nutzten Codex als Standardanbieter für Codex-eigene Arbeit, wiesen abgeschnittene Übersetzungsausgabe vor Cache-Schreibung zurück, schlossen Locale-Schreibungen ab, verifizierten Locale-Routen und lösten veraltete CDN-Antworten mit gezieltem Purge, statt still von einem Claude-only-Pfad abzuhängen. Ein begrenzter Geheimnis-/Protokollhygiene-Durchlauf trennte Quelltext, Dokumentation, generierte Caches, Sitzungsaufzeichnungen, Shell-Schnappschüsse, Protokolle und absichtliche Geheimnisspeicher, bevor Rotation, Redaktion und Präventions-Hook-Lücken festgehalten wurden. Die Veröffentlichungsschleife behandelt jetzt lokale Prüfungen, Deployment-Status, CDN-Frische und Live-Nachweis geänderter Marker als getrennte Prüfgrenzen. Ein Quellenintelligenz-Durchlauf bewies Probelauf-/Schreibvolumen-Disziplin vor privaten Speicher-Schreibungen, der Company-Blog-Onboarding-Pfad stoppt jetzt vor Dateigenerierung, solange Ziel/Pfad/Aufnahmebelege nicht ausdrücklich sind, der Blogübersetzer stoppt jetzt vor schreibender Ausführung, wenn D1-Zugangsdaten oder ein ausdrückliches Ziel fehlen, und verweigert rückstandsreiche Codex-Ausgabe vor Veröffentlichung, wenn Zugangsdaten vorhanden sind, eine agentenübergreifende Zusammenarbeitsschleife bewies Review/Behebung/Neuprüfung, ohne dem zweiten Agenten Autorität zu übergeben, und eine manuelle Zustandsprüfung des lokalen Agentensystems prüft die deterministische Beförderungsoberfläche vor jeder breiteren Aktivierung. Die nächste Arbeit besteht darin, die verbleibenden Produktionsrituale nur auf ausdrücklichen Aufruf weiter zu beweisen, die Grenze zur öffentlichen Veröffentlichung geparkt zu halten und echte öffentliche Schreib- und Engineering-Arbeit weiter durch die gestuften Bahnen laufen zu lassen, bevor irgendeine Prüfgrenze erweitert wird.

Quellen