Guide de migration de Claude Code vers Codex 2026

Le 3 mai 2026, j’ai inventorié 744 entrées locales de configuration d’agents, puis j’en ai classé 691 selon leur poids opérationnel.¹ Le chiffre semblait élevé. La forme comptait davantage : une vingtaine de fichiers portaient le système.

Une migration de Claude Code vers Codex doit transférer les contrats d’exploitation, pas copier l’arborescence. Déplacez les règles CLAUDE.md vers des AGENTS.md en couches, les procédures réutilisables vers des skills Codex, les seuils déterministes vers des hooks ciblés, la posture de risque vers des profils, et l’outillage navigateur/source vers du MCP explicite. Ne copiez pas un treillis de hooks Claude dans Codex ; déplacez les obligations de preuve.

TL;DR

La pile privée de rédaction et de vérification existe déjà dans mon monde Codex. La pièce manquante n’était pas le contenu des skills. La pièce manquante était le manuel d’exploitation public : où les skills réutilisables doivent vivre, comment Codex doit les sélectionner, quel profil doit exécuter la rédaction publique, et quelles barrières de l’époque Claude doivent devenir des règles natives Codex sans exposer les détails privés du flux de travail.

Le premier passage Codex réel a changé la règle de migration : ne rendez pas un flux de travail privé ambiant au moment où il est transféré. Échelonnez-le. Mon chemin de rédaction propre au site commence maintenant en mode explicite seulement, tandis que le flux de migration vit comme skill utilisateur pour un usage local actif et comme candidat de paquet Codex privé pour les tests locaux. Ce paquet n’est pas open source ni généralement disponible ; si vous voulez tester le flux de migration, contactez-moi. Le paquet ne doit pas devenir le chemin d’exécution par défaut simplement parce qu’une entrée d’installation locale existe. Un vrai pilote d’installation doit encore valider le paquet, vérifier l’installation du plugin, vérifier la découverte des skills avec espace de noms, nettoyer les doublons, et lancer une session Codex fraîche avant que cela signifie quoi que ce soit. Cela laisse le système apprendre du vrai travail avant qu’un flux de travail devienne un comportement par défaut.¹⁸¹⁰¹⁴

Ne commencez pas par cloner chaque hook Claude dans Codex. Commencez par écrire le contrat Codex :

• Mettez la politique inter-dépôts durable dans ~/.codex/AGENTS.md.
• Mettez la politique du dépôt dans AGENTS.md, et placez les surcharges plus étroites près du travail.
• Mettez les procédures réutilisables dans .agents/skills ou $HOME/.agents/skills.
• Promouvez la rédaction publique vers careful-review ou un profil dédié public-writing.
• Gardez les barrières déterministes comme hooks, mais traitez les hooks comme un garde-fou, pas comme tout le modèle de sécurité.

Le premier artefact de migration réussi doit être un article auto-descriptif. Cet artefact prouve que le système peut se décrire, citer la documentation actuelle, utiliser un inventaire local assaini, et produire un travail public sous contrôle Codex sans publier la mécanique privée derrière lui.

J’ai couvert le côté Claude de la pile dans Claude Code as Infrastructure, le côté fichiers d’instructions dans AGENTS.md Patterns, et le problème de déclin des skills dans Static Skills Are Dead Skills. La migration ci-dessous relie ces fils à l’environnement d’exécution Codex que j’utilise réellement.

Pour le contexte adjacent, lisez le guide Codex CLI, Claude Code vs Codex, Codex vs Claude Code 2026, Claude Code Hooks Tutorial, Building Custom Skills, et Jiro Quality Philosophy. Ces articles expliquent les pièces que la migration assemble ici.

Que montrait l’inventaire de migration ?

Le système local avait trois centres de gravité.

Les données d’utilisation pointaient vers la même conclusion. Mes journaux de routage de profils montraient que le travail lourd en revue dominait l’exécution courante.¹ Le vrai cœur n’était pas le fichier le plus long ni le script le plus astucieux. Le cœur était la couche de décision qui choisissait le niveau de risque, chargeait la doctrine, et imposait les preuves avant l’achèvement.

