Claude Code et Codex dans le Même Dépôt : Ma Configuration Réelle

Claude Code et Codex dans le Même Dépôt : Ma Configuration Réelle

J'étais un fidèle de Claude Code. Pas de manière tribale — plutôt dans le sens « c'est l'agent en qui j'ai confiance, celui que j'ai affiné, la mémoire musculaire est en place ». Anthropic publiait une mise à jour, je l'installais. Anthropic avait une panne, j'attendais. L'idée d'exécuter un deuxième CLI en parallèle ressemblait à une trahison envers un outil qui avait mérité sa place dans mon flux de travail.

Puis le mois dernier, un mercredi après-midi, la page de statut de l'API de Claude est passée à l'orange. Puis au rouge. Aria — mon agente de contenu — était à mi-chemin d'un lot de quatre publications. Je suis resté assis là pendant 47 minutes à regarder le spinner tourner. Le temps que l'API revienne, j'avais perdu la matinée et la patience de rester un ingénieur à CLI unique.

Alors j'ai fait ce que j'évitais depuis un moment. J'ai ouvert un deuxième panneau de terminal, lancé codex dans le même dépôt, et j'ai commencé à m'apprendre comment vivre réellement dans les deux écosystèmes en même temps. Pas la version marketing où l'on « compare » les deux outils et on choisit un gagnant. La version ennuyeuse et granulaire où l'on exécute les deux, sur la même base de code, avec le même contexte de projet, avec des skills qui fonctionnent majoritairement dans l'un ou l'autre des CLIs, et une astuce de transfert de session qui permet de passer le travail entre eux quand l'un reste bloqué.

C'est le sujet de cet article. Pas « Claude Code vs Codex. » C'est « Claude Code et Codex, dans le même dossier de projet, avec un cerveau partagé et un skill de transfert qui survit aux pannes. » J'utilise cette configuration depuis environ six semaines maintenant. Les trois premières semaines ont été difficiles. Les trois dernières ont été l'environnement de développement le plus résilient que j'aie jamais eu.

Laissez-moi vous guider exactement à travers le câblage.

Pourquoi J'ai Arrêté de Choisir un Camp Entre Claude Code et Codex

Avant la configuration, un mot rapide sur le changement de mentalité — parce que le câblage n'a d'importance que si la philosophie sous-jacente est juste.

Pendant la majeure partie de 2025, la conversation sur les agents CLI était tribale. Vous étiez une personne Claude Code, ou Codex, ou Cursor, ou Gemini CLI. Les raisons étaient réelles : chaque outil avait une ergonomie différente, un comportement de modèle différent, des fichiers de configuration différents, et changer coûtait du temps réel. En choisir un et s'y plonger avait du sens.

Deux choses ont changé pour moi en 2026.

La première, ce sont les pannes. Pas la faute d'Anthropic en particulier — chaque grand fournisseur de modèles a eu au moins une journée difficile cette année. OpenAI a eu un incident de plusieurs heures en février. Anthropic a eu le bégaiement d'API que j'ai mentionné plus haut. Le côté Gemini de Google a eu un bug de routage de modèle en mars qui a silencieusement dégradé les réponses pendant des heures avant que quiconque ne s'en aperçoive. Si tout votre flux de travail repose sur un seul fournisseur, une panne emporte votre journée entière. Ce n'est pas un problème de technologie — c'est un problème de point de défaillance unique.

La deuxième, c'est l'ornière. Parfois Claude Code se bloque. Pas « cassé » — créativement bloqué. Il choisit une approche, fonce avec, et quand cette approche ne marche pas, il continue à affiner la même approche plus fort. J'ai vu Opus passer 40 minutes à essayer de rendre un test instable fiable en ajoutant des tentatives de reprise alors que la vraie correction était de réécrire le test dans un style différent. Un second agent — pas comme remplacement, mais comme deuxième avis — brise généralement l'ornière en un seul prompt. Changer de CLI est le moyen le moins coûteux que j'aie trouvé pour obtenir une perspective fraîche du modèle sans perdre le contexte du projet.

Donc l'objectif n'est pas « choisir le meilleur CLI. » L'objectif est l'agnosticisme d'outils : construire une configuration où Claude Code et Codex peuvent tous deux travailler sur la même base de code, avec la même connaissance du projet, et où l'on peut passer de l'un à l'autre sans perdre sa position. Le CLI devient interchangeable. Le contexte du projet est ce qui est sacré. C'est le même instinct dont j'ai parlé dans mon flux de travail à deux agents superviseur-constructeur, poussé plus loin : pas seulement deux agents, mais deux CLIs entiers traités comme interchangeables.

