Migrer depuis Claude Code : de nouveaux repères pour un outil familier

📚 Navigation de la série : Le chapitre précédent 〔31 Techniques avancées et accélération〕 expliquait comment optimiser votre flux de travail pour le rendre plus rapide, plus économique et limiter les corrections. Ce chapitre s'adresse spécifiquement aux utilisateurs effectuant la transition depuis Claude Code : quels concepts de votre modèle mental actuel sont transposables directement, lesquels nécessitent une adaptation de vocabulaire, et quelles sont les nouveautés propres à Codex. Le chapitre suivant 〔33 Utilisation sous Windows〕 détaillera les spécificités de la plateforme Windows.

Commençons par une discussion réelle. Le mois dernier, un ami habitué à Claude Code a installé Codex et m'a posé une série de questions :

Lui : « Où se trouve le fichier CLAUDE.md de Codex ? Pourquoi ne lit-il pas celui situé à la racine de mon projet ? » Moi : « Codex ne reconnaît pas le nom CLAUDE.md. Il recherche un fichier nommé AGENTS.md, dont vous pouvez copier le contenu presque à l'identique. » Lui : « Et qu'en est-il de mes règles d'autorisation allow / deny définies dans settings.json ? » Moi : « Il faut également les adapter. Codex utilise un fichier de configuration au format TOML situé dans ~/.codex/config.toml. La gestion des permissions repose sur des notions de "sandbox + approbation", plutôt que sur allowedTools. » Lui : « Comment exécuter des scripts de manière non interactive, comme avec claude -p ? Et retrouve-t-on les commandes slash comme /compact ou /clear ? » Moi : « La commande claude -p équivaut à codex exec. La majorité des commandes slash sont présentes sous les mêmes dénominations. En résumé, 90 % de vos habitudes d'utilisation restent valables. »

Ces explications l'ont rassuré : il ne s'agit pas de réapprendre un outil à partir de zéro, mais d'adapter ses repères à une nouvelle terminologie. Ce chapitre détaille les équivalences de concepts, les pièges à éviter lors de la transition, et la procédure pour convertir un fichier CLAUDE.md existant en AGENTS.md.

Ce que vous obtiendrez après avoir lu ce chapitre :

La certitude que 90 % de votre modèle mental lié à Claude Code est directement transposable à Codex, rendant l'apprentissage simple.
Un tableau de correspondance complet « Concept Claude Code → Équivalent Codex » explicitant les différences clés.
L'analyse des trois éléments clés aux comportements différents malgré des noms proches : la documentation de projet, le fichier de configuration et la gestion des permissions.
La liste des fonctionnalités de Claude Code absentes ou implémentées différemment dans Codex, pour éviter les erreurs d'interprétation.
Un guide pratique pour migrer un fichier CLAUDE.md existant vers AGENTS.md.

⚠️ Les commandes, clés de configuration et comportements par défaut mentionnés ici se réfèrent à la documentation officielle de Codex. Les noms de modèles et numéros de versions pouvant évoluer, référez-vous aux affichages de votre panneau /model local et de la commande codex --help. Les deux outils évoluant rapidement, ce tableau présente des équivalences de concepts plutôt qu'une correspondance figée.

01 Un modèle mental transposable à 90 %

La transition depuis Claude Code vers Codex ne nécessite pas de réapprendre le fonctionnement de ce type d'outil, mais d'adapter vos repères.

Les deux solutions partagent la même logique de fond : ce sont des interfaces en ligne de commande (CLI) s'exécutant dans le terminal, fonctionnant selon une boucle d'agent autonome (agentic loop) et disposant d'un accès en lecture et écriture à votre codebase local. Ces principes de base restent inchangés.

Analogie : Passer d'un smartphone Android à un autre de marque différente. Il ne s'agit pas d'une refonte complète comme un passage d'Android à iOS. Vos habitudes pour téléphoner, envoyer des messages, installer des applications ou naviguer par balayage restent valables. Seuls l'emplacement des icônes, la structure des paramètres ou les noms de certaines applications changent. Vous n'avez pas besoin de réapprendre à utiliser un téléphone, mais simplement de passer dix minutes à repérer les nouveaux menus. C'est exactement cette relation qui existe entre Codex et Claude Code.