Ce constat change le transfert.

Si l’important avait été « Claude a beaucoup de hooks », la migration aurait copié les hooks. Si l’important avait été « le système a une philosophie », la migration aurait copié la prose. L’inventaire a montré une autre réponse : l’important est un petit contrat qui se déclenche au bon moment.

Qu’avons-nous fait avant publication ?

L’article lui-même est devenu le premier exercice de migration.

D’abord, j’ai cartographié la forme de la configuration Claude Code mature : quelles pièces gouvernaient le comportement, quelles pièces documentaient seulement des préférences, et quelles pièces devaient rester privées. Ensuite, j’ai vérifié le comportement actuel de Codex contre la documentation officielle et le CLI local, parce que les guides de migration vieillissent vite quand ils héritent d’anciens indicateurs ou de formes de configuration non prises en charge. Puis j’ai rédigé cet article avec la vraie migration en tête, mais en réduisant le détail public à une architecture assainie, pas à l’implémentation privée.

L’étape suivante arrive avant publication : utiliser ce guide pour construire la configuration Codex, puis réviser l’article à partir de ce qui a réellement changé. L’article public doit montrer le modèle de migration et les critères d’acceptation. Il ne doit pas publier de prompts privés, de flux de rédaction privés, d’internes exacts de hooks, de chemins sensibles, ni quoi que ce soit qui permettrait à un lecteur de reconstruire le système privé.

Le passage réel a produit un tableau de preuves publiable. Je publie seulement le contrat, l’état d’activation et le signal d’acceptation, pas les prompts privés, les corps exacts des hooks ni les internes du flux de rédaction.

Faut-il commencer une migration Codex par les hooks ?

Claude m’a appris à penser en événements de cycle de vie. Un hook UserPromptSubmit peut injecter le contexte du projet. Un hook PreToolUse peut bloquer des chemins sensibles. Un hook Stop peut refuser un achèvement faible. Ce modèle fonctionne dans Claude parce que ma pile locale s’est développée autour de répartiteurs qui transforment beaucoup de petits scripts en un pipeline d’événements ordonné.¹¹

Codex a aussi des hooks, mais Codex actuel les traite comme un système de cycle de vie derrière fonctionnalité activée plutôt que comme un répertoire de hooks toujours actif. La documentation hooks d’OpenAI montre [features] codex_hooks = true dans config.toml, et mon codex features list local rapporte hooks comme stable et activé sur Codex CLI 0.130.0.²⁸ OpenAI documente l’entrée des hooks comme JSON sur stdin, avec des champs partagés comme l’id de session, le répertoire de travail, le nom d’événement et le modèle actif.² Codex prend en charge des événements comme SessionStart, PreToolUse, PermissionRequest, PostToolUse, UserPromptSubmit et Stop ; PreToolUse peut intercepter Bash, apply_patch et les appels d’outils MCP.²

La même documentation donne aussi l’avertissement qui compte pour la migration : PreToolUse reste un garde-fou, pas une frontière d’application complète. Les docs notent que l’interception ne couvre pas tous les chemins shell et n’intercepte pas la recherche web ni d’autres appels non-shell et non-MCP.²

Cette limite ne rend pas les hooks Codex faibles. Elle signifie que les hooks ne doivent pas porter tout le transfert. OpenAI note aussi que plusieurs hooks de commande correspondants pour le même événement se lancent en parallèle, donc un transfert Codex qui exige un ordre a encore besoin d’un répartiteur ou d’une seule commande hook combinée.²

Pour Codex, je veux des hooks pour des contrôles déterministes étroits :

• Bloquer les commandes shell évidemment destructrices.
• Avertir sur les chemins en forme d’identifiants.
• Ajouter un petit contexte au démarrage de session.
• Enregistrer les preuves des exécutions de rédaction publique.
• Faire échouer un événement stop lorsqu’un artefact requis ou une commande de vérification manque.

Je ne veux pas que les hooks portent la voix de rédaction, la politique de citation, la philosophie, le routage ou la doctrine projet. Codex a déjà de meilleurs endroits pour cela.

Comment les artefacts Claude se mappent-ils à Codex ?