Maintenant, le câblage.

Le Cerveau Partagé : CLAUDE.md et AGENTS.md Contiennent (Presque) la Même Chose

La première chose que j'ai apprise en commençant sérieusement à faire tourner les deux agents dans le même dépôt est ceci : les deux écosystèmes s'accordent déjà plus que le marketing ne le suggère. Claude Code et Codex lisent tous deux un fichier markdown au niveau du projet au démarrage. Claude Code lit CLAUDE.md. Codex lit AGENTS.md. Les contenus sont presque interchangeables. Le format est du markdown brut. L'intention est la même : dire à l'agent ce qu'est ce projet, quelles sont les conventions, quels outils utiliser, quels tests exécuter, et ce qu'il ne faut pas toucher.

Quand j'ai configuré le flux de travail en parallèle pour la première fois, j'ai fait l'erreur du débutant d'écrire deux fichiers séparés et de les garder synchronisés à la main. Ça a duré environ quatre jours avant que la dérive fasse que les agents ne s'accordent plus sur des choses basiques — Codex pensait qu'on utilisait pnpm, Claude Code pensait qu'on utilisait npm, et le hasard déterminait lequel avait raison à tout moment.

La solution est l'un de ces deux modèles, et les deux fonctionnent :

Modèle A — Lien symbolique de l'un vers l'autre. Choisissez le fichier que vous voulez comme source de vérité (j'ai choisi AGENTS.md parce qu'il devient le standard multi-fournisseur) et créez un lien symbolique de l'autre vers lui :

# depuis la racine du projet, avec AGENTS.md comme canonique
mv CLAUDE.md AGENTS.md   # si vous partez de CLAUDE.md
ln -s AGENTS.md CLAUDE.md

Maintenant les deux agents lisent le même fichier. Éditez AGENTS.md, les deux CLIs voient la mise à jour au prochain démarrage. C'est ce que recommande le guide de migration d'Onur Solmaz et ce que j'utilise dans la plupart de mes dépôts.

Modèle B — Les garder séparés mais forcer la synchronisation. Si vous voulez que chaque fichier ait quelques lignes spécifiques à l'outil (certains skills se comportent différemment dans l'un vs l'autre), gardez les deux fichiers et écrivez un hook de pre-commit qui compare la section partagée et avertit s'ils ont divergé. C'est plus lourd, mais ça vous permet d'avoir un bloc # Spécifique à Claude Code à la fin de l'un et pas de l'autre.

J'ai commencé avec le Modèle B et j'ai tout migré vers le Modèle A en deux semaines. Le coût de maintenance pour garder deux fichiers synchronisés était supérieur à la valeur d'avoir quelques lignes spécifiques par outil.

Quel que soit le modèle que vous choisissez, voici ce qui devrait réellement se trouver dans ce fichier partagé. Voici la section de mon vrai AGENTS.md pour le dépôt où j'écris tout ce contenu :

# Project: my-ai-crew

## What this is
Multi-brand content generation system. Four brands, each with a distinct
voice. Posts are saved to content/{brand}/[slug].md. No build system,
no tests — the workflow is agent-driven.

## Conventions
- All article files start with `**BRAND:**` — never YAML frontmatter.
- META DESCRIPTION must be 150-160 characters. Count before saving.
- Word count floor: 3,000.
- Brand voices are defined in .claude/agents/aria.md (do not edit
  without explicit instruction).