Voici les habitudes et concepts qui se transposent sans aucune modification :

La boucle d'action de l'agent (« Réfléchir → Agir → Observer ») : le cycle où vous décrivez un besoin, le modèle propose un plan, effectue les modifications puis analyse les résultats reste identique.
La phase d'analyse préalable : demander au modèle d'analyser le code et de proposer une stratégie avant de modifier les fichiers reste la règle.
La centralisation des consignes de projet dans un fichier unique lu à chaque début de cycle (bien que le nom du fichier change, voir paragraphe 03).
Les commandes slash pour contrôler la session (choix du modèle, gestion du contexte, statut).

Lors de mon premier projet avec Codex, j'ai pu utiliser la majorité des commandes par habitude : /status pour la configuration, /model pour le choix du modèle, ou la demande préalable d'une stratégie de refactorisation. Les seules différences concernaient le nom du fichier de consignes et la configuration des permissions, ce qui a été réglé en quelques minutes à l'aide de la documentation officielle.

💡 Résumé en une phrase : Codex et Claude Code partagent la même architecture (CLI terminal, boucle d'agent et accès local). 90 % de votre modèle mental est conservé, seule la terminologie des options change.

02 Tableau de correspondance : concepts Claude Code vs Codex

Voici la table de correspondance des principaux concepts de Claude Code vers leurs équivalents dans Codex.

Claude Code	Codex	Relation	Différence clé
Guide du projet `CLAUDE.md`	`AGENTS.md`	Renommé	Même principe, mais les règles de détection et de surcharge diffèrent (voir 03)
Configuration `~/.claude/settings.json` (JSON)	`~/.codex/config.toml` (TOML)	Format modifié	Passage du JSON au TOML, structure et clés différentes (voir 04)
Permissions `allow`/`ask`/`deny`	Sandbox (`sandbox`) et approbation (`approval`)	Approche modifiée	Remplacement de la liste d'outils par une logique de périmètre (sandbox) (voir 05)
Mode non interactif `claude -p`	Commande non interactive `codex exec`	Renommé	Même fonction : exécution d'une tâche sans entrer dans l'interface interactive
Niveaux de `CLAUDE.md` (utilisateur / projet / sous-répertoire)	Niveaux de `AGENTS.md` (global / héritage projet)	Équivalent	Logique identique, Codex introduit en plus le fichier `AGENTS.override.md`
Protocoles externes MCP	MCP	Identique	Même protocole, la syntaxe de configuration varie
Sous-agents (Subagents)	Sous-agents (Subagents)	Équivalent	Présent dans les deux outils, l'emplacement de configuration varie
Compétences (Skills)	Compétences (Skills)	Équivalent	Présent dans les deux outils, l'organisation locale des dossiers diffère légèrement
Commandes slash (`/model`, `/compact`...)	Commandes slash (`/model`, `/compact`...)	Identique	Commandes majoritairement identiques, quelques variations (voir 06)
Mémoire automatique (activée par défaut)	Memories / Chronicle	Équivalent avec nuances	La mémoire de Codex est désactivée par défaut, soumise à des restrictions géographiques et générée de manière asynchrone
Modèles Opus / Sonnet / Haiku	Gamme GPT-5.x	Modèles modifiés	Modèle phare `gpt-5.5`, modèle léger `gpt-5.4-mini`, etc.

Règle générale de transition :

Tous les concepts de base (guide projet, permissions, mémoire, sous-agents, compétences, MCP) existent de part et d'autre. La migration consiste à adapter la syntaxe et la nomenclature. Les seuls points de vigilance concernent la documentation projet, le fichier de configuration et la gestion des permissions. Les paragraphes suivants détaillent ces trois aspects.

Pour le choix des modèles, la logique reste identique à celle de Claude Code : associer la complexité de la tâche à la puissance du modèle. Le modèle phare gpt-5.5 remplace Opus pour les tâches complexes, et le modèle léger gpt-5.4-mini remplace Haiku pour les tâches secondaires (voir chapitre 30 Comment choisir son modèle). Attention à ne pas confondre gpt-5.4 et gpt-5.5 : le modèle phare est le 5.5, le 5.4-mini étant sa version allégée.

💡 Résumé en une phrase : La correspondance des concepts est presque totale. Les différences majeures se concentrent sur le guide projet, le format de configuration et le modèle de permissions.

03 Documentation de projet : `CLAUDE.md` vers `AGENTS.md`

Il s'agit du premier point de divergence pratique : Codex ne prend pas en charge le fichier CLAUDE.md. Le fichier contenant vos instructions à la racine du projet doit être nommé AGENTS.md.

Bonne nouvelle : son contenu est presque entièrement réutilisable. Les sections décrivant le projet, les technologies utilisées, les commandes usuelles, les règles de style et les contraintes de modification partagent les mêmes objectifs et la même structure. Les bonnes pratiques (comme documenter les spécificités du projet plutôt que des règles évidentes à la lecture du code) restent d'actualité.

Analogie : Mettre à jour une documentation technique lors d'un changement d'outil. Les informations de fond (architecture, exécution des tests, limites du système) restent identiques. Seule la structure du document final ou son nommage doivent respecter les standards du nouvel outil. C'est le cas pour le passage de CLAUDE.md à AGENTS.md.

Voici les différences de comportement à prendre en compte :

Caractéristique	Claude Code (`CLAUDE.md`)	Codex (`AGENTS.md`)
Emplacement utilisateur	`~/.claude/CLAUDE.md`	`~/.codex/AGENTS.md`
Emplacement projet	`./CLAUDE.md` ou `./.claude/CLAUDE.md`	`./AGENTS.md` (racine)
Sous-répertoires	Lu dans tout sous-répertoire si présent	Lu de la racine Git jusqu'au dossier courant
Surcharge locale	Fichier `CLAUDE.local.md` (hors git)	Fichier `AGENTS.override.md` (remplace le fichier `AGENTS.md` du même dossier)
Limite de taille	Recommandation en lignes (~200 lignes max)	Limite en octets (32 KiB par défaut après fusion, via `project_doc_max_bytes`)

Trois différences méritent une attention particulière :

1. Le mécanisme de surcharge locale est différent. Claude Code utilise CLAUDE.local.md pour ajouter des préférences personnelles exclues du suivi Git. Codex utilise AGENTS.override.md pour remplacer intégralement le contenu du fichier AGENTS.md du même répertoire. Ces deux fonctionnements ne sont pas identiques : l'un ajoute des consignes, l'autre les remplace (voir chapitre [11]).

2. La limite de taille est définie en octets. Claude Code recommande de ne pas dépasser 200 lignes de texte. Codex applique une limite stricte de 32 KiB après fusion. Tout dépassement entraîne une troncature du document ou son rejet complet par le système. Pensez à simplifier vos guides de projet lors de la migration en supprimant les règles évidentes à la lecture du code afin de respecter cette limite.

3. La fusion des consignes fonctionne par héritage. Les fichiers globaux et de projet s'appliquent simultanément, le fichier le plus proche du dossier de travail ayant la priorité en cas de conflit. Ce comportement est similaire à celui de Claude Code. La priorité s'établit en fusionnant les fichiers de la racine vers le dossier courant (voir chapitre [11]).

💡 Résumé en une phrase : Le contenu de CLAUDE.md se transpose directement dans AGENTS.md. Seuls le nom du fichier, le principe de surcharge (AGENTS.override.md) et la limite de taille (désormais en octets) changent.

04 Fichier de configuration : `settings.json` (JSON) vers `config.toml` (TOML)

Le format et la structure de configuration diffèrent entre les deux outils :

Claude Code utilise un fichier JSON unique situé dans ~/.claude/settings.json pour déclarer les permissions, les variables d'environnement, les scripts d'initialisation et le modèle par défaut.
Codex utilise un fichier au format TOML situé dans ~/.codex/config.toml pour paramétrer le modèle, le comportement de la sandbox, les autorisations et les outils MCP.

Analogie : Transposer un schéma d'installation électrique du système métrique au système impérial. Les éléments décrits (les circuits et les interrupteurs) sont identiques, mais les unités de mesure et les symboles graphiques changent. Vous devez redessiner le schéma en respectant les nouvelles normes de notation. C'est le cas pour la conversion du JSON vers le TOML.

Voici une comparaison des syntaxes de configuration :

Option à configurer	Claude Code (`settings.json`, JSON)	Codex (`config.toml`, TOML)
Modèle par défaut	`"model": "claude-..."`	`model = "gpt-5.5"`
Permissions / Sécurité	`"permissions": { "deny": [...] }`	`sandbox_mode = "..."` et `approval_policy = "..."`
Structure imbriquée	Accolades `{ }` et virgules	En-têtes de section `[nom_section]` et signes `=`
Guillemets	Obligatoires pour les chaînes	Obligatoires pour les chaînes

Exemple concret pour définir le modèle par défaut :

Dans Claude Code (JSON) :

json

{
  "model": "claude-sonnet-4"
}

Dans Codex (TOML) :

toml

# ~/.codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "medium"

Attention aux spécificités de la syntaxe TOML lors de la transition : utilisez le signe = (et non :) pour associer les clés et les valeurs, déclarez les sections avec des crochets [nom_section] (sans accolades pour le document global), et ne mettez pas de virgule en fin de ligne. Les virgules de fin de ligne (habitus du JSON) provoquent des erreurs de lecture dans Codex.

La description détaillée de toutes les options de configuration de config.toml est disponible au chapitre 18 config.toml 配置详解. Il est recommandé de réécrire vos règles utiles dans le nouveau fichier plutôt que de chercher à traduire l'intégralité de l'ancien fichier JSON. La plupart des utilisateurs ne configurent que le modèle par défaut et les niveaux de sécurité.

💡 Résumé en une phrase : La configuration de settings.json doit être réécrite au format TOML dans config.toml. Veillez à respecter la syntaxe TOML (signe =, sections entre crochets, pas de virgule de fin de ligne).

05 Sécurité : des permissions explicites à la sandbox avec approbation

Il s'agit du changement de logique le plus important. Chercher à calquer le système de permissions de Claude Code sur Codex se révélera inefficace.

Le modèle de sécurité de Claude Code repose sur deux piliers :

Le mode de permissions (permission mode) : un sélecteur à plusieurs niveaux (de default avec confirmation systématique à bypassPermissions avec exécution libre) accessible via le raccourci Shift+Tab.
Une liste de règles définies dans settings.json sous forme de règles allow, ask ou deny associées à des outils ou des commandes spécifiques (ex. bloquer rm -rf).

Codex adopte une approche différente en séparant le périmètre d'exécution et les demandes d'autorisation via deux options distinctes :

Le mode sandbox (sandbox) : définit le périmètre d'action autorisé (read-only, workspace-write ou danger-full-access).
La politique d'approbation (approval) : définit la fréquence des confirmations demandées à l'utilisateur (untrusted, on-request ou never).

Analogie : Passer d'un contrôle de dépenses sur justificatif à une enveloppe budgétaire avec alerte de dépassement. Claude Code fonctionne comme un contrôle sur justificatif : chaque dépense (chaque outil ou commande) doit être explicitement autorisée ou validée. Codex fonctionne comme une enveloppe budgétaire : il définit un cadre de dépenses autorisé (la sandbox) au sein duquel le modèle agit de manière autonome, les demandes de validation ne se déclenchant que si le modèle tente de sortir de ce cadre.

Voici la correspondance des configurations de sécurité :

Comportement recherché	Configuration Claude Code	Configuration Codex
Lecture seule, aucune modification	Mode `default` / Lecture seule	Sandbox réglée sur `read-only`
Modifications limitées au projet, validation requise pour le reste	Mode standard ou `acceptEdits`	Sandbox `workspace-write` + approbation `on-request` (configuration recommandée au quotidien)
Mode automatique sans confirmations	Mode `bypassPermissions`	Sandbox `danger-full-access` + approbation `never` (ou utilisation de l'option `--yolo`)
Interdiction d'une commande spécifique	Règle `permissions.deny`	Utilisation expérimentale des règles `rules` avec `prefix_rule()` pour bloquer des commandes par préfixe (`decision = "forbidden"`)
Modification rapide des niveaux	Raccourci `Shift+Tab`	Commande slash `/permissions` ou options `-s` / `-a` au démarrage

Quelques différences fondamentales à assimiler :

1. L'absence de confirmation n'implique pas des droits illimités. Dans Claude Code, le niveau d'autorisation dépend du mode choisi. Dans Codex, les paramètres sont indépendants : vous pouvez choisir une sandbox en lecture seule (read-only) associée à une approbation désactivée (never), ce qui permet au modèle de lire le code sans jamais vous interrompre.

2. Le niveau de sécurité par défaut s'adapte à la présence d'un dépôt Git. Au démarrage, Codex détecte si le dossier de travail est suivi par Git. Si c'est le cas, il applique la configuration recommandée workspace-write + on-request. Dans le cas contraire, il passe par défaut en lecture seule (read-only) pour protéger vos fichiers. Cette sécurité automatique n'existe pas dans Claude Code.

3. Les accès réseau et les modifications du répertoire .git sont restreints par défaut sous le mode workspace-write. L'accès réseau est désactivé et le dossier .git est protégé en écriture. Si vous avez besoin d'autoriser l'accès réseau, vous devez configurer explicitement l'option network_access.

Pour plus de détails sur la gestion de la sécurité, reportez-vous au chapitre 15 Permissions, sandbox et approbation. Veillez à bien intégrer cette distinction entre périmètre (sandbox) et politique d'approbation.

💡 Résumé en une phrase : Le système de permissions de Claude Code est remplacé dans Codex par deux paramètres indépendants : le mode sandbox (périmètre) et la politique d'approbation (fréquence des questions).

06 Utilisation au quotidien : commandes slash et gestion des sessions

Les commandes de contrôle de la session partagent de nombreuses similitudes entre les deux outils :

Action recherchée	Claude Code	Codex	Commande identique
Changer de modèle	`/model`	`/model`	Oui
Compresser le contexte	`/compact`	`/compact`	Oui
Démarrer une nouvelle session vide	`/clear`	`/clear`	Oui
Afficher la configuration / le statut	`/status` (ou `/config`)	`/status`	Équivalent
Initialiser la documentation	`/init` (crée `CLAUDE.md`)	`/init` (crée `AGENTS.md`)	Oui
Afficher les modifications	`/diff`	`/diff`	Oui
Lancer la revue de code	`/review`	`/review`	Oui
Modifier les permissions	Raccourci `Shift+Tab`	Commande `/permissions`	Différent

On note deux variations principales :

1. La modification des permissions s'effectue via la commande slash /permissions sous Codex (qui ouvre un menu de sélection), alors qu'elle s'effectue par le raccourci clavier Shift+Tab sous Claude Code.

2. La distinction entre /clear et /new : sous Codex, la commande /clear vide l'écran et démarre une nouvelle session, tandis que la commande /new crée une nouvelle session en conservant l'affichage des messages précédents. Sous Claude Code, la gestion des nouvelles sessions repose principalement sur la commande /clear.

La transition se fait naturellement pour la majorité des commandes quotidiennes. En cas de doute, la liste complète des commandes est disponible au chapitre 12 Commandes slash et raccourcis.

💡 Résumé en une phrase : Les commandes de contrôle de session sont très proches (/model, /compact, /clear, /diff, /review). La différence majeure concerne le réglage des permissions qui s'effectue via la commande /permissions (et non Shift+Tab).

07 Différences notables et fonctionnalités exclusives de Codex

Il est important d'identifier les fonctionnalités dont le comportement diffère de manière importante ou qui n'existent que dans l'un des deux outils :

1. L'état de la mémoire automatique. Claude Code active par défaut la conservation d'une mémoire de travail par dépôt Git. Sous Codex, le système de Memories est désactivé par défaut, fait l'objet de restrictions géographiques et s'exécute de manière asynchrone en arrière-plan. Pour les règles devant s'appliquer de manière constante, documentez-les dans le fichier AGENTS.md (voir chapitre [19]).

2. Fonctionnalités exclusives de Codex :

Le fichier AGENTS.override.md : permet de surcharger localement les consignes de projet (voir chapitre [11]).
Le système Chronicle : permet d'intégrer le contenu de l'écran dans le contexte du modèle (fonctionnalité expérimentale soumise à restrictions géographiques, voir chapitre [19]).
La détection du mode de sécurité basée sur la présence d'un dépôt Git (voir chapitre [15]).

3. Synthèse des changements de comportement : Le fichier CLAUDE.local.md est remplacé par AGENTS.override.md (avec une logique de remplacement et non d'ajout). Les règles de restriction de commandes spécifiques s'écrivent via des scripts de règles au format Starlark plutôt que par de simples listes de chaînes JSON.

Tableau récapitulatif des pièges de transition :

Hypothèse erronée	Comportement réel sous Codex
❌ Codex prend en charge le fichier `CLAUDE.md`	✅ Il recherche uniquement `AGENTS.md` (sauf si vous déclarez l'option `project_doc_fallback_filenames`)
❌ La mémoire de session est active par défaut	✅ Le système Memories est désactivé par défaut
❌ Le fichier `settings.json` est réutilisable	✅ La configuration doit être réécrite au format TOML dans `config.toml`
❌ Les permissions se configurent par outil	✅ La sécurité repose sur les options de sandbox et d'approbation
❌ Les permissions se modifient par `Shift+Tab`	✅ Les permissions se modifient via la commande `/permissions`

💡 Résumé en une phrase : La mémoire est désactivée par défaut sous Codex. L'outil introduit de nouveaux concepts (comme AGENTS.override.md ou la détection Git pour la sécurité) et requiert une réécriture TOML de vos configurations.

08 Guide pratique : migrer un fichier `CLAUDE.md` vers `AGENTS.md`

Ce guide présente la procédure pour convertir un fichier d'instructions existant et valider sa prise en compte par Codex.

Pour les utilisateurs de Windows, il est recommandé d'exécuter ces commandes dans Git Bash, WSL ou d'utiliser l'explorateur de fichiers pour créer les dossiers. Sur Windows, le chemin ~ correspond à C:\Users\NomUtilisateur\.

Étape 1 : Créer un projet de test avec un fichier CLAUDE.md.

Initialisez un dossier de test :

bash

mkdir migrate-demo && cd migrate-demo
git init

Créez un fichier CLAUDE.md représentatif (contenant un paragraphe historique inutile à supprimer lors de la migration) :

# Projet migrate-demo

Ce projet d'API de gestion de commandes est basé sur FastAPI. Il a été initié par l'équipe back-end en 2023.
Le framework d'origine était Flask, mais nous avons migré vers FastAPI pour des raisons de performance.
Ce choix d'architecture a fait l'objet de plusieurs revues... (texte historique superflu)

## Technologies

- Python 3.11 / PostgreSQL / pytest

## Commandes utiles

- `pytest` — Exécuter la suite de tests
- `ruff check .` — Lancer le linter de code

## Style de code

- Toutes les fonctions doivent être typées
- Utiliser les guillemets doubles pour les chaînes de caractères

## Restrictions

- Ne pas modifier les fichiers du répertoire migrations/
- Demander validation avant d'ajouter une dépendance

Étape 2 : Créer le fichier AGENTS.md équivalent.

Créez le fichier AGENTS.md en recopiant les informations utiles et en supprimant le paragraphe historique superflu :

# Projet migrate-demo — API de gestion de commandes sous FastAPI

## Technologies

- Python 3.11 / PostgreSQL / pytest

## Commandes utiles

- `pytest` — Exécuter la suite de tests
- `ruff check .` — Lancer le linter de code

## Style de code

- Toutes les fonctions doivent être typées
- Utiliser les guillemets doubles pour les chaînes de caractères

## Restrictions

- Ne pas modifier les fichiers du répertoire migrations/
- Demander validation avant d'ajouter une dépendance

Le fichier AGENTS.md ainsi créé est plus concis et se concentre sur les règles applicables au code, ce qui économise de l'espace de contexte.

Étape 3 : Valider la prise en compte des instructions par Codex.

Lancez la commande suivante dans le dossier du projet (l'option --ask-for-approval never permet d'éviter les demandes d'autorisation pour obtenir un affichage clair) :

bash

codex --ask-for-approval never "Summarize the current instructions."

Résultat attendu : Codex doit lister les consignes définies (technologies, exécution des tests, typage des fonctions, guillemets doubles, protection du dossier migrations). Si le modèle restitue ces informations, cela confirme que le fichier AGENTS.md a bien été chargé dans le contexte de travail.

Étape 4 (optionnelle) : Gérer l'ancien fichier CLAUDE.md.

Une fois la validation effectuée, le fichier CLAUDE.md peut être conservé ou supprimé (il n'est plus lu par Codex). Si vous devez cohabiter temporairement avec les deux outils et souhaitez que Codex lise également l'ancien fichier, ajoutez cette option dans votre fichier ~/.codex/config.toml :

toml

# ~/.codex/config.toml
project_doc_fallback_filenames = ["CLAUDE.md"]

Avec cette option, Codex cherchera les instructions dans l'ordre suivant : AGENTS.override.md → AGENTS.md → CLAUDE.md, en retenant le premier fichier non vide trouvé (redémarrez Codex pour appliquer la modification).

💡 Résumé en une phrase : La migration s'effectue en recopiant les règles utiles dans AGENTS.md et en supprimant les détails superflus. Validez avec la consigne « Summarize the current instructions » et utilisez l'option project_doc_fallback_filenames si vous devez conserver les deux fichiers.

Synthèse

Ce chapitre a détaillé la transition de vos compétences de Claude Code vers Codex :

Le modèle mental reste identique à 90 % (boucle d'action de l'agent, diagnostic préalable, configuration locale).
La documentation projet migre de CLAUDE.md vers AGENTS.md avec des spécificités sur le renommage, la surcharge locale (AGENTS.override.md) et les limites de taille.
La configuration abandonne le JSON pour le TOML (config.toml), ce qui requiert une adaptation de syntaxe.
La gestion de la sécurité passe d'une liste blanche d'outils à un couple indépendant Sandbox (périmètre) + Approbation (politique d'autorisation).
L'utilisation courante conserve les commandes slash habituelles, à l'exception du changement de niveau de permission qui s'effectue via /permissions.
Les fonctionnalités exclusives comme la gestion dynamique des permissions et la surcharge locale apportent plus de souplesse à votre flux de travail.

Vous êtes maintenant en mesure de : Migrer vos fichiers d'instructions CLAUDE.md vers AGENTS.md, adapter vos fichiers de configuration au format TOML et appréhender le système de sécurité Sandbox/Approbation. Vos acquis sur Claude Code restent de précieux atouts pour utiliser efficacement Codex.

Le chapitre suivant 〔33 Utilisation sous Windows〕 traite des spécificités de la plateforme Windows : comment appréhender les chemins de fichiers, configurer la sandbox et gérer le terminal pour exploiter pleinement les capacités de Codex.

Migrer depuis Claude Code : de nouveaux repères pour un outil familier ​

01 Un modèle mental transposable à 90 % ​

02 Tableau de correspondance : concepts Claude Code vs Codex ​

03 Documentation de projet : CLAUDE.md vers AGENTS.md ​

04 Fichier de configuration : settings.json (JSON) vers config.toml (TOML) ​

05 Sécurité : des permissions explicites à la sandbox avec approbation ​

06 Utilisation au quotidien : commandes slash et gestion des sessions ​

07 Différences notables et fonctionnalités exclusives de Codex ​

08 Guide pratique : migrer un fichier CLAUDE.md vers AGENTS.md ​

Synthèse ​

Lectures recommandées ​