La migration devient plus propre quand chaque artefact Claude correspond à la primitive Codex qui convient le mieux à son rôle.

La documentation AGENTS.md d’OpenAI fait de la première ligne l’épine dorsale de la migration. Codex lit les fichiers AGENTS.md avant le travail, superpose les consignes globales du répertoire home Codex, puis parcourt de la racine du projet vers le répertoire courant, laissant les fichiers plus proches surcharger les consignes précédentes.³ Ce comportement correspond à ce dont j’ai réellement besoin de CLAUDE.md : des accords de travail persistants plus des spécificités locales au projet.

Le geste important : réécrire les règles comme opérations. « Écrire avec soin » n’a pas sa place dans AGENTS.md. « Pour les articles publics, rassembler les citations d’abord, vérifier les URL, exécuter les contrôles d’expressions interdites, et signaler toute affirmation non vérifiée » y a sa place.

Comment les skills d’écriture privées doivent-elles passer à Codex ?

La pile de rédacteur de blog se transfère proprement parce qu’elle a déjà la bonne forme. Une skill Codex est un dossier avec un fichier SKILL.md qui contient du frontmatter et des instructions. Codex peut activer des skills quand l’utilisateur les invoque explicitement ou quand la tâche correspond à la description de la skill.⁴ Codex lit les skills depuis des emplacements dépôt, utilisateur, admin et système, y compris .agents/skills du dépôt, $HOME/.agents/skills et /etc/codex/skills.⁴

C’est là qu’une migration Claude Code peut se tromper subtilement. Les skills Codex ne sont pas des commandes slash Claude. Le chemin officiel Codex pour l’invocation explicite d’une skill est le sélecteur de skill ou une mention $skill-name, tandis que les commandes slash Codex CLI sont une surface interactive séparée pour des actions intégrées comme statut, permissions, changements de modèle, plugins et contrôle de session.⁴¹⁵ Un prompt comme /cave peut encore être un raccourci utile si la description de la skill le reconnaît ou si une enveloppe le transforme en Use $cave ..., mais le texte slash lui-même n’est pas le contrat durable. Pour la preuve de migration, testez $skill-name ; puis testez /name séparément seulement si vous promettez cette compatibilité.

Cela signifie que je dois normaliser les nouvelles skills de rédaction natives Codex dans les chemins de skills officiels sans publier les noms ni les contenus des skills privées :

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

Mon environnement d’exécution local a aussi des skills utilisateur fonctionnelles dans un emplacement plus ancien.¹ Je ne dois pas les supprimer simplement parce que les docs publiques nomment .agents/skills. La migration sûre est :

1. Copier ou lier symboliquement une skill dans $HOME/.agents/skills.
2. Redémarrer Codex.
3. Confirmer que Codex liste et active la skill.
4. Rendre la skill explicite seulement pendant le pilote.
5. Déplacer le reste seulement après que la découverte et l’usage pilote fonctionnent.
6. Laisser l’ancien chemin en place jusqu’à ce que les sessions et scripts existants n’en dépendent plus.

C’est le chemin que j’ai pris pour le premier flux de rédaction privé. J’ai échelonné un rédacteur propre au site comme skill privée explicite seulement au lieu d’en faire le rédacteur par défaut pour chaque tâche de contenu. Cela a donné à la migration un meilleur test : si la skill améliore cet article et la prochaine exécution de rédaction publique sans fuite de processus privé, elle peut passer d’explicite seulement à pilote. Si elle ajoute de la confusion, elle reste bornée.

Les rédacteurs propres à une marque ne doivent pas devenir des rédacteurs de site par défaut. Un rédacteur privé de produit peut partager les mêmes standards de citation et de revue, mais son audience, ses faits produit, ses appels à l’action et ses règles de voix doivent rester bornés à ce produit. Le transfert correct garde les adaptateurs de marque séparés et crée un rédacteur fin propre à blakecrosley.com.

Cette skill de site doit rester fine :

---
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

Utilise les skills privées de rédaction, de vérification des sources et de découvrabilité IA pour chaque article technique public.