## Tools available
- WebSearch — use for fact verification, never guess versions/pricing
- Glob — scan content/{brand}/*.md before writing
- Read, Write, Edit — standard file ops

## What NOT to do
- Don't run git commit unless explicitly asked.
- Don't add Co-Authored-By lines without instruction.
- Don't generate placeholder metrics — use real numbers or omit.

## Brand directories
- content/mejba.me/ — personal practitioner voice
- content/ramlit.com/ — agency, business-focused
- content/colorpark.io/ — design agency, opinionated
- content/xcybersecurity.io/ — security, authoritative

Les deux CLIs lisent cela. Les deux agents connaissent maintenant les conventions. La première fois que vous écrivez ce fichier correctement est la première fois que votre configuration à deux CLIs semble cohérente plutôt que schizophrène.

Il y a une subtilité qui mérite d'être signalée. Claude Code prend en charge les fichiers CLAUDE.md imbriqués dans les sous-répertoires — quand l'agent lit un fichier dans content/colorpark.io/, il peut récupérer des instructions supplémentaires d'un CLAUDE.md placé dans ce sous-dossier. Codex a un mécanisme similaire : quand vous faites cd dans un sous-répertoire, il concatène les fichiers AGENTS.md du dossier actuel jusqu'à la racine du dépôt, les fichiers les plus proches écrasant les précédents (c'est documenté dans le guide AGENTS.md de Codex). Si vous créez un lien symbolique à la racine, vous pouvez aussi le faire au niveau des sous-dossiers. Les deux écosystèmes s'entendront bien.

La Carte des Fichiers et Dossiers : Où Chaque CLI Cherche

Une fois le cerveau partagé connecté, la question suivante est : où se trouve tout le reste ? Skills, agents, configuration, commandes slash. Les deux CLIs ont leur propre structure de dossiers, et vous avez besoin d'une carte mentale.

Voici celle que je garde épinglée dans mes propres notes :

Quelques remarques sur ce tableau parce qu'elles m'ont piégé la première fois :

Le format de configuration est le plus grand écart de format. Claude Code utilise JSON pour settings.json. Codex utilise TOML pour config.toml. Si vous n'avez jamais écrit de TOML, c'est à mi-chemin entre YAML et INI — clés, valeurs, sections entre crochets. Pas difficile, mais vous ne pouvez pas coller votre settings.json dans config.toml et vous attendre à ce que ça fonctionne. La conversion est mécanique mais manuelle. (Ou, comme je le montrerai dans un instant, vous demandez à Claude Code de le faire pour vous.)

Les commandes slash et les skills convergent dans Codex. La documentation officielle d'OpenAI dit maintenant que les prompts personnalisés sont dépréciés en faveur des skills. Donc en 2026, si vous écrivez des instructions réutilisables pour Codex, vous les écrivez comme skills, pas comme prompts personnalisés. Claude Code distingue encore entre les commandes (dans .claude/commands/) et les skills (dans .claude/skills/), mais l'écart se réduit. Les deux écosystèmes convergent vers « un skill est un fichier markdown avec un frontmatter qui décrit quand il doit se déclencher. » Bonne nouvelle pour la portabilité.

Les sous-agents divergent plus qu'on ne s'y attendrait. Les sous-agents de Claude Code se déclenchent automatiquement — l'agent principal lit les descriptions de chaque fichier .claude/agents/*.md au démarrage, et route le travail vers eux quand une tâche correspond. Codex nécessite une invocation explicite. Vous pouvez créer des agents dans .codex/agents/, mais Codex ne route pas automatiquement vers eux ; vous dites à Codex quel agent utiliser. Je reviendrai sur cette différence parce que c'est ce qui change le plus votre façon de travailler.

Les Skills Sont Majoritairement Portables. Les Agents Nécessitent une Conversion.

La raison pour laquelle toute cette configuration fonctionne est que la plupart des fichiers markdown dans .claude/ et .codex/ sont structurellement identiques. Un skill est un dossier avec un SKILL.md à l'intérieur. Le SKILL.md a un frontmatter YAML avec name et description, puis un corps markdown avec des instructions. Cette spécification est la même des deux côtés. Ce qui signifie qu'un skill que j'ai écrit pour Claude Code se transfère dans Codex sans aucune modification la plupart du temps.

Je l'ai testé directement. Mon skill caveman — le mode de communication ultra-compressé qui réduit l'utilisation de tokens d'environ 75% (j'ai écrit sur la création du skill caveman pour Claude Code il y a quelque temps) — a été écrit à l'origine pour Claude Code. J'ai copié le dossier caveman/ de .claude/skills/ dans .codex/skills/, redémarré Codex, et le skill s'est déclenché correctement dès le premier prompt. Aucun changement de format. Aucune réécriture de frontmatter. Ça a simplement fonctionné.

Les skills qui ne se portent pas proprement sont ceux qui référencent des noms d'outils spécifiques à Claude Code. Si votre skill dit « utilisez l'outil Glob » — Codex n'a pas d'outil nommé Glob. Il a un accès shell, donc l'agent peut toujours chercher des fichiers via find ou ls, mais vous devrez soit réécrire le skill pour référencer des opérations shell, soit accepter que le skill fonctionnera moins fiablement. Environ 80% des skills que j'ai migrés n'ont nécessité aucun changement. Les 20% restants ont nécessité des modifications légères des références d'outils.

Les sous-agents sont là où la conversion devient sérieuse. Le frontmatter est similaire (name, description, model, tools) mais le modèle de dispatch est différent — et cela change la façon dont vous écrivez le corps de l'agent. Un agent Claude Code est écrit en supposant qu'il sera auto-invoqué quand une tâche correspond à sa description. Un agent Codex est écrit en supposant que vous l'invoquerez explicitement. Donc :

• Les descriptions d'agents Claude Code sont écrites pour être lues par le modèle de dispatch. Elles disent « utilisez cet agent quand X est nécessaire » parce que l'agent principal a besoin de savoir quand déléguer.
• Les descriptions d'agents Codex sont écrites pour être lues par l'utilisateur humain. Elles disent « cet agent gère X » parce que c'est l'humain qui route le travail.

Quand vous migrez un agent de l'un à l'autre, vous ne copiez pas simplement le fichier. Vous réécrivez la description depuis la bonne perspective. Le corps — le system prompt réel — se transfère généralement sans changement.

C'est la plus grande différence pratique entre les deux écosystèmes, et c'est la raison pour laquelle j'exécute les deux côte à côte plutôt que de les traiter comme des remplacements directs. Claude Code est meilleur pour l'orchestration multi-agents parce que le dispatch est automatique — j'ai couvert la mécanique de dispatch en détail dans mon guide des équipes d'agents Claude Code. Codex est meilleur pour l'utilisation contrôlée et déterministe d'agents parce que vous décidez quel agent s'exécute. Des forces différentes, les mêmes briques de base.

Le Prompt de Conversion que Je Colle dans Claude Code pour Initialiser Codex

Quand je commence un nouveau dépôt et que je veux les deux CLIs prêts dès le premier jour, je ne convertis rien manuellement. J'écris d'abord la configuration Claude Code (parce que c'est là que la mémoire musculaire est) puis je colle ce prompt dans Claude Code et je le laisse générer l'équivalent Codex.

Voici le prompt réel. Copiez-le, collez-le dans Claude Code, et il fera la conversion pour vous :

I want this repo to work in both Claude Code and Codex CLI side by side.
Right now the Claude Code setup is complete. I need you to generate the
parallel Codex setup. Specifically:

1. Read CLAUDE.md and create AGENTS.md with the same content, then
   replace CLAUDE.md with a symlink to AGENTS.md. Use:
     mv CLAUDE.md CLAUDE.md.bak
     # copy CLAUDE.md.bak contents into AGENTS.md
     ln -s AGENTS.md CLAUDE.md
     rm CLAUDE.md.bak  (only after verifying the symlink works)

2. Read .claude/settings.json and create .codex/config.toml that mirrors
   the relevant settings. Convert JSON syntax to TOML. Skip any
   Claude-Code-specific keys that have no Codex equivalent (e.g.
   permissions, hooks) and add a comment listing what was skipped.

3. For each file in .claude/skills/<name>/SKILL.md, create
   .codex/skills/<name>/SKILL.md by copying the file. Check the body
   for any references to Claude-Code-specific tools (Glob, Read tool,
   etc) and either rewrite them as shell equivalents or flag them in a
   comment at the top of the file.

4. For each file in .claude/agents/<name>.md, do NOT auto-port to
   .codex/agents/. Instead, list the agents and ask me which ones I
   want available in Codex. For the ones I select, rewrite the
   description field to be human-routing-friendly (Codex requires
   explicit invocation, not auto-dispatch) and copy the body unchanged.

5. After all conversions, write a CONVERSION_LOG.md at the repo root
   that lists every file created or modified, every skipped key, and
   every tool reference that was rewritten. I want to be able to audit
   this in 30 seconds.

Do not commit anything. Just create the files and the log.

La première fois que j'ai exécuté cela, Claude Code a pris environ quatre minutes. La majeure partie était l'agent qui lisait chaque skill et décidait si chacun avait des références d'outils spécifiques à Claude Code. Le log de conversion a été utile parce qu'il a détecté deux skills qui référençaient l'outil Glob par son nom — je les ai réécrits pour utiliser find du shell à la place, et maintenant les deux versions du skill fonctionnent dans leurs CLIs respectifs sans autre modification.

Vous pouvez aussi exécuter la conversion inverse, allant d'une configuration Codex vers une configuration Claude Code. Le prompt est symétrique — il suffit d'inverser la source et la cible. J'ai habituellement une direction de conversion comme pipeline de configuration canonique et l'autre comme bootstrap ponctuel.

Le Skill de Transfert de Session : Déplacer le Contexte Entre les Agents

Voici la partie dont personne ne parle : même avec un AGENTS.md partagé, les agents eux-mêmes ne partagent pas l'état de conversation. Quand vous passez de Claude Code à Codex en pleine tâche, le nouvel agent ne sait pas ce que vous étiez en train de faire. Il connaît les conventions du projet, mais pas l'intention active.

C'est le moment où la plupart des gens abandonnent la configuration de CLI en parallèle. Ils l'essaient un jour, heurtent un mur de contexte en changeant d'outil, et concluent qu'exécuter les deux « n'en vaut pas la peine ». C'est faux — mais seulement si vous avez un transfert délibéré.

J'ai créé un skill qui résout cela. Il capture les quatre choses qui comptent réellement lors du transfert de travail entre agents : les fichiers actifs que vous avez touchés, l'intention en cours (ce que vous essayez de faire), les blocages (ce qui est bloqué ou a échoué), et la prochaine étape (ce que l'agent récepteur devrait faire en premier). Il écrit ces quatre champs dans un fichier .handoff.md à la racine du dépôt. L'agent récepteur lit ce fichier au prompt suivant et sait exactement où reprendre.

Voici le skill réel, qui se trouve dans .claude/skills/session-handoff/SKILL.md :

---
name: session-handoff
description: Capture the active session state into .handoff.md so another CLI agent (Codex, Gemini, etc.) can pick up the work. Use when the user says "handoff", "pass to codex", "switch agents", or "context for next agent".
allowed-tools: Read, Write, Bash
---

# Session Handoff

When this skill fires, write `.handoff.md` at the repo root with these
exact four sections. Be terse. The receiving agent reads this and
needs to act on it immediately.

## Format

```markdown
# Session Handoff — [ISO timestamp]
From: [claude-code | codex | other]

## Active files
- [path/to/file:line-range] — [one-line reason]
- [path/to/file] — [one-line reason]

## Current intent
[1-3 sentences: what we're trying to accomplish in this work session]

## Blockers
- [Specific thing that's stuck. Include error message if any.]
- [Or "none" if not stuck — just switching for fresh perspective.]

## Next step
[Exactly one sentence. The single action the receiving agent should
take first.]

Rules

• Do NOT include full file contents. Just paths and line ranges.
• Do NOT summarize the conversation. Capture state, not history.
• If .handoff.md already exists, overwrite it (no append).
• After writing, print "Handoff written to .handoff.md" and exit.
• The receiving agent should be told (by the human) to read .handoff.md as their first action.

Le skill miroir dans `.codex/skills/session-handoff/SKILL.md` est identique sauf pour un changement — la description est réécrite parce que Codex ne fait pas d'auto-dispatch. La version Codex ressemble plus à une indication d'utilisation qu'à un signal de routage. La différence en texte clair : la description de Claude Code dit « déclenchez ceci quand l'utilisateur dit X. » Celle de Codex dit « utilisez ce skill pour écrire un fichier de transfert. »

Pour déclencher un transfert dans Claude Code, je tape simplement « handoff to codex » — le skill détecte le mot-clé et écrit le fichier. Pour le déclencher dans Codex, je tape `$session-handoff` (la syntaxe d'invocation explicite de Codex) et il fait la même chose. Ensuite je change d'onglet, et la première chose que je dis à l'agent récepteur est : « Lis .handoff.md et continue. »

Le fichier de transfert fait généralement entre 15 et 30 lignes. L'agent récepteur le lit, a le contexte complet en cinq secondes, et commence à travailler. J'ai utilisé ce skill probablement 200 fois au cours des six dernières semaines. C'est la seule pièce de colle qui fait que la configuration de CLI en parallèle semble cohérente plutôt que fragmentée.

Si vous ne construisez qu'une seule chose de tout cet article, construisez ce skill. Il est petit. Il fait gagner des heures. Si vous n'avez jamais construit un skill Claude Code à partir de zéro, mon [guide des skills avancés de Claude Code](https://www.mejba.me/blog/agent-skills-advanced-claude-code) explique le format et les pièges.

## À Quoi Ressemble Réellement le Côte à Côte : Panneau Divisé dans VS Code

Le câblage ci-dessus est la configuration statique. Voici la dynamique — à quoi ressemble réellement mon écran pendant une session de travail.

VS Code, panneau de terminal divisé, orientation verticale. Panneau gauche : Claude Code, exécutant Opus 4.7, à la racine du projet. Panneau droit : Codex CLI, exécutant GPT-5.4, même racine de projet. Les deux agents ont le même `AGENTS.md`. Les deux ont accès aux mêmes skills. Les deux peuvent éditer les mêmes fichiers (ils se coordonnent via le système de fichiers, pas par une messagerie inter-CLI — git est la source de vérité sur l'état du disque).

Par défaut, j'utilise Claude Code au début de chaque session. C'est l'agent que j'ai le plus affiné, et il a mon ensemble complet de sous-agents `.claude/agents/` disponibles. Je planifie, je structure et je fais les premiers 60% des changements là.

Je passe à Codex dans des scénarios spécifiques :

**Claude Code reste bloqué sur une approche.** Quarante minutes plus tard, il tourne sur la même idée. J'exécute le skill de transfert, passe à Codex, et lui demande de regarder le même problème avec un œil neuf. Environ 70% du temps, Codex choisit un angle différent et débloque le travail. Les 30% restants, il est d'accord avec l'approche de Claude Code mais suggère un ajustement spécifique qui la fait fonctionner. Dans les deux cas, l'ornière se brise.

**Travail de refactoring long et mécanique.** Les performances du Codex CLI sur les tâches basées sur le terminal sont réellement supérieures à celles de Claude Code sur les tâches routinières lourdes en shell, selon la [comparaison DeployHQ 2026](https://www.deployhq.com/blog/comparing-claude-code-openai-codex-and-google-gemini-cli-which-ai-coding-assistant-is-right-for-your-deployment-workflow) (Codex CLI a atteint 77,3% sur Terminal-Bench 2.0 contre 65,4% pour Claude Code). Quand la tâche est « renommer 30 variables dans 12 fichiers en suivant ce modèle » ou « exécuter la suite de tests, analyser les échecs, écrire les corrections », Codex est plus rapide et utilise moins de tokens.

**L'API de Claude est en panne.** C'est la raison originale pour laquelle j'ai construit la configuration en parallèle. Quand Anthropic a un incident, je bascule entièrement vers le panneau Codex et je continue à travailler. Les skills se transfèrent. Le contexte du projet se transfère. La seule chose que je perds est l'agente Aria (parce qu'Aria a un comportement de sous-agent spécifique à Claude Code qui ne se traduit pas complètement), et je n'utilisais généralement pas Aria pour le travail que je transfère à Codex de toute façon.

**Revue adversariale.** Quand je veux une revue de code qui *n'est pas* du même modèle qui a écrit le code, je fais le travail dans Claude Code, puis je demande à Codex de revoir le diff. Lignée de modèle différente, données d'entraînement différentes, angles morts différents. Je détecte des bugs de cette manière qu'aucun agent ne trouve en revoyant son propre travail. J'ai écrit sur ce modèle en détail dans [l'article sur la revue adversariale avec le plugin Codex](https://www.mejba.me/blog/codex-plugin-claude-code-adversarial-review) — même idée, intégration plus étroite quand vous le souhaitez.

Le modèle qui a émergé après quelques semaines : Claude Code est mon principal, Codex est mon parallèle. Je suis dans Claude Code 70-80% du temps. Codex c'est 20-30%, plus 100% quand Claude est en panne.

## Garder les Deux Configurations Synchronisées (La Discipline)

Tout le système se casse si les deux configurations divergent. Le mode de défaillance le plus courant que je vois — y compris dans ma propre configuration, quand je deviens paresseux — c'est qu'on édite `CLAUDE.md` (qui est maintenant le lien symbolique) et qu'on écrit accidentellement des changements que seul Claude Code comprend. Ou on ajoute un nouveau skill dans `.claude/skills/` et on oublie de le répliquer dans `.codex/skills/`. Deux semaines plus tard, on change de CLI et on découvre que la moitié de ses outils manque.

La discipline qui fonctionne réellement pour moi, après plusieurs itérations :

**Les éditions au fichier canonique sont toujours considérées « agnostiques d'outil » par défaut.** Si j'écris quelque chose dans `AGENTS.md` qu'un seul CLI devrait connaître, je le mets dans une section clairement marquée à la fin : des blocs `# Claude Code uniquement` et `# Codex uniquement`. Les deux CLIs lisent le fichier entier, mais les en-têtes de section me disent (à l'humain) quelles lignes s'appliquent où. Réduit beaucoup le travail de maintenance.

**Les changements de skills passent par un script de synchronisation.** J'ai un petit script shell qui copie les fichiers nouveaux ou modifiés de `.claude/skills/` vers `.codex/skills/` (et inversement), en préservant les substitutions de noms d'outils que j'ai déjà faites. Je l'exécute manuellement après avoir édité un skill, avant la prochaine session. Cinq secondes de travail, empêche la dérive lente.

**Les changements de sous-agents ne se synchronisent pas automatiquement.** Je laisse les agents dans `.claude/agents/` pour l'usage de Claude Code, et je ne porte manuellement que ceux que je veux activement dans Codex. La plupart de mes agents sont exclusifs à Claude Code parce que le comportement d'auto-dispatch est tout l'intérêt de les avoir. Les deux ou trois que je porte vers Codex, je les garde synchronisés manuellement parce que les descriptions doivent être différentes de toute façon.

**Les fichiers de configuration (`settings.json` et `config.toml`) ne se synchronisent jamais automatiquement.** Ils divergent naturellement parce qu'ils exposent des paramètres différents. Je les traite comme indépendants, et je les revois chacun une fois par mois pour m'assurer que je n'ai pas introduit une divergence de comportement non intentionnelle.

Voilà la charge opérationnelle, honnêtement. Environ dix minutes par semaine de travail de synchronisation explicite. En échange, j'ai deux CLIs qui connaissent tous les deux mon projet et peuvent tous les deux y travailler de manière interchangeable.

## Quand la Configuration en Parallèle Ne Vaut Pas le Coup

Je mentirais si je disais que cette configuration convient à tout le monde.

Si vous êtes nouveau sur Claude Code, ne faites pas ça encore. Affinez d'abord Claude Code. Écrivez bien votre `CLAUDE.md`, construisez une poignée de skills, habituez-vous au fonctionnement des sous-agents. Ajouter Codex dès le premier jour signifie que vous apprenez deux CLIs en même temps, et vous serez confus sur quel comportement vient de quel outil. Choisissez-en un, approfondissez, puis ajoutez l'autre.

Si votre travail est principalement dans les outils d'un écosystème — utilisation intensive de Claude Skills, beaucoup de serveurs MCP connectés spécifiquement à Claude, des sous-agents qui dépendent de l'auto-dispatch — la configuration en parallèle pourrait ne pas être rentable. La couche portable est plus petite pour vous que pour quelqu'un qui utilise les deux outils principalement via des skills en markdown brut.

Si vous êtes un développeur solo qui lance un projet personnel le week-end, l'argument de la résilience compte moins. Une panne vous coûte le samedi après-midi. Ennuyeux, pas catastrophique. La configuration en parallèle est la plus rentable quand votre gagne-pain dépend de la disponibilité de l'agent — quand une panne signifie que le travail du client n'est pas livré.

Et si vous êtes sensible aux coûts, exécuter deux CLIs signifie que vous avez des abonnements ou un accès API à deux fournisseurs. J'exécute les deux via des plans Pro, ce qui coûte plus par mois que d'en exécuter un seul. Ça vaut le coup pour moi parce que la valeur de résilience est élevée. Probablement pas rentable pour quelqu'un dont l'utilisation est légère.

## Le Vrai Gain : Résilience et Perspective Fraîche

La configuration vaut l'effort pour deux raisons faciles à sous-estimer tant qu'on n'a pas vécu sans elles.

D'abord, la résilience. Au cours des six semaines depuis que j'exécute les deux CLIs, j'ai rencontré deux incidents Anthropic séparés et un bug prolongé de mise à jour du CLI Claude Code. Dans les trois cas, j'ai perdu approximativement zéro temps de travail, parce que je suis passé à Codex en cinq minutes et j'ai continué à avancer. Par rapport aux jours d'avant la configuration, où un mauvais après-midi pouvait me coûter un livrable client complet, l'investissement dans le CLI parallèle s'est rentabilisé dès le premier incident.

Ensuite, la perspective fraîche. Même les jours où aucun agent n'est en panne, changer de CLI en pleine tâche est l'outil de créativité le moins cher que j'aie jamais utilisé. Lignée de modèle différente. RLHF différent. Emphase différente sur les données d'entraînement. Le même prompt, envoyé à Claude Code et à Codex, produit parfois des solutions avec des approches radicalement différentes. J'ai pris l'habitude de délibérément exécuter les deux sur le même problème difficile et de fusionner les meilleures idées. C'est comme avoir deux ingénieurs seniors sur la même tâche, sauf que l'un d'eux ne coûte presque rien de plus et ne se fatigue jamais.

L'état d'esprit agnostique d'outils est le vrai changement. Le CLI est interchangeable. La connaissance du projet est ce qui compte. Traitez `AGENTS.md` (ou quel que soit votre fichier d'instructions partagé) comme le fichier le plus important de votre dépôt. Traitez les skills comme des actifs portables, pas des scripts spécifiques à un outil. Traitez les sous-agents comme la chose que chaque CLI fait à sa manière, et n'essayez pas de les forcer à être identiques entre fournisseurs.

Si Anthropic lançait un concurrent de Codex demain, mon flux de travail l'absorberait en un après-midi. Si OpenAI lançait quelque chose qui rendait Claude Code obsolète, pareil. Les agents vont et viennent. La connaissance du projet reste.

C'est ça, le gain.

## Questions Fréquemment Posées

### Claude Code et Codex peuvent-ils éditer les mêmes fichiers en même temps ?
Oui, les deux CLIs peuvent éditer des fichiers dans le même projet simultanément, mais ils ne se coordonnent pas au niveau de la mémoire — ils se coordonnent via le système de fichiers. Si les deux agents touchent le même fichier dans la même minute, vous aurez un problème de lecture obsolète. Règle pratique : exécutez-les en parallèle sur des fichiers différents, ou faites un transfert explicitement en utilisant le skill de session-handoff décrit ci-dessus.

### Dois-je payer pour Claude Code et Codex séparément ?
Oui. Claude Code est le CLI d'Anthropic et utilise la facturation Anthropic (plan Pro ou API). Codex est le CLI d'OpenAI et utilise la facturation OpenAI (ChatGPT Plus/Pro ou API). Il n'y a pas d'abonnement partagé. Le coût d'exécution des deux est approximativement le double du coût d'un seul, mais la résilience et la perspective fraîche en valent la peine pour les professionnels en activité.

### Quelle est la vraie différence entre CLAUDE.md et AGENTS.md ?
Fonctionnellement, aucune — les deux sont des fichiers markdown bruts que l'agent lit au démarrage pour apprendre les conventions du projet. La différence est quel CLI lit lequel par défaut. AGENTS.md devient le standard multi-fournisseur, supporté par Codex et d'autres, tandis que CLAUDE.md est le nom natif de Claude Code. La configuration la plus propre est de garder AGENTS.md comme le vrai fichier et de créer un lien symbolique de CLAUDE.md vers lui.

### Mes skills Claude Code fonctionneront-ils dans Codex sans modifications ?
La plupart, oui. Les deux écosystèmes utilisent le même format SKILL.md (frontmatter YAML avec name/description, corps markdown). Les skills qui nécessitent des modifications sont ceux qui référencent des noms d'outils spécifiques à Claude Code comme Glob ou des serveurs MCP spécifiques qui ne sont pas installés dans votre configuration Codex. Environ 80% se portent sans modification dans mon expérience ; les 20% restants nécessitent 5-10 lignes de modifications.

### Codex a-t-il des sous-agents comme Claude Code ?
Codex supporte maintenant les skills (le remplacement moderne des prompts personnalisés) et les sous-agents via `.codex/agents/`, mais le modèle de dispatch est différent : Codex vous demande d'invoquer explicitement un sous-agent, tandis que Claude Code fait un auto-dispatch basé sur la correspondance entre la description de l'agent et la tâche. Si vous dépendez du routage automatique entre de nombreux sous-agents, Claude Code reste l'orchestrateur le plus puissant. Si vous préférez un contrôle déterministe sur quel agent s'exécute, le modèle d'invocation explicite de Codex est plus propre.

## Travaillons Ensemble

Vous cherchez à construire des systèmes d'IA, automatiser des flux de travail ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.

* **Fiverr** (projets personnalisés et intégrations) : [fiverr.com/s/EgxYmWD](https://www.fiverr.com/s/EgxYmWD)
* **Portfolio** : [mejba.me](https://www.mejba.me)
* **Ramlit Limited** (solutions entreprise) : [ramlit.com](https://www.ramlit.com)
* **ColorPark** (design et branding) : [colorpark.io](https://www.colorpark.io)
* **xCyberSecurity** (services de sécurité) : [xcybersecurity.io](https://www.xcybersecurity.io)