Le même projet dans les deux outils : ce qui change concrètement

Le projet de départ : ce site

Le site sur lequel tu lis cette leçon est un projet Next.js 16. À sa racine, deux fichiers d'instructions :

Texte brut

linedev-formation/
  AGENTS.md    un bloc de règles écrit par Next.js
  CLAUDE.md    « @AGENTS.md », puis toutes les règles du projet
  contenu/
  src/

Je n'ai pas inventé ce montage : il vient de Next.js. J'ai lu son code source dans node_modules/next/dist/server/lib/generate-agent-files.js (version 16.3.7 installée ici) : quand next dev détecte un assistant de code et que le bloc de règles manque, il l'écrit dans AGENTS.md. Si aucun des deux fichiers n'existe, il crée les deux, avec un CLAUDE.md qui contient une seule ligne : @AGENTS.md.

Ensuite, j'ai ajouté les règles de mon projet dans CLAUDE.md, sous cette ligne. Le port local, la règle unique d'accès aux leçons, l'interdiction de lire les fichiers .env, les migrations à créer après chaque changement de base.

Ce que Claude Code lit au démarrage

Claude Code lit CLAUDE.md dans ton dossier de travail et dans chaque dossier au-dessus. La ligne @AGENTS.md est un import : Claude Code charge le fichier cité en même temps que le CLAUDE.md qui le cite.

Résultat : Claude Code voit le bloc de Next.js, puis toutes mes règles. Tout va bien de ce côté.

Ce que Codex lit au démarrage

Codex part de la racine du projet et descend jusqu'au dossier où tu l'as lancé. Dans chaque dossier, il prend un seul fichier : AGENTS.override.md s'il existe, sinon AGENTS.md. Par défaut, il ne lit pas CLAUDE.md.

Résultat : dans ce projet, Codex voit le bloc de Next.js. Et rien d'autre.

Chargement du schéma…

Dans ce dépôt aujourd'hui : les règles du projet ne vont qu'à un seul outil

La correction tient en un déplacement : les règles communes vont dans AGENTS.md, et CLAUDE.md garde l'import plus ce qui ne concerne que Claude Code. On le fait pas à pas au chapitre 2, avec les pièges de Windows et la façon de vérifier ce que chaque outil a vraiment lu.

Les gestes du quotidien, côte à côte

Voici les commandes que j'ai vérifiées dans les deux documentations. Sur chaque ligne : Claude Code d'abord, puis Codex après le point-virgule.

Lancer : claude ; codex.
Lancer avec une demande : claude "explique ce projet" ; codex "explique ce projet".
Créer le fichier d'instructions : /init écrit un CLAUDE.md ; /init écrit un AGENTS.md.
Voir l'état de la session : /status ; /status.
Choisir le modèle : /model ; /model.
Réfléchir avant d'agir : /plan, ou la touche Maj+Tab qui fait tourner les modes ; /plan.
Libérer du contexte en résumant : /compact ; /compact.
Repartir d'une conversation vide : /clear ; /new ou /clear.
Reprendre une session : claude -c ou /resume ; codex resume ou /resume.
Voir les changements : /diff ; /diff.
Faire relire les changements : /code-review, dont /review est un alias ; /review.
Serveurs MCP : /mcp ; /mcp.
Skills : /skills ; /skills, ou $nom pour en appeler un.
Permissions : /permissions ; /permissions.
Script ou intégration continue : claude -p "..." ; codex exec "...".
Importer la configuration de l'autre : /import codex ; /import, puis choisir Claude Code.

Les habitudes qui changent

Où va une autorisation permanente

Quand tu réponds « Oui, et ne plus demander » à Claude Code pour une commande shell, il enregistre une règle « autoriser » dans le fichier .claude/settings.local.json du projet, un fichier personnel qui reste hors de git.

Quand tu ajoutes une commande à la liste autorisée dans l'interface de Codex, il l'écrit dans ~/.codex/rules/default.rules, dans ton dossier personnel. Ces règles servent aux commandes qui doivent sortir du bac à sable.

Le réseau

Chez Codex, le réseau est coupé par défaut pour les commandes, même dans le préréglage Auto. Il faut l'ouvrir dans la configuration, ou approuver la demande.

Chez Claude Code, en mode Manual, la lecture d'une page web demande ton accord par domaine, sauf pour une liste de domaines de documentation déjà approuvés.

Les fichiers que l'outil protège

Codex garde en lecture seule .git, .agents, .codex et .aws, même quand il a le droit d'écrire dans ton projet. Claude Code, lui, n'approuve jamais automatiquement une écriture dans .git ou .claude, sauf quand tu as désactivé ses vérifications.

Conséquence pratique : si tu demandes à l'un ou l'autre de modifier ses propres réglages ou ses skills, attends-toi à devoir donner ton accord. C'est voulu.

Ce que la suite t'apporte

Tu as vu le problème sur un vrai dépôt. Le chapitre 2 te donne la solution et tout le reste des équivalences :

installer le second outil et importer ta configuration existante, dans un sens ou dans l'autre ;
un seul fichier d'instructions lu par les deux, avec la vérification de ce que chacun a chargé ;
un même skill utilisable des deux côtés ;
la traduction exacte des permissions et du bac à sable.

Le chapitre 3 passe à la pratique à deux outils : une relecture croisée avant chaque commit, et une grille pour choisir l'outil d'une tâche.

Sources : mémoire et AGENTS.md dans Claude Code, permissions de Claude Code, AGENTS.md dans Codex, commandes de Codex et sécurité de Codex, vérifiées le 19 octobre 2026.