Preuves requises avant final :
- Les affirmations techniques externes ont des citations.
- Les affirmations Codex actuelles citent la documentation OpenAI.
- Les affirmations internes lient vers des articles existants ou vers une analyse de l'auteur.
- L'article inclut un TL;DR, des enseignements par rôle et des questions de lecteurs quand utile.

Les docs des skills Codex montrent name et description comme champs frontmatter manuels de skill, et font de la description le déclencheur d’activation implicite.⁴ Le corps peut dire à Codex d’utiliser des skills privées compagnes ; la composition appartient aux instructions sauf si une chaîne d’outils locale ajoute des métadonnées supplémentaires. La pile générale possède les règles de rédaction. L’enveloppe de site possède la voix, les modèles de liens et la preuve.

La même séparation s’applique au flux de migration lui-même. Les docs plugins d’OpenAI recommandent de commencer par une skill locale quand vous itérez encore sur un flux personnel, puis de construire un plugin quand vous voulez partager un paquet stable entre équipes ou regrouper plus d’intégrations.¹⁰ Cela a rendu le chemin actif évident : skill utilisateur d’abord, pilote de paquet privé ensuite. Je n’ai pas open-sourcé la skill de migration ni promis de publication publique ; si vous voulez la tester, contactez-moi. Une sonde de cache plugin a montré qu’une skill de plugin installé apparaît sous un espace de noms plugin plutôt que sous le nom nu de la skill, donc la documentation du paquet doit distinguer l’usage direct de la skill de l’usage de skill installée via plugin.⁸

Le paquet privé a besoin d’un validateur avant d’avoir besoin d’une histoire de lancement. Dans le dernier passage, j’ai ajouté un validateur qui vérifie le JSON de marketplace, le manifeste plugin, le frontmatter de skill, les références requises, la syntaxe du vérificateur de citations, la politique d’installation, l’absence de manifestes actifs de hook ou MCP, les fichiers générés et les fuites évidentes de chemins privés ou de fixtures de secrets. Ce contrôle appartient avant toute activation plus large parce que les docs plugins d’OpenAI font de la marketplace la surface d’installation, pas une zone de brouillon pour flux de travail privé instable.⁸¹⁰

Comment AGENTS.md doit-il porter les règles d’écriture publique ?

Le changement de migration Codex le plus fort appartient à AGENTS.md, pas à un hook. La rédaction publique a besoin d’une classe de risque par défaut.

Voici la règle que je veux près du haut du fichier global ou projet :

## La Rédaction Publique Est Un Travail Produit

Les articles publics, guides, pages d'accueil, docs qui façonnent la compréhension utilisateur et textes produit utilisent au minimum le profil `default`. Promouvoir vers `careful-review` lorsque des affirmations, citations, marque, argent, sécurité, sûreté ou confiance utilisateur sont en jeu.

Avant de terminer la rédaction publique :
- Rassembler les citations avant de rédiger.
- Citer les docs produit officielles pour le comportement actuel des outils.
- Étiqueter clairement l'analyse de l'auteur.
- Exécuter une recherche d'expressions interdites.
- Vérifier les liens internes.
- Signaler toute affirmation qui n'a pas pu être vérifiée.

Cette règle corrige la faille que j’ai trouvée dans l’inventaire du routeur. Une partie du travail de contenu avait dérivé vers une exécution rapide parce que le routeur traitait le « contenu » comme un travail bon marché. La rédaction publique n’est pas bon marché quand elle change ce que les gens croient, achètent, installent ou exécutent. Les brouillons de blog, guides et pages produit méritent plus de revue que des modifications de code courantes parce que le mode de défaillance est la confiance publique, pas un test local échoué.

L’article que vous lisez est l’exemple. Il cite les docs Codex actuelles pour le comportement Codex actuel. Il étiquette les affirmations d’inventaire local comme analyse de l’auteur. Il utilise une vraie pile au lieu de prétendre que la migration commence depuis une machine vide, mais garde les détails d’implémentation privés hors de l’article public.

Comment les profils Codex doivent-ils encoder le risque ?

La référence de configuration OpenAI définit profile comme profil par défaut au démarrage et prend en charge des surcharges par profil pour les clés de configuration prises en charge.⁵ La même référence définit model_reasoning_effort, approval_policy et sandbox_mode comme contrôles de configuration explicites.⁵

Cela donne à Codex un endroit naturel pour encoder le risque.

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

Le modèle exact peut changer. La politique ne doit pas changer. La rédaction publique a besoin d’un raisonnement plus élevé, d’une vérification de sources réelles quand les faits peuvent changer, d’une exécution limitée à l’espace de travail, et d’une approbation humaine pour les actions qui sortent du chemin sûr de travail.

Le routeur doit envoyer des tâches comme celles-ci vers public-writing ou careful-review :

• Un article de blog, guide ou changement de page d’accueil.
• Tout article avec citations.
• Tout contenu qui compare des outils ou fournisseurs.
• Tout article qui nomme Codex, Claude Code, OpenAI, Anthropic, Apple, Google actuels, ou un autre produit qui évolue vite.
• Tout travail qui touche schema, llms.txt, SEO, analytics ou métadonnées publiques.

Le profil n’est pas une ambiance. Le profil est un budget de risque.

Quels hooks Codex comptent encore ?

Les hooks Codex doivent faire respecter les petites choses qui doivent arriver à l’exécution.

Un hook stop de rédaction publique pourrait vérifier les fichiers modifiés et refuser l’achèvement si un article Markdown public contient des références de notes sans définitions. Un hook avant outil pourrait avertir si l’agent essaie de modifier .env, des identifiants analytics ou des caches de traduction générés pendant l’écriture d’un article. Un hook de démarrage de session pourrait ajouter la date courante et rappeler à Codex que les affirmations « latest » exigent vérification.

Gardez la charge utile du hook petite. OpenAI documente les formes de sortie JSON pour les hooks, y compris systemMessage, continue et des champs propres aux événements.² Utilisez ces champs pour bloquer ou avertir sur des échecs exacts. Ne reconstruisez pas tout le treillis de répartiteurs Claude sauf si les données d’échec Codex prouvent que vous en avez besoin.

Les tests de configuration ne méritent pas une promotion. Un hook sort du pilote seulement après qu’une passe d’observation en usage réel montre trois choses : il se déclenche dans les situations prévues, il laisse passer le travail ordinaire, et il enregistre une télémétrie agrégée sûre plutôt que du contenu privé. Si un blocage se déclenche, la raison doit dire à l’utilisateur quoi faire ensuite.²⁸

Après les premiers passages réels, l’arriéré pratique des hooks ressemble à ceci :

1. SessionStart : garder en pilote le contexte compact de date courante, fraîcheur, projet et frontière public/privé.
2. PreToolUse:Bash : garder en pilote la garde étroite contre commandes destructrices et lecture d’identifiants.
3. PostToolUse:apply_patch : garder le miroir de qualité non bloquant sur les lignes de patch code/config modifiées.
4. Stop : garder en pilote la barrière de citations pour Markdown public modifié.
5. Stop : garder le contrat de vérification finale plié dans le pilote Stop de qualité existant ; ne pas créer de hook de résumé séparé tant que de vrais échecs ne prouvent pas le besoin.

Cet ensemble transfère le comportement de sécurité sans importer des mois de cérémonie propre à Claude.

Comment MCP et les outils de navigateur doivent-ils s’insérer ?

Ma configuration Codex actuelle utilise déjà un chemin privé d’automatisation navigateur soutenu par MCP.¹ Codex prend aussi en charge les serveurs MCP via le CLI et config.toml : codex mcp add peut enregistrer un serveur stdio, et les tables [mcp_servers.<server-name>] peuvent définir command, args, environment, URLs, enabled_tools, disabled_tools et timeouts.⁶

Pour la rédaction publique, MCP appartient à deux endroits :

• Automatisation navigateur pour vérifier les pages réelles rendues, captures d’écran et aperçus locaux.
• Découverte de sources ou récupération de docs quand un fournisseur précis expose un serveur MCP fiable.

MCP ne doit pas cacher la trace des sources. Un rédacteur de blog a besoin de citations qu’un lecteur peut cliquer, pas d’un résultat d’outil privé qui n’a existé que dans la session. MCP peut aider à trouver le fait. L’article final a encore besoin d’une source publique.

Comment amorcer une migration de Claude Code vers Codex ?

Le premier artefact natif Codex doit décrire le transfert tout en utilisant le transfert.

Voici la boucle interactive d’amorçage :

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."

Pour le travail non interactif, utilisez codex exec et faites de la recherche réelle une affaire de configuration/profil plutôt que de copier l’indicateur interactif --search. OpenAI documente codex exec pour les exécutions scriptées ou de type CI, avec des surcharges --profile, --sandbox et --config ; l’aide de mon Codex CLI 0.130.0 local confirme ces indicateurs et rejette codex exec --search.⁷⁸

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."

Les détails de ligne de commande comptent. OpenAI marque --full-auto comme indicateur de compatibilité obsolète et recommande --sandbox workspace-write à la place.⁷ Les anciens guides centrés sur --full-auto ne doivent pas contrôler la nouvelle automatisation.

L’article devient le test d’acceptation. Si Codex peut :

• Charger les skills de rédaction.
• Utiliser careful-review.
• Citer les docs OpenAI actuelles.
• Utiliser l’inventaire local sans exposer de détails d’implémentation privés.
• Expliquer ce qui change dans AGENTS.md, les skills, hooks, profils et MCP.
• Produire un article Markdown propre dans le dépôt du site.

Alors le transfert de rédaction fonctionne.

Liste de contrôle de migration de Claude Code vers Codex

Pour la configuration Codex :

• Ajouter ou mettre à jour ~/.codex/AGENTS.md avec les accords de travail globaux.
• Ajouter des règles AGENTS.md de dépôt pour la rédaction publique.
• Créer public-writing ou router la rédaction publique vers careful-review.
• Faire en sorte que careful-review utilise vraiment un raisonnement high ou xhigh pour les affirmations publiques.
• Ajouter une règle de routeur qui traite guides, articles de blog, docs et textes produit comme du travail de surface publique.

Pour les skills :

• Déplacer ou refléter les skills privées de rédaction vers $HOME/.agents/skills une à la fois.
• Garder les flux de migration testés activement comme skills utilisateur avant de traiter un paquet plugin comme chemin d’exécution.
• Utiliser $skill-name comme test canonique d’invocation explicite ; traiter /name comme enveloppe pratique ou habitude de sélection, pas comme preuve qu’une skill Codex a chargé.
• Ajouter un validateur de préparation de paquet avant activation marketplace.
• Ajouter une barrière de santé du cadre d’agent qui prouve les références AGENTS, profils, skills, hooks, état de paquet, forme du registre et état d’activation avant promotion.
• Pour les pilotes d’installation, vérifier ajout marketplace, lecture/installation plugin, liste plugin, liste skills, visibilité des skills en session fraîche et nettoyage des doublons marketplace.
• Garder les skills pilotes explicites seulement avant d’autoriser l’activation implicite.
• Garder les standards génériques de rédaction séparés de la voix propre au site.
• Garder la vérification des sources comme barrière factuelle dure.
• Garder les contrôles de découvrabilité IA séparés de la voix auteur.
• Créer une skill fine de rédacteur propre au site au lieu de réutiliser un rédacteur propre à une marque.
• Confirmer que Codex découvre les skills après chaque déplacement.

Pour la collaboration inter-agents :

• Garder Codex propriétaire de la boucle.
• Ancrer les revues à de vrais fichiers ou artefacts de contexte.
• Échouer fermé quand les ancres manquent, que la sortie est vide ou que le second agent dépasse le délai.
• Rejeter les constats non étayés du second agent avec des preuves locales.
• Accepter seulement les constats fondés, appliquer la plus petite correction, relancer la revue statique, puis exécuter les contrôles possédés par Codex.

Pour les hooks :

• Transférer seulement les contrôles déterministes d’abord.
• Utiliser SessionStart, PreToolUse, PostToolUse et Stop pour des barrières étroites.
• Journaliser les échecs avant d’ajouter plus de barrières.
• Pour les hooks miroirs, journaliser des catégories au lieu du contenu privé brut.
• Tester une fixture connue mauvaise et une fixture connue bruyante avant promotion.
• Séparer les échecs propres de la dette de nettoyage avant d’appliquer un contrôle migré.
• Traiter les hooks comme contrôles d’exécution, pas comme magasin canonique de doctrine.

Pour le flux de rédaction :

• Rassembler les citations avant rédaction.
• Utiliser les docs officielles pour le comportement Codex actuel.
• Utiliser l’analyse de l’auteur pour l’inventaire et l’expérience locaux.
• Lier les articles internes lorsqu’ils expliquent déjà un concept.
• Exécuter la vérification avant final.
• Pour la maintenance de guides, vérifier les affirmations source et exécution, synchroniser les surfaces publiques dérivées, régénérer les fichiers de découverte, et nommer les contrôles de traduction, déploiement et réel sautés.
• Pour les guides traduits, enregistrer le fournisseur de traduction choisi, le lot différentiel ou le nombre de sections, l’état des identifiants sans valeurs, si des écritures/téléversements ont eu lieu, la vérification de locale, et la raison de non-écriture quand l’exécution est bloquée.
• Pour l’hygiène des secrets et journaux, séparer source exécutable, docs, caches générés, transcriptions de session, instantanés shell, journaux et magasins de secrets intentionnels ; expurger l’historique et convertir les aides en configuration requise par environnement avant de traiter un flux migré comme sûr.
• Après déploiement, vérifier l’URL canonique, les données structurées, le sitemap, llms-full.txt, l’état de déploiement, la fraîcheur CDN et les marqueurs de contenu changé en production.
• Si un cache CDN sert du contenu périmé, purger seulement les URL publiques affectées via le chemin de déploiement existant, puis revérifier les marqueurs changés.

FAQ

Les skills d’écriture privées doivent-elles être publiques ?

Non. Un article de migration peut décrire la forme du système de rédaction sans publier les noms des skills privées, prompts, détails de scoring ou adaptateurs propres aux marques. La leçon publique est où ces skills appartiennent et comment Codex doit les activer.

La skill de migration suit la même règle. Elle est privée aujourd’hui, pas un paquet open source. Si vous voulez tester le flux de travail, contactez-moi.

Une migration de Claude Code vers Codex doit-elle réutiliser des rédacteurs propres à une marque ?

Non. Les rédacteurs propres à une marque doivent rester propres à cette marque. Un site personnel ou d’entreprise a besoin d’un adaptateur de site fin qui partage les standards de vérification sans hériter de l’audience, des faits ou des appels à l’action d’un autre produit.

Dois-je copier chaque hook Claude Code dans Codex ?

Non. Copiez le comportement seulement après avoir identifié le contrat derrière lui. Un blocage d’identifiants appartient à un hook. Une grille de rédaction appartient à une skill. Une règle de risque appartient à un profil ou routeur. Une philosophie appartient à AGENTS.md plus une skill ciblée.

Où les skills Codex doivent-elles vivre ?

Pour du nouveau travail natif Codex, utilisez les emplacements officiels des skills : .agents/skills du dépôt pour les skills projet et $HOME/.agents/skills pour les skills utilisateur.⁴ Si une configuration locale existante utilise aussi ~/.codex/skills, gardez-la jusqu’à ce que la découverte Codex confirme que le nouvel emplacement fonctionne.

Pourquoi les prompts /skill échouent-ils parfois dans Codex ?

Parce que /skill n’est pas le contrat canonique d’invocation de skill Codex. Les skills Codex s’activent quand vous sélectionnez ou mentionnez explicitement la skill, y compris $skill-name, ou quand la tâche correspond à la description de la skill.⁴ Les commandes slash Codex CLI sont leur propre surface de commandes intégrées.¹⁵ Utilisez $skill-name quand vous avez besoin d’une activation déterministe de skill. Gardez /name seulement comme enveloppe pratique, habitude de sélection ou phrase de prompt qui nécessite encore sa propre preuve.

Quel est le cœur d’une migration de Claude Code vers Codex ?

Le cœur n’est pas les hooks, skills ou profils seuls. Le cœur est la couche de décision qui répond à quatre questions avant que le travail commence : quel type de travail est arrivé, quel profil de risque doit l’exécuter, quelles instructions le gouvernent, et quelle preuve doit exister avant l’achèvement ?

Points clés

Pour les utilisateurs Codex : Transférez des contrats, pas des répertoires. AGENTS.md, profils, skills, MCP et hooks ont chacun un rôle. Placez chaque règle là où Codex l’honorera le plus directement.

Pour les utilisateurs Claude Code qui migrent : Traitez les hooks Codex comme des garde-fous, pas comme un remplacement complet d’un système mature de répartiteurs Claude. Commencez par AGENTS.md et les skills, puis ajoutez les hooks là où l’application à l’exécution compte.

Pour les rédacteurs publics : La rédaction de blog appartient à un profil à forte revue. Les affirmations actuelles ont besoin de sources actuelles. Un article poli mais faux abîme la confiance plus vite qu’un script local cassé.

Pour ma propre pile : Le système privé de rédaction n’est plus seulement transféré en substance ; le premier rédacteur propre au site est échelonné comme explicite seulement, le flux de migration est actif comme skill utilisateur, et le paquet plugin privé a passé un pilote d’installation local sans devenir une publication publique. La doctrine Codex fait maintenant de la qualité et du goût une règle d’exploitation. Le résumé de vérification finale est resté une revue miroir manuelle, avec son contrôle déterministe étroit plié dans le pilote Stop de qualité existant au lieu d’un hook séparé. Un hook compact de contexte SessionStart est en pilote, le premier hook actif de qualité observe les changements apply_patch en mode miroir, le premier garde-fou pre-Bash fonctionne comme pilote bloquant étroit, le vérificateur de citations fonctionne maintenant comme pilote Stop de Markdown public modifié, les passages de maintenance de guides ont prouvé la boucle source-vers-rendu sur de vraies docs publiques, un passage a corrigé des affirmations périmées de décompte exact au lieu de préserver d’anciens chiffres de cadre source, un autre a attrapé une divergence de route de découverte IA générée contre servie, des passages récents ont corrigé compatibilité modèle/paramètre, dérive de benchmarks/model cards, dérive rapide de publication plugin, dérive de données structurées FAQ rendues, dérive de comptabilité des crédits, affirmations API/légales/minimum fonctionnel seulement tierces, et dérive de routes par slug frontmatter, et les derniers passages du guide Codex ont rendu la traduction de guide sélectionnable par fournisseur, utilisé Codex comme fournisseur par défaut pour le travail possédé par Codex, rejeté les sorties de traduction tronquées avant écriture cache, complété les écritures de locales, vérifié les routes de locales, et résolu les réponses CDN périmées par purge ciblée au lieu de dépendre silencieusement d’un chemin seulement Claude. Une passe bornée d’hygiène secrets/journaux a séparé source, docs, caches générés, enregistrements de session, instantanés shell, journaux et magasins de secrets intentionnels avant d’enregistrer rotation, expurgation et manques de hooks de prévention. La boucle de publication traite maintenant les contrôles locaux, l’état de déploiement, la fraîcheur CDN et la preuve de marqueurs changés réels comme des barrières séparées. Une passe de veille des sources a prouvé la discipline de simulation/volume d’écriture avant les écritures en mémoire privée, le chemin d’intégration de blog d’entreprise s’arrête maintenant avant génération de fichiers sauf si cible/chemin/preuves d’admission sont explicites, le traducteur de blog s’arrête maintenant avant exécution d’écriture quand les identifiants D1 ou une cible explicite manquent et refuse les sorties Codex lourdes en résidus avant publication lorsque les identifiants sont présents, une boucle de collaboration inter-agents a prouvé revue/correction/revérification sans remettre l’autorité au second agent, et une barrière manuelle de santé du cadre d’agent vérifie la surface déterministe de promotion avant toute activation plus large. Le prochain travail consiste à continuer de prouver les rituels de production restants en explicite seulement, garder la frontière de publication publique en pause, et continuer de faire passer du vrai travail de rédaction publique et d’ingénierie par les voies échelonnées avant d’élargir une barrière.

Références