Codex CLI : la référence technique définitive

TL;DR : Codex est un agent de programmation multi-surface : il lit votre codebase, exécute des commandes dans un sandbox au niveau du système d’exploitation, modifie des fichiers et délègue des tâches au cloud. Maîtrisez cinq systèmes – config.toml, le modèle de sandbox/approbation, AGENTS.md, MCP et les skills – et il deviendra un multiplicateur de force. GPT-5.6 Sol est le choix par défaut recommandé (le réglage « Power », avec un raisonnement moyen) ; GPT-5.5, le modèle phare de la génération précédente, offre un contexte de 400K dans Codex et de 1M dans API.⁸³¹¹⁷ Vous découvrez Codex ? Accédez directement à Installation et Démarrage rapide. Vous suivez les versions ? La dernière version stable est v0.147.0 (7 août 2026) – consultez Points forts des versions pour le récit des versions récentes et le Changelog pour chaque mise à jour.¹¹⁶

Codex fonctionne comme un agent de programmation multi-surface, et non comme un chatbot qui écrit du code. CLI lit votre codebase, exécute des commandes dans un sandbox, modifie des fichiers, se connecte à des services externes via MCP et délègue les tâches de longue durée au cloud. Il s’exécute localement tout en pensant globalement ; la même intelligence alimente cinq surfaces distinctes selon votre façon de travailler, y compris la nouvelle extension Chrome qui exécute Codex dans votre navigateur sans en prendre le contrôle.⁹⁰

La différence entre une utilisation occasionnelle et efficace de Codex repose sur cinq systèmes fondamentaux. Maîtrisez-les et Codex deviendra un multiplicateur de force :

1. Système de configuration : contrôle le comportement via config.toml
2. Modèle de sandbox et d’approbation : détermine ce que Codex peut faire
3. AGENTS.md : définit les contrats opérationnels au niveau du projet
4. Protocole MCP : étend les capacités aux services externes
5. Système de skills : regroupe une expertise métier réutilisable

J’ai passé des mois à utiliser Codex aux côtés de Claude Code dans des codebases de production, des pipelines CI/CD et des workflows d’équipe. Ce guide distille cette expérience dans la référence complète que j’aurais aimé trouver à mes débuts. Chaque fonctionnalité comprend une syntaxe réelle, des exemples de configuration concrets et les cas limites qui piègent même les utilisateurs expérimentés.

Points clés

• Cinq interfaces, un seul cerveau : CLI, application de bureau, extension IDE, tâches cloud et nouvelle extension Chrome partagent toutes la même intelligence GPT-5.x-Codex ; choisissez donc l’interface adaptée à votre workflow.⁹⁰
• Sandboxing au niveau de l’OS : Codex applique les restrictions du système de fichiers et du réseau au niveau du noyau (Seatbelt sur macOS, Landlock + seccomp sur Linux), et non à l’intérieur de conteneurs.
• AGENTS.md est inter-outils : les instructions de votre projet fonctionnent dans Codex, Cursor, Copilot, Amp, Jules, Gemini CLI, Windsurf, Cline, Aider, Zed et plus de 60 000 projets open source. Écrivez une fois, utilisez partout.
• Les profils réduisent le coût des changements de contexte : définissez des préréglages de configuration nommés (fast, careful, auto) et basculez entre eux avec --profile.
• La gestion du contexte compte : la famille GPT-5.6 (Sol, Terra, Luna) s’exécute avec une fenêtre de contexte de 272 K ; GPT-5.5, le modèle phare de la génération précédente, offre 400 K dans Codex et 1 M dans le API. Utilisez /compact, des prompts ciblés et des références @file afin de gérer proactivement vos budgets de tokens.⁸³¹¹²

Comment utiliser ce guide

Cette référence compte plus de 3 300 lignes — commencez au niveau correspondant à votre expérience :

La fiche de référence rapide, à la fin, fournit un résumé facilement parcourable de toutes les commandes principales.

Points marquants des versions : changements récents

Le récit version par version, destiné aux lecteurs qui suivent le cycle de publication de Codex. Vous débutez ici ? Ignorez cette section et revenez-y après le démarrage rapide – rien de ce qu’elle contient n’est nécessaire pour être productif.

GPT-5.6 Sol est la valeur par défaut recommandée dans Codex — le réglage « Power » par défaut avec un raisonnement moyen, ajustable vers Smarter ou Faster ; GPT-5.5 (23 avril 2026 : contexte de 400 K dans Codex, 1 M dans le API, 5 $/30 $ par MTok, 82,7 % SOTA sur Terminal-Bench 2.0) est le modèle phare de la génération précédente.⁸³¹¹⁷ Depuis CLI v0.147.0 (stable, 7 août 2026), codex exec --full-auto est supprimé (déprécié depuis la v0.128) — les scripts qui le transmettent encore échouent désormais ; remplacez-le par --sandbox workspace-write avec un indicateur d’approbation ou un profil. La v0.147.0 inclut également --approve-for-me (les demandes d’approbation sont tranchées par un passage de revue automatique), des Agent Plugins portables avec recherche dans des catalogues locaux, personnels, d’espace de travail et distants, le protocole MCP 2026-07-28 à participation volontaire (découverte paginée, requêtes à plusieurs tours, démarrage non bloquant du serveur) et des sections de conversation pour organiser les longues transcriptions.¹¹⁶ La v0.146.0 (stable, 29 juillet) a étendu les proxys configurés à toutes les couches de transport, ajouté les manifestes Agent Plugins ainsi que les marketplaces Amazon Bedrock et Claude Code, le nommage des sessions avec épinglage de threads, et les skills fournis par l’exécuteur ; la v0.146.1 (5 août) a renforcé les valeurs par défaut de la revue automatique pour les modèles aux capacités cyber.¹¹⁴¹¹⁵ Depuis CLI v0.145.0 (stable, 21 juillet 2026), /import migre depuis Cursor ainsi que depuis Claude Code — paramètres, serveurs MCP, plugins, sessions, commandes et mémoires limitées au projet — la voix revient sous forme de conversations realtime V3 en streaming avec entrées audio et sorties d’outils audio dans les formats locaux courants, l’expérience multi-agent v2 à participation volontaire est stabilisée avec des modèles de sous-agents, niveaux de raisonnement et concurrence configurables, un historique de threads paginé expérimental apporte une reprise, une recherche, des noms persistants, la prise en charge des sous-agents et des mémoires efficaces, la connexion expérimentale à Amazon Bedrock est proposée avec prise en charge d’un endpoint et d’une authentification personnalisés (GPT-5.6 Sol comme modèle Bedrock par défaut), et les sélections de modèles GPT-5.4 intégrées migrent vers les variantes GPT-5.6 Terra et Luna ; la v0.144.6 (18 juillet) a corrigé les fenêtres de contexte GPT-5.6 Sol/Terra/Luna à 272 000 tokens.¹¹¹¹¹² Depuis CLI v0.140.0 (stable, 15 juin 2026), /usage affiche l’activité quotidienne, hebdomadaire et cumulée des tokens du compte, les sessions peuvent être supprimées définitivement via codex delete / /delete (avec des garde-fous de confirmation), /import migre sélectivement la configuration, la configuration de projet et les discussions récentes depuis Claude Code, saisir @ ouvre par défaut un menu de mentions unifié pour les fichiers, plugins et skills, et l’authentification gérée par clé API Amazon Bedrock est fournie avec le stockage local chiffré des identifiants CLI et MCP OAuth ; les commandes vocales expérimentales /realtime ont été supprimées du TUI (la voix est revenue plus tard dans la v0.145.0 sous forme de realtime V3 en streaming).¹⁰²¹¹² Depuis CLI v0.139.0 (stable, 9 juin 2026), le mode code peut appeler directement la recherche web autonome (y compris depuis des appels d’outils JavaScript imbriqués) et recevoir des résultats en texte brut, les schémas d’entrée des outils/connecteurs préservent désormais les constructions oneOf/allOf pour une meilleure compatibilité avec les grands schémas et MCP, codex doctor ajoute des détails sur les environnements d’éditeur et de pager (en masquant les valeurs sensibles dans JSON), et la marketplace de plugins expose les sources dans codex plugin marketplace list --json avec un affichage plus rapide des catalogues mis en cache.¹²² La v0.138.0 (8 juin) a ajouté /app pour transférer une session CLI vers l’application de bureau sur macOS et Windows, exposé les chemins d’images locales au modèle, assoupli la sélection de l’effort de raisonnement et fourni à l’automatisation des plugins une sortie JSON structurée ; elle a aussi commencé à chiffrer le texte des tâches parent-vers-sous-agent dans multi-agent v2, afin que les instructions de délégation n’apparaissent plus en clair dans les journaux de session locaux (voir Multi-Agent).¹²³¹⁰⁸ La v0.137.0 (4 juin) a livré multi-agent v2 (runtime conservé par thread, valeurs par défaut plus propres pour les suivis et les métadonnées, hide_spawn_agent_metadata à true par défaut), des raccourcis clavier TUI F13–F24 et une extension skills v1 avec résolution du catalogue à chaque tour.¹²⁴ Depuis CLI v0.135.0 (28 mai 2026), codex doctor signale un inventaire plus riche de l’environnement, de Git, du terminal, de l’app-server et des threads ; /status affiche les détails de connexion distante et la version du serveur lorsque le TUI est connecté à distance ; le mode vim a gagné l’édition par objet de texte, un meilleur comportement pour les fins de mots/lignes et une interruption de tour configurable ; /permissions comprend désormais les profils d’autorisations nommés et affiche les profils personnalisés ; les builds Codex empaquetés découvrent et utilisent l’assistant zsh patché intégré sur les macOS pris en charge ; et le Python SDK expose des préréglages Sandbox conviviaux pour les APIs de thread et de tour.[^179] La v0.134.0 (26 mai 2026) a introduit la recherche dans l’historique local des conversations avec des correspondances de contenu insensibles à la casse et des aperçus de résultats, fait de --profile le sélecteur de profil principal dans CLI, les autorisations TUI et les flux de sandbox (les anciennes configurations de profils sont rejetées avec des indications de migration), amélioré la configuration de MCP avec le ciblage d’environnement par serveur et des options OAuth pour les serveurs HTTP streamables, rendu les schémas des outils de connecteurs plus fiables en préservant les $ref/$defs locaux et en compactant les schémas trop volumineux, permis aux outils MCP en lecture seule de s’exécuter simultanément lorsqu’ils annoncent readOnlyHint, et ajouté un contexte d’extension et de hook plus riche, incluant l’historique des conversations pour les outils d’extension.¹⁰¹ La v0.133.0 (21 mai 2026) a activé les objectifs par défaut avec un stockage dédié et un suivi de la progression ; codex remote-control a obtenu l’état/la disponibilité au premier plan ainsi qu’un démarrage/arrêt de type daemon ; les profils d’autorisations ont gagné des APIs de liste, l’héritage, requirements.toml géré, l’actualisation à l’exécution et une intégration renforcée du sandbox Windows ; la découverte des plugins affiche les versions installées, les racines de marketplace et les collections distantes ; et les extensions peuvent observer le démarrage/l’arrêt des sous-agents, l’exécution des outils, les métadonnées des tours et le traitement asynchrone des approbations/tours. La mise à jour de l’application Codex du 21 mai a ajouté Appshots pour les fenêtres Mac au premier plan, la disponibilité générale du mode Goal dans l’application/l’IDE/CLI, des améliorations d’annotation dans le navigateur intégré et Computer Use verrouillé à participation volontaire pour les utilisateurs Mac éligibles.⁹⁹¹⁰⁰ La v0.132.0 (20 mai 2026) a ajouté l’authentification Python SDK de premier plan, des APIs de tour en texte seul plus simples, un TurnResult plus riche, codex exec resume --output-schema, un démarrage du TUI plus rapide, l’enregistrement d’exécuteurs distants adossé à l’authentification et la préservation de la fidélité des images dans les tours app-server. Utilisez des indicateurs explicites de sandbox/d’approbation ou des profils d’autorisations — l’ancien --full-auto est supprimé depuis la v0.147.0 ; js_repl reste supprimé.^{86878991969798116}

Note de stabilité : les fonctionnalités marquées [EXPERIMENTAL] ou under development sont susceptibles d’évoluer entre les versions. Depuis la v0.133.0 (21 mai 2026), les objectifs sont activés par défaut, les profils d’autorisations constituent une surface gérée de premier plan, la découverte des plugins est plus inspectable et remote-control est plus facile à exécuter comme commande app-server au premier plan ou daemonisée. Codex Cloud et le mode code restent expérimentaux ou en cours de développement, tandis que les surfaces principales CLI, sandboxing, AGENTS.md, config.toml, Skills, hooks, outils multi-agent, plugins, Browser, Computer Use et Appshots sont stables ou documentées pour les utilisateurs selon la plateforme et le plan. La v0.132.0 complète l’authentification Python SDK et l’automatisation de reprise structurée ; la v0.131.0 a ajouté codex doctor, la recherche de mentions @ unifiée, les commandes CLI de marketplace, le partage de plugins tenant compte des versions, remote-control géré par daemon avec activation/désactivation à l’exécution, les environnements adossés à un registre et un renforcement supplémentaire du sandbox Windows.⁹⁶⁹⁷⁹⁸ L’ancien --full-auto a été supprimé dans la v0.147.0 (déprécié depuis la v0.128) et js_repl reste supprimé.^8687116

Fonctionnement de Codex : le modèle mental

Avant d’explorer les fonctionnalités, comprenez comment l’architecture de Codex façonne tout ce que vous faites avec lui. Le système fonctionne sur cinq surfaces, soutenues par une couche d’intelligence partagée :

┌─────────────────────────────────────────────────────────┐
│                    CODEX SURFACES                       │
├─────────────────────────────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐   │
│  │   CLI    │  │ Desktop  │  │   IDE    │  │ Cloud  │   │
│  │ Terminal │  │   App    │  │Extension │  │  Tasks │   │
│  └──────────┘  └──────────┘  └──────────┘  └────────┘   │
│  Local exec     Multi-task    Editor-native  Async      │
│  + scripting    + worktrees   + inline edits detached   │
│  ┌──────────┐                                           │
│  │  Chrome  │  Signed-in browser workflows              │
│  │Extension │  (launched May 2026)                      │
│  └──────────┘                                           │
├─────────────────────────────────────────────────────────┤
│  EXTENSION LAYER                                        │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │   MCP   │  │ Skills  │  │  Apps   │  │  Search │     │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘     │
│  External tools, reusable expertise, ChatGPT            │
│  connectors, web search (cached + live)                 │
├─────────────────────────────────────────────────────────┤
│  SECURITY LAYER                                         │
│  ┌─────────────────────────────────────────────────┐    │
│  │    Sandbox (Seatbelt / Landlock / seccomp)      │    │
│  │    + Approval Policy (untrusted → never)        │    │
│  └─────────────────────────────────────────────────┘    │
│  OS-level filesystem + network restrictions             │
├─────────────────────────────────────────────────────────┤
│  CORE LAYER                                             │
│  ┌─────────────────────────────────────────────────┐    │
│  │         GPT-5.x-Codex Intelligence              │    │
│  │   Tools: Shell, Patch, Read, Web Search         │    │
│  │   (legacy artifact, read_file, grep_files       │    │
│  │    removed in v0.117.0)                         │    │
│  └─────────────────────────────────────────────────┘    │
│  Shared model across all surfaces; costs tokens         │
└─────────────────────────────────────────────────────────┘

Couche centrale : la famille de modèles GPT-5.x alimente l’ensemble. En août 2026, gpt-5.6-sol est le modèle par défaut recommandé — le réglage « Power », avec un niveau de raisonnement moyen — aux côtés de Terra (usage quotidien) et Luna (rapide et abordable) ; gpt-5.5 est le modèle phare de la génération précédente (contexte de 400K dans Codex, 1M dans le API), et gpt-5.4 quitte Codex le 31 août 2026.⁸³¹¹⁷ Il lit les fichiers, écrit des correctifs, exécute des commandes shell et raisonne sur votre base de code. Lorsque le contexte se remplit, Codex compacte la conversation pour libérer de l’espace. Cette couche consomme des tokens.

Couche de sécurité : chaque commande exécutée par Codex passe par un sandbox au niveau du système d’exploitation. Sur macOS, le framework Seatbelt d’Apple applique des restrictions au niveau du noyau. Sous Linux, Landlock + seccomp filtrent l’accès au système de fichiers et aux appels système. Le sandbox fonctionne au niveau du noyau, et non dans des conteneurs. La politique d’approbation décide ensuite à quel moment demander une confirmation humaine.

Couche d’extension : MCP connecte des services externes (GitHub, Figma, Sentry). Les skills regroupent des workflows réutilisables que Codex charge à la demande. Les apps se connectent aux connecteurs ChatGPT. La recherche Web apporte du contexte en temps réel depuis Internet.

Couche de surface : CLI pour les utilisateurs avancés du terminal et l’automatisation. L’application de bureau pour la gestion de projets multithread. L’extension IDE pour les boucles modification-compilation-test. Le Cloud pour les tâches asynchrones exécutées de manière indépendante.

L’idée essentielle : la plupart des utilisateurs n’emploient qu’une seule surface. Les utilisateurs avancés utilisent les cinq : le Cloud pour les tâches de longue durée, CLI pour des opérations déterministes sur le dépôt, l’extension IDE pour des boucles de code serrées, l’application de bureau pour la planification et la coordination, et Chrome pour les workflows de navigateur avec connexion.

Table des matières

1. Comment installer Codex ?
2. Démarrage rapide : votre première session
3. Surfaces d’interaction principales
4. Exploration approfondie du système de configuration
5. Quel modèle choisir ?
6. Quel est le coût de Codex ?
7. Cadres de décision
8. Comment fonctionne le système de sandbox et d’approbation ?
9. Comment fonctionne AGENTS.md ?
10. Hooks
11. Qu’est-ce que MCP (Model Context Protocol) ?
12. Code Mode
13. Runtime REPL JavaScript
14. Que sont les skills ?
15. Plugins
16. Plan Mode et collaboration
17. Système de mémoire
18. Gestion des sessions
19. Mode non interactif (codex exec)
20. Codex Cloud et tâches en arrière-plan
21. L’application de bureau Codex
22. Action GitHub et CI/CD
23. Codex SDK
24. Optimisation des performances
25. Comment déboguer les problèmes ? – y compris codex doctor
26. Déploiement en entreprise
27. Bonnes pratiques et anti-patterns
28. Recettes de workflow
29. Guide de migration
30. Carte de référence rapide
31. Journal des modifications
32. Références

Comment installer Codex ?

Gestionnaires de paquets

# npm (recommended)
npm install -g @openai/codex

# Homebrew (macOS)
brew install --cask codex

# winget (Windows)
winget install OpenAI.Codex

# Upgrade to latest
npm install -g @openai/codex@latest

Comment mettre à jour, rétrograder ou désinstaller le CLI Codex ?

Depuis la v0.128.0, Codex propose une commande d’auto-mise à jour ; tout le reste passe par le gestionnaire de paquets utilisé pour l’installation.⁸⁶ Depuis la v0.146.0, les artefacts de version, les métadonnées de canal et les alias d’installation sont servis depuis l’infrastructure de publication hébergée par OpenAI, avec GitHub comme solution de repli.¹¹⁴ Si votre réseau autorise GitHub pour les installations et mises à jour de Codex, ajoutez également l’hôte de publication OpenAI — la solution de repli permet à une omission dans la liste d’autorisation de se dégrader discrètement plutôt que d’échouer de façon explicite.

# Check what you are running
codex --version                          # -> codex-cli 0.147.0
npm view @openai/codex version           # Latest published version

# Update
codex update                             # Built-in self-update (v0.128.0+)
npm install -g @openai/codex@latest      # Or update via npm
brew upgrade --cask codex                # Or via Homebrew

# Pin or downgrade to an exact version
npm install -g @openai/codex@0.144.6

# Uninstall
npm uninstall -g @openai/codex
brew uninstall --cask codex
winget uninstall OpenAI.Codex

Épingler une version est la bonne décision lorsqu’une version vous bloque. Codex suit une branche stable à évolution rapide ; installer une version précise est le moyen le plus rapide de revenir en arrière — signalez le problème, épinglez la version et continuez. Vérifiez que le retour en arrière a bien pris effet avec codex --version, car une seconde installation masquée dans votre PATH peut continuer silencieusement à fournir l’ancien binaire (codex doctor le signale précisément dans la section Environment).

Désinstaller le paquet ne supprime pas votre état. L’authentification, la configuration et l’historique des sessions se trouvent dans ~/.codex/. Laissez-le en place pour conserver vos connexions et votre historique après une réinstallation ; supprimez-le uniquement si vous souhaitez réellement repartir de zéro — rm -rf ~/.codex supprime également config.toml, auth.json et toutes les sessions enregistrées.

Script d’installation direct (v0.106.0+)

Pour macOS et Linux, un script d’installation en une ligne est disponible en tant qu’artefact de version GitHub :⁶⁰

curl -fsSL https://github.com/openai/codex/releases/latest/download/install.sh | sh

Le script détecte automatiquement votre plateforme et votre architecture, télécharge le bon binaire et le place dans votre PATH.

Téléchargements de binaires

Pour les environnements sans npm ni Homebrew, téléchargez les binaires spécifiques à votre plateforme depuis GitHub Releases¹ :

Configuration système requise

• macOS : Apple Silicon ou Intel (prise en charge complète du sandbox via Seatbelt)
• Linux : x86_64 ou arm64 (sandbox via Landlock + seccomp)
• Windows : sandbox natif avec jetons restreints (passé du statut expérimental au statut stable dans la v0.100.0). WSL est également pris en charge²

Authentification

codex login                  # Interactive OAuth (recommended)
codex login --device-auth    # OAuth device code flow (headless)
codex login --with-api-key   # API key from stdin
codex login status           # Check auth state (exit 0 = logged in)
codex logout                 # Clear stored credentials

Deux méthodes d’authentification :

1. Compte ChatGPT (recommandé) : connectez-vous avec votre abonnement Plus, Pro, Team, Business, Edu ou Enterprise existant. Accès complet aux fonctionnalités, y compris aux cloud tasks.
2. Clé API : définissez-la via la variable d’environnement CODEX_API_KEY ou codex login --with-api-key. Certaines fonctionnalités (cloud threads) peuvent être indisponibles.

Conseil d’expert : le stockage des identifiants est configurable via cli_auth_credentials_store dans config.toml. Options : file (par défaut), keyring (trousseau du système d’exploitation) ou auto (keyring s’il est disponible, sinon file).

Connexion Amazon Bedrock (v0.145.0, expérimentale) : les équipes dont l’accès aux modèles passe par Amazon Bedrock disposent d’un parcours de connexion expérimental prenant en charge des endpoints et une authentification personnalisés, en complément de l’authentification existante par clé API gérée (v0.140.0+) et de la chaîne d’identifiants AWS (voir Custom Model Providers). GPT-5.6 Sol est le modèle Bedrock par défaut.¹¹²

Complétions du shell

# Generate completions for your shell
codex completion bash > /etc/bash_completion.d/codex
codex completion zsh > ~/.zsh/completions/_codex
codex completion fish > ~/.config/fish/completions/codex.fish

Vérifier l’installation

codex --version
# codex-cli 0.147.0

Démarrage rapide : votre première session

Passez de zéro à productif en 5 minutes.

1. Installez et authentifiez-vous :

npm i -g @openai/codex          # Install
codex login                      # Log in with your OpenAI account

2. Accédez à un projet :

cd ~/my-project                  # Any git repo works

3. Démarrez Codex :

codex

Vous verrez le TUI interactif. Codex lit automatiquement la structure de votre projet.

4. Posez une question :

> What does this project do? Summarize the architecture.

Codex lit les fichiers clés et explique la base de code. Une question de ce type n’apporte aucune modification — Codex ne modifie les fichiers que lorsque vous demandez un changement, et le sandbox ainsi que la politique d’approbation déterminent quand il doit demander votre accord au préalable.

5. Effectuez une modification :

> Add input validation to the login endpoint

Codex propose les modifications sous forme de diff. Examinez-les et approuvez avec y, ou refusez avec n.

6. Utilisez une slash command :

> /plan Refactor the database layer to use connection pooling

Codex crée un plan sans l’exécuter. Examinez le plan, puis approuvez-le pour commencer l’exécution.

7. Vérifiez votre travail :

> /diff

Affichez toutes les modifications apportées par Codex au cours de la session actuelle.

Quelle est la suite : - Configurez AGENTS.md avec les instructions du projet (voir Comment fonctionne AGENTS.md ?) - Configurez un profil adapté à votre workflow (voir Profiles) - Essayez codex exec pour l’automatisation non interactive (voir Mode non interactif)

Surfaces d’interaction principales

Codex propose cinq interfaces distinctes, reposant sur la même intelligence. Chaque surface est optimisée pour un type de flux de travail différent.

1. CLI interactif (Terminal UI)

codex                        # Launch TUI
codex "fix the failing tests" # Launch with initial prompt
codex -m gpt-5.5            # Specify model
codex --sandbox workspace-write --ask-for-approval on-request

L’interface de terminal est une application plein écran comprenant :

• Composer : saisissez des prompts, joignez des fichiers avec @, exécutez des commandes shell avec le préfixe !
• Volet de sortie : réponses du modèle en flux continu, appels d’outils et sortie des commandes
• Barre d’état : modèle, utilisation des tokens, branche git, mode sandbox

Raccourcis TUI principaux :

Modification de la ligne d’état (v0.121.0) : l’ancien indicateur de fenêtre de contexte de la ligne d’état a été remplacé par un indicateur de pourcentage de contexte montrant le taux de remplissage de votre fenêtre de contexte. Si des scripts ou hooks analysent la ligne d’état, vérifiez ce changement de format.⁸² Codex affichera également une annonce de mise à jour de CLI lorsqu’une nouvelle version sera disponible.

Slash commands disponibles dans le TUI :

Refonte du sélecteur de flux de travail (v0.129.0) : les options de reprise et de duplication sont désormais plus faciles d’accès depuis un sélecteur repensé, et un nouveau mode de défilement brut vous permet de parcourir la transcription non rendue lorsque vous devez copier des commandes ou la sortie du modèle textuellement. Utile pour trier une longue session de débogage ou envoyer la sortie à un autre outil.⁸⁹

Menu unifié de mentions @ (v0.140.0) : saisir @ dans le composer ouvre désormais par défaut un unique menu de mentions couvrant les fichiers, les plugins et les skills, remplaçant le flux d’ajout de fichiers uniquement — une seule frappe pour référencer n’importe quelle ressource du projet.¹⁰²

2. Codex Desktop App (macOS + Windows)

codex app                    # Launch desktop app (auto-installs if missing)

L’application de bureau ajoute des capacités que le CLI ne possède pas :

• Multitâche : exécutez simultanément plusieurs agents parallèles sur différents projets
• Isolation par git worktree : chaque fil travaille sur une copie isolée de votre dépôt
• Révision de diff en ligne : indexez, annulez et validez les modifications sans quitter l’application
• Terminal intégré : terminal par fil pour exécuter des commandes
• Duplication de conversations : créez des branches de conversation pour explorer des alternatives
• Fenêtres détachables flottantes : détachez les conversations dans des fenêtres portables
• Automatisations : planifiez des tâches récurrentes (triage des tickets, surveillance CI, réponse aux alertes)
• Appshots : joignez à un fil la fenêtre de l’application Mac au premier plan avec une capture d’écran et le texte disponible
• Commentaires dans le navigateur intégré : prévisualisez des pages locales ou publiques, laissez des commentaires sur des éléments ou zones, et laissez Codex traiter des retours visuels précis
• Computer Use : laissez Codex utiliser les applications Mac autorisées pour un travail GUI ciblé ; l’utilisation verrouillée est facultative pour les tours Remote Mac Computer Use éligibles

ChatGPT Voice, propulsé par GPT-Live (desktop 26.715, 23 juillet 2026) : l’application de bureau peut désormais être pilotée à la voix — échangez à propos du travail et coordonnez des tâches dans Chat, Work et Codex sans saisir de texte. Sous macOS, l’activation de Screen context partage un appshot de votre fenêtre au premier plan avec la conversation ; vous pouvez ainsi poser des questions sur ce que vous regardez au lieu de le décrire. Disponible sur les offres Plus, Pro, Business, Edu et Enterprise, dans l’application de bureau et via Remote sur iOS. Il s’agit de la fonctionnalité vocale de la surface de bureau ; la transcription vocale par barre d’espace du CLI est une fonctionnalité distincte et expérimentale.¹¹³

Quand utiliser l’application plutôt que le CLI : utilisez l’application de bureau lorsque vous coordonnez plusieurs flux de travail ou avez besoin d’une révision visuelle des diffs. Utilisez le CLI lorsque vous recherchez la composabilité du terminal, le scripting ou l’intégration CI/CD.

3. Extension IDE (VS Code, Cursor, Windsurf)

L’extension Codex IDE s’intègre directement dans votre éditeur :

• Mode Agent par défaut : lit les fichiers, effectue des modifications et exécute des commandes
• Modifications en ligne : suggestions tenant compte du contexte dans vos fichiers actifs
• Sessions partagées : les sessions se synchronisent entre le CLI et l’extension IDE
• Même authentification : connectez-vous avec un compte ChatGPT ou une clé API

Installez-la depuis le VS Code Marketplace ou les boutiques d’extensions Cursor/Windsurf.³

4. Codex Cloud [EXPERIMENTAL]

Les tâches cloud s’exécutent de manière asynchrone dans des environnements gérés par OpenAI :

• Exécution sans attente : mettez en file d’attente des tâches qui s’exécutent indépendamment de votre machine locale
• Exécution parallèle : exécutez simultanément plusieurs tâches cloud
• Création de PR : Codex crée des pull requests à partir du travail terminé
• Application locale : récupérez les résultats cloud dans votre dépôt local avec codex apply <TASK_ID>

codex cloud list             # List recent cloud tasks
codex apply <TASK_ID>        # Apply diff from a specific cloud task

Les tâches cloud sont également accessibles depuis chatgpt.com/codex.⁴

5. Codex for Chrome [NEW]

Codex est proposé sous la forme d’une extension de navigateur pour Chrome, ajoutant une cinquième surface aux côtés du CLI, de l’application de bureau, de l’extension IDE et du cloud. L’extension est conçue pour accompagner votre navigation habituelle plutôt que pour la prendre en charge : Codex travaille en parallèle sur les onglets en arrière-plan, et vous gardez le contrôle des sites auxquels il accède.⁹⁰

• Exécution parallèle dans les onglets : Codex opère simultanément sur plusieurs onglets sans verrouiller l’onglet au premier plan.
• Contrôle par site : vous autorisez les sites web avec lesquels Codex peut interagir ; aucun accès n’est accordé par défaut.
• Le navigateur comme environnement de travail : l’extension est idéale pour le travail sur les applications et sites web où la page est la source de vérité — consoles d’administration, tableaux de bord internes, interfaces de gestion de contenu, systèmes de tickets — et ne remplace pas le CLI pour les dépôts locaux.
• Même intelligence : Codex for Chrome utilise la même intelligence GPT-5.x-Codex que les autres surfaces ; une configuration AGENTS.md ou de skills qui fonctionne dans le CLI conserve donc les mêmes conventions pour le travail piloté par navigateur.

Installez-la depuis la documentation de l’extension Codex Chrome.⁹⁰

Analyse approfondie du système de configuration

Codex utilise TOML pour sa configuration. Il est essentiel de comprendre la hiérarchie de priorité, car elle détermine quels paramètres l’emportent en cas de conflit.

Priorité (de la plus élevée à la plus faible)

1. Remplacements de session (priorité maximale) : indicateurs CLI (--model, --sandbox, --ask-for-approval, --search, --enable/--disable, --profile) et remplacements -c key=value
2. Configuration du projet (.codex/config.toml, détectée depuis le CWD jusqu’à la racine du projet ; le répertoire le plus proche l’emporte)
3. Configuration utilisateur ($CODEX_HOME/config.toml, utilise par défaut ~/.codex/config.toml)
4. Configuration système (/etc/codex/config.toml sous Unix)
5. Valeurs par défaut intégrées (priorité minimale)

requirements.toml sert de couche de contraintes de politique qui limite les valeurs que les utilisateurs peuvent sélectionner après la fusion normale des configurations. Consultez Déploiement en entreprise.

Emplacements des fichiers de configuration

Conseil d’expert : la variable d’environnement CODEX_HOME remplace le répertoire ~/.codex par défaut. Utile pour les configurations CI/CD ou multi-comptes.

Projets Desktop à plusieurs dossiers (26.715, 23 juillet 2026) : un projet local dans l’application de bureau ChatGPT peut désormais couvrir plusieurs dossiers associés, dont l’un est désigné comme dossier principal (menu du projet → Edit project). La détection automatique de config.toml s’exécute uniquement sur le dossier principal ; les dossiers secondaires restent disponibles pour la recherche, la lecture et la modification de fichiers, mais ne contribuent à aucune configuration. Un fichier .codex/config.toml situé dans un dossier secondaire est un fichier que Codex peut lire, et non une configuration qu’il charge. Il s’agit du périmètre des projets de l’application de bureau, et non d’une modification des règles de priorité ci-dessus — le CLI résout toujours la configuration du projet en remontant depuis le répertoire de travail actuel.¹¹³

Référence complète de la configuration

# ~/.codex/config.toml — annotated reference

# ─── Model Selection ───────────────────────────────────
model = "gpt-5.6-sol"                  # Recommended default (the "Power" setting)
model_provider = "openai"               # Provider (openai, oss, or custom provider id)
model_context_window = 272000           # Token count available to active model (override)
model_auto_compact_token_limit = 200000 # Threshold triggering automatic history compaction
model_reasoning_effort = "medium"       # minimal|low|medium|high|xhigh (model-dependent)
model_reasoning_summary = "auto"        # auto|concise|detailed|none
model_verbosity = "medium"              # low|medium|high
personality = "pragmatic"               # none|friendly|pragmatic
review_model = "gpt-5.5"               # Optional model for /review command
service_tier = "fast"                  # Preferred service tier for new turns
oss_provider = "lmstudio"              # lmstudio|ollama (used with --oss)

# ─── Sandbox & Approval ───────────────────────────────
sandbox_mode = "workspace-write"        # read-only|workspace-write|danger-full-access
approval_policy = "on-request"          # untrusted|on-request|never

[sandbox_workspace_write]
writable_roots = []                     # Additional writable paths
network_access = false                  # Allow outbound network
exclude_tmpdir_env_var = false          # Exclude $TMPDIR from sandbox
exclude_slash_tmp = false               # Exclude /tmp from sandbox

# ─── Web Search ────────────────────────────────────────
web_search = "live"                     # Web search mode (constrained by allowed modes)

# ─── Instructions ──────────────────────────────────────
developer_instructions = ""             # Additional injected instructions
model_instructions_file = ""            # Custom instructions file path
compact_prompt = ""                     # Custom history compaction prompt

# ─── Shell Environment ─────────────────────────────────
allow_login_shell = false               # Allow login shell semantics (loads .profile/.zprofile)

[shell_environment_policy]
inherit = "all"                         # all|core|none
ignore_default_excludes = false         # Set true to keep KEY/SECRET/TOKEN vars
exclude = []                            # Glob patterns to exclude
set = {}                                # Explicit overrides
include_only = []                       # Whitelist patterns

# ─── Authentication ────────────────────────────────────
cli_auth_credentials_store = "file"     # file|keyring|auto
forced_login_method = "chatgpt"         # chatgpt|api
mcp_oauth_callback_port = 0            # Fixed port for MCP OAuth callback (0 = random)
mcp_oauth_credentials_store = "auto"   # auto|file|keyring

# ─── History & Storage ─────────────────────────────────
[history]
persistence = "save-all"                # save-all|none
max_bytes = 0                           # Cap size (0 = unlimited)

tool_output_token_limit = 10000         # Max tokens per tool output
log_dir = ""                            # Custom log directory
sqlite_home = ""                        # Override SQLite-backed resumable state location

# ─── UI & Display ──────────────────────────────────────
file_opener = "vscode"                  # vscode|vscode-insiders|windsurf|cursor|none
hide_agent_reasoning = false
show_raw_agent_reasoning = false
check_for_update_on_startup = true

[tui]
notifications = false                   # Enable notifications
notification_method = "auto"            # auto|osc9|bel
animations = true
show_tooltips = true
alternate_screen = "auto"               # auto|always|never
status_line = ["model", "context-remaining", "git-branch"]

# ─── Project Trust ─────────────────────────────────────
project_doc_max_bytes = 32768           # Max AGENTS.md size (32 KiB)
project_doc_fallback_filenames = []     # Alternative instruction filenames
project_root_markers = [".git"]         # Project root detection

# ─── Feature Flags ─────────────────────────────────────
# Use `codex features list` for current names/stages/defaults.
[features]
shell_tool = true                       # Shell command execution (stable)
unified_exec = true                     # PTY-backed exec (stable)
shell_snapshot = true                   # Shell env snapshots (stable)
enable_request_compression = true       # zstd request compression where supported (stable)
fast_mode = true                        # Service-tier selection and Fast-tier commands (stable)
goals = true                            # Goal mode; stable and on by default in v0.133.0+
hooks = true                            # Lifecycle hooks (stable)
multi_agent = true                      # Enable multi-agent collaboration tools (stable)
personality = true                      # Personality selection (stable)
plugins = true                          # Plugin system (stable)
plugin_hooks = true                     # Plugin-bundled hooks (stable)
plugin_sharing = true                   # Workspace plugin sharing (stable)
browser_use = true                      # In-app browser automation (stable)
browser_use_external = true             # Chrome extension browser use (stable)
computer_use = true                     # macOS Computer Use (stable, plan/region gated)
in_app_browser = true                   # Shared rendered-page preview (stable)
image_generation = true                 # Image-generation tool (stable)
guardian_approval = true                # Auto-review approval path (stable)
skill_mcp_dependency_install = true     # Prompt/install missing skill MCP deps (stable)
tool_suggest = true                     # Tool/plugin suggestion surface (stable)
workspace_dependencies = true           # Workspace dependency discovery (stable)
memories = true                         # Memories (experimental)
network_proxy = false                   # Sandboxed networking proxy (experimental)
prevent_idle_sleep = true               # Keep machine awake during active turns (experimental)
terminal_resize_reflow = true           # Terminal reflow improvements (experimental)

# Removed or deprecated feature names still appear in `codex features list`
# for migration diagnostics. Do not set removed flags such as
# `collaboration_modes`, `request_rule`, `codex_git_commit`,
# `apply_patch_freeform`, `search_tool`, or `js_repl` in new configs.

# ─── Multi-Agent Roles (v0.102.0+) ───────────────────
[agents]
max_threads = 4                         # Maximum concurrent agent threads

[agents.explorer]
description = "Read-only codebase navigator"
config_file = "~/.codex/profiles/explorer.toml"

# ─── Notifications ────────────────────────────────────
notify = ["terminal-notifier", "-title", "Codex"]  # Command for notifications

# ─── Per-Project Overrides ────────────────────────────
[projects."/absolute/path/to/repo"]
trust_level = "trusted"                 # Per-project trust override

Profils

Préréglages de configuration nommés pour différents modes de travail :

# Define profiles in ~/.codex/config.toml

[profiles.fast]
model = "gpt-5.6-luna"
model_reasoning_effort = "low"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
personality = "pragmatic"

[profiles.careful]
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
approval_policy = "untrusted"
sandbox_mode = "read-only"

[profiles.auto]
model = "gpt-5.6-sol"
model_reasoning_effort = "medium"
approval_policy = "never"
sandbox_mode = "workspace-write"

Activez un profil :

codex --profile fast "quick refactor"
codex --profile careful "security audit"
codex -p auto "fix CI"

Conseil d’expert : définissez un profil par défaut avec profile = "fast" au niveau supérieur de votre configuration. Remplacez-le pour chaque session avec --profile.

Fournisseurs de modèles personnalisés

Connectez-vous à Azure, AWS Bedrock, à des modèles locaux ou à des services proxy :

[model_providers.azure]
name = "Azure OpenAI"
base_url = "https://YOUR_PROJECT.openai.azure.com/openai"
wire_api = "responses"
query_params = { api-version = "2025-04-01-preview" }
env_key = "AZURE_OPENAI_API_KEY"

# Built-in amazon-bedrock provider (v0.123.0+, first-class in v0.124.0+)
# AWS SigV4 signing + credential-based auth; AWS profile selectable via the
# nested `aws.profile` field (NOT a top-level `aws_profile` key).
# v0.130.0+ also accepts credentials from `aws login` (the AWS console-login
# flow) — Codex resolves the cached console-login session for the chosen
# profile if static keys are absent.
# v0.140.0+ adds managed Amazon Bedrock API-key authentication, and stores
# CLI and MCP OAuth credentials in encrypted local storage.[^184]
[model_providers.amazon-bedrock]
name = "Amazon Bedrock"

[model_providers.amazon-bedrock.aws]
profile = "default"                   # any profile from ~/.aws/credentials
# Region/credential resolution otherwise follows the standard AWS chain;
# v0.130.0 added support for `aws login` console-login profiles in addition
# to static access keys and IAM role assumption.[^168]

[model_providers.ollama]
name = "Ollama (Local)"
base_url = "http://localhost:11434/v1"
wire_api = "chat"

Avertissement : le API filaire chat/completions (wire_api = "chat") a été déprécié pour les modèles hébergés par OpenAI, OpenAI ayant annoncé sa suppression en février 2026.³⁴ Les fournisseurs locaux (Ollama, LM Studio) peuvent encore accepter ce format. Pour les points de terminaison OpenAI, utilisez plutôt wire_api = "responses".

Utilisez des modèles locaux avec l’indicateur --oss :

codex --oss "explain this function"               # Uses default OSS provider
codex --oss --local-provider lmstudio "explain"   # Explicit LM Studio
codex --oss --local-provider ollama "explain"      # Explicit Ollama

Ou définissez-le dans la configuration :

model_provider = "oss"
oss_provider = "lmstudio"   # or "ollama"

Remplacements de configuration en ligne

Remplacez n’importe quelle valeur de configuration depuis la ligne de commande :

codex -c model="gpt-5.5" "refactor the API"
codex -c 'sandbox_workspace_write.network_access=true' "install dependencies"
codex -c model_reasoning_effort="xhigh" "debug the race condition"

Quel modèle choisir ?

Modèles disponibles (août 2026)

GPT-5.5 (23 avril 2026) était le choix recommandé par OpenAI pour la plupart des tâches Codex lors de son lancement : code complexe, utilisation d’ordinateur, travail de connaissance et flux de recherche. Disponible dans Codex CLI / web / desktop le 23 avril pour ChatGPT Plus / Pro / Business / Enterprise / Edu / Go ; dans l’OpenAI API le 24 avril. Fenêtre de contexte : 400K dans Codex, 1M dans le API — Codex limite la fenêtre à 400K afin d’équilibrer le débit et le coût entre les niveaux d’abonnement ; le API expose les 1M complets. Tarification (API) : 5 $ en entrée / 30 $ en sortie par MTok (2× le tarif de GPT-5.4 ; OpenAI indique une hausse effective d’environ 20 % après les améliorations d’efficacité des tokens). Benchmarks : 82,7 % sur Terminal-Bench 2.0 (SOTA actuel parmi les modèles disponibles publiquement), 84,9 % sur GDPval (44 professions), 78,7 % sur OSWorld-Verified, 98,0 % sur Tau2-bench Telecom (sans ajustement de prompt). OpenAI a utilisé GPT-5.5 + Codex en interne pour réécrire l’infrastructure de serving avant le lancement — ce qui a augmenté de 20 % la vitesse de génération des tokens.⁸³

GPT-5.4 et GPT-5.4 mini seront retirés de Codex le 31 août 2026.¹¹⁷ D’ici là, GPT-5.4 reste sélectionnable sur les surfaces Codex.⁶⁴ La liste exacte des modèles varie selon le compte et le déploiement. Consultez votre cache local : ~/.codex/models_cache.json.

Note de dépréciation (11 mars 2026) : les modèles GPT-5.1 ne sont plus disponibles dans ChatGPT. Les conversations existantes continuent automatiquement avec GPT-5.3 Instant, GPT-5.4 Thinking ou GPT-5.4 Pro. GPT-5.1-Codex-Mini est resté disponible via API et CLI jusqu’à son arrêt le 23 juillet 2026.⁷¹⁸⁸

Note sur le niveau gratuit (5 mai 2026) : GPT-5.5 Instant a été déployé sur le niveau gratuit de ChatGPT le 5 mai 2026. Cela élargit l’audience de la famille GPT-5.5 au-delà des offres payantes, bien que l’accès à Codex CLI continue de nécessiter un abonnement Plus / Pro / Business / Enterprise / Edu / Go éligible ou une clé API.⁹²

GPT-5.4 mini (17 mars 2026) : une variante plus petite et plus rapide de GPT-5.4, avec un contexte de 400K à 0,75 $/4,50 $ par MTok — elle n’utilise que 30 % du quota de GPT-5.4. Idéal pour la délégation à des sous-agents : laissez GPT-5.4 gérer la planification et la coordination pendant que les sous-agents GPT-5.4 mini traitent en parallèle des sous-tâches plus ciblées (recherche dans la base de code, revue de fichiers, traitement de documents).⁷⁶

Bedrock GPT-5.6 (Sol, Terra, Luna) (v0.143.0, 8 juillet 2026) : Codex a ajouté une prise en charge de premier ordre de trois variantes de modèle GPT-5.6 hébergées sur Amazon Bedrock, y compris du niveau d’effort de raisonnement max. Pour les équipes dont l’accès aux modèles passe par un fournisseur Bedrock, elles sont sélectionnables de la même façon que les autres modèles de fournisseurs personnalisés (voir Fournisseurs de modèles personnalisés) ; le niveau d’effort max cible les charges de travail de raisonnement et agentiques les plus difficiles.¹⁰⁶ v0.144.6 (18 juillet 2026) a actualisé les instructions groupées pour Sol, Terra et Luna, et corrigé leurs fenêtres de contexte à 272 000 tokens.¹¹¹ v0.145.0 (21 juillet 2026) ajoute une connexion Bedrock expérimentale avec prise en charge d’un endpoint et d’une authentification personnalisés, fait de GPT-5.6 Sol le modèle Bedrock par défaut, et migre les sélections groupées de modèles GPT-5.4 vers les variantes Terra et Luna correspondantes.¹¹²

Organigramme de sélection du modèle

Is this a quick fix or simple question?
├─ Yes → gpt-5.6-luna (fastest, most affordable)
└─ No
   ├─ Do you need real-time pairing speed?
   │  ├─ Yes → gpt-5.3-codex-spark (near-instant, Pro only)
   │  └─ No
   │     ├─ Subagent or parallel subtask (search, review, processing)?
   │     │  ├─ Yes → gpt-5.6-luna (the bundled subagent pick since v0.145.0)
   │     │  └─ No
   │     │     ├─ Everyday coding task (refactor, migration, feature build)?
   │     │     │  ├─ Yes → gpt-5.6-terra (everyday model, 272K context)
   │     │     │  └─ No → gpt-5.6-sol (flagship — the default "Power" setting)
   └─ Still unsure? → gpt-5.6-sol

Effort de raisonnement

Contrôlez à quel point le modèle « réfléchit » avant de répondre :

Les niveaux pris en charge dépendent du modèle. minimal est disponible uniquement pour les modèles GPT-5. Tous les modèles ne prennent pas en charge chaque niveau.

codex -c model_reasoning_effort="xhigh" "find the race condition"

Conseil d’expert : le raisonnement xhigh peut utiliser 3 à 5× plus de tokens que medium pour le même prompt. Réservez-le aux problèmes réellement difficiles, lorsque cette réflexion supplémentaire est justifiée.

Commandes rapides de raisonnement dans le TUI (v0.124.0+).⁸⁵ Dans une session TUI interactive, Alt+, réduit le raisonnement d’un niveau et Alt+. l’augmente d’un niveau — utile lorsqu’un problème difficile en cours de session justifie une montée temporaire de medium → high → xhigh sans /effort ni -c. Lorsque vous acceptez une mise à niveau de modèle en cours de session, le raisonnement est réinitialisé au niveau par défaut du nouveau modèle au lieu de conserver le niveau précédent.

Changer de modèle

Changez de modèle en cours de session avec la slash command /model, ou définissez-le pour chaque exécution via --model / -m :

codex -m gpt-5.3-codex-spark "pair with me on this component"

Combien coûte Codex ?

Consultez aussi Sélection du modèle pour les capacités et Cadres de décision pour choisir le bon modèle selon la tâche.

Accès via les forfaits ChatGPT

La disponibilité de Codex dépend de votre forfait ChatGPT et des paramètres de votre organisation :⁵¹

Mise à jour des tarifs d’avril 2026 : Le tarif annuel de Business est passé de $25 à $20/siège/mo. Des sièges Codex uniquement avec une tarification à l’usage sont désormais disponibles pour les espaces de travail Business et Enterprise — sans frais de siège fixes, avec facturation selon la consommation de tokens.⁷⁹ La page de tarification publie désormais les limites sous forme de plages par modèle (voir le tableau ci-dessus), plutôt que les multiplicateurs promotionnels de 2x du lancement de Desktop App en février 2026.¹⁶¹¹⁹

Augmentation des limites d’utilisation de mai 2026 (expirée le 31 mai 2026) : Codex dans le forfait Plus fonctionnait avec une limite de 25× sur 5 heures (contre l’augmentation standard de 20×), et le niveau à $100/mois était doublé pour cette même fenêtre.⁸⁹

Coût en crédits

Les opérations Codex consomment des crédits de l’allocation de votre forfait :

En pratique, « l’utilisation de GPT-5.6 atteint en moyenne 5-40 crédits par message » ; le mode rapide consomme les crédits à un rythme plus élevé sur les modèles pris en charge, et la génération d’images épuise les limites incluses 3-5x plus vite que des tours comparables uniquement textuels.¹¹⁹

Les forfaits Enterprise et Edu adaptent les crédits à l’allocation contractuelle. Consultez /status dans le TUI pour connaître l’utilisation actuelle.

Facturation API

Lorsque vous utilisez Codex via l’API, OpenAI facture l’utilisation par token selon la tarification OpenAI API standard du modèle sélectionné (ainsi que les remises applicables pour la mise en cache des prompts). Consultez la page officielle de tarification API pour connaître les tarifs actuels.²⁰

Stratégies d’optimisation des coûts

1. Utilisez des profils : créez un profil fast avec gpt-5.6-luna et model_reasoning_effort = "low" pour les tâches courantes
2. Réservez le raisonnement élevé : n’utilisez xhigh que pour des problèmes réellement difficiles, car il coûte 3-5x plus de tokens
3. Utilisez --ephemeral : ignorez la persistance de session dans CI/CD pour réduire la surcharge
4. Réduisez les résumés de raisonnement : définissez model_reasoning_summary = "none" lorsque vous n’avez pas besoin d’explications
5. Traitez par lots avec le mode exec : codex exec évite la surcharge du TUI pour les flux d’automatisation
6. Surveillez l’utilisation : consultez /status dans le TUI et les tableaux de bord de facturation de votre organisation

Exemples de coûts réels

Coûts API représentatifs pour des tâches courantes (instantané des tarifs gpt-5.3-codex de mi-2026, raisonnement moyen — les proportions relatives se retrouvent d’un modèle à l’autre) :

Les coûts varient selon l’effort de raisonnement, la mise en cache et la longueur de la conversation. Utilisez gpt-5.6-luna pour les tâches courantes afin de réduire sensiblement ces dépenses. Les tokens d’entrée mis en cache sont facturés avec une remise.

Surcharge cachée de tokens

Chaque appel d’outil ajoute des tokens au-delà de votre prompt visible :

Conseil d’expert : Surveillez votre utilisation réelle via /status dans le TUI. Le nombre de tokens inclut toute la surcharge, pas seulement vos messages visibles. Si les coûts vous surprennent, vérifiez combien de serveurs MCP sont connectés — chacun ajoute des définitions d’outils à chaque appel API.

Gestion des coûts d’équipe

Stratégies de maîtrise des coûts d’équipe :

• Définissez requirements.toml pour appliquer des limites de modèle et d’effort de raisonnement dans toute l’organisation
• Utilisez gpt-5.6-luna pour CI/CD — les pipelines automatisés ont rarement besoin du raisonnement maximal
• Budgétisation basée sur les profils — définissez des profils ci, review et dev avec des plafonds de coûts adaptés
• Surveillez via OpenTelemetry — les déploiements Enterprise peuvent exporter les données de télémétrie d’utilisation vers les piles d’observabilité existantes

Cadres de décision

Quand utiliser chaque interface

Quand utiliser chaque mode sandbox

Quand utiliser chaque niveau de raisonnement

Mode Planification vs exécution directe

Will Codex need to change more than 3 files?
│
├── YES → Use Plan Mode (/plan)
│         Codex designs the approach BEFORE making changes.
│         You review and approve the plan.
│         Best for: refactors, new features, migrations
│
└── NO → Is the change well-defined?
         │
         ├── YES → Direct execution
         │         Just describe the task. Codex executes immediately.
         │         Best for: bug fixes, small features, test additions
         │
         └── NO → Use Plan Mode (/plan)
                  Let Codex explore and propose an approach first.
                  Best for: unfamiliar codebases, ambiguous requirements

Mode Steer : Enter vs Tab

Règle générale : Enter = « arrêtez-vous, écoutez ceci maintenant. » Tab = « quand vous aurez terminé, faites aussi ceci. »

Desktop App vs CLI

How do you prefer to work?
│
├── Terminal-first → Use CLI
│   │
│   ├── Single focused task → codex (interactive TUI)
│   ├── Scripted automation → codex exec (non-interactive)
│   └── Quick one-shot → codex exec "prompt" -o result.txt
│
└── Visual/multi-project → Use Desktop App
    │
    ├── Multiple parallel tasks → Multi-thread with worktree isolation
    ├── Visual diff review → Built-in Git diff viewer
    ├── Scheduled automation → Automations tab
    └── Voice-driven → Ctrl+M for voice dictation

Quel profil ?

Associez votre tâche à un profil préconfiguré :

Configuration config.toml :

# Default profile
profile = "default"

[profiles.fast]
model = "gpt-5.6-luna"
model_reasoning_effort = "low"

[profiles.careful]
model = "gpt-5.5"
model_reasoning_effort = "xhigh"

[profiles.pair]
model = "gpt-5.3-codex-spark"
model_reasoning_effort = "high"

[profiles.ci]
model = "gpt-5.6-luna"
model_reasoning_effort = "low"
sandbox_mode = "workspace-write"

Changez de profil par session : codex --profile careful

Comment fonctionnent le sandbox et le système d’approbation ?

Codex utilise un modèle de sécurité à deux niveaux qui distingue ce qui est techniquement possible de quand Codex demande une approbation humaine. Cette approche diffère fondamentalement du système d’autorisations de Claude Code : Codex applique les restrictions au niveau du noyau du système d’exploitation.⁵ Consultez également la section Déploiement en entreprise pour connaître les contraintes définies dans requirements.toml que les administrateurs appliquent à l’ensemble de l’organisation.

Niveau 1 : sandbox (ce qui est possible)

Le sandbox contrôle l’accès au système de fichiers et au réseau à l’aide de mécanismes natifs du système d’exploitation :

Application selon la plateforme :

• macOS : framework Seatbelt d’Apple via sandbox-exec, avec des profils propres à chaque mode, compilés lors de l’exécution et appliqués par le noyau⁶. Depuis la v0.121.0, les profils de sandbox macOS peuvent placer sur liste d’autorisation des sockets Unix précis (par exemple, docker.sock et les sockets IPC des éditeurs), et la résolution DNS privée n’est plus bloquée par défaut.⁸²
• Linux : Landlock pour les restrictions du système de fichiers et seccomp pour le filtrage des appels système. Un processus auxiliaire autonome (codex-linux-sandbox) assure une isolation renforcée.⁵ Bubblewrap (bwrap) est intégré aux sources et compilé avec la version Linux (il n’est plus facultatif depuis la v0.100.0)⁷. La v0.117.0 a amélioré la fiabilité du sandbox sur les distributions anciennes dotées de configurations de noyau héritées.⁷⁵ La v0.129.0 a renforcé le démarrage du sandbox sous Linux et mis à niveau la version intégrée de Bubblewrap vers la 0.11.2, avec les correctifs de sécurité du projet d’origine ; la v0.130.0 a encore renforcé le démarrage.⁸⁹⁹¹
• Windows : sandbox natif utilisant des jetons restreints (sorti du statut expérimental dans la v0.100.0). WSL est également pris en charge et hérite de Landlock et seccomp sous Linux. La v0.117.0 améliore le sandbox à jetons restreints afin de mieux isoler les processus.⁷⁵ La v0.130.0 accorde aux utilisateurs du sandbox l’accès au cache des binaires d’exécution de l’application de bureau, afin que le sandbox Windows puisse trouver ces binaires de manière fiable pour les utilisateurs du sandbox de l’espace de travail.⁹¹

Pourquoi est-ce important ? Contrairement au sandbox reposant sur des conteneurs (Docker), celui qui opère au niveau du système d’exploitation est plus rapide, plus léger et plus difficile à contourner. Le noyau applique les restrictions avant même que Codex ne voie l’appel système.

Correctifs de sécurité : - Contournement du sandbox par zsh-fork (v0.106.0) : correction d’une vulnérabilité qui permettait à l’exécution de commandes shell via la création de processus zsh de contourner les restrictions du sandbox.⁶⁰ Si vous utilisez une version antérieure, effectuez immédiatement la mise à niveau. - Limite de taille des entrées (v0.106.0) : Codex impose désormais une limite d’environ 1 million de caractères aux entrées afin d’éviter les blocages provoqués par des charges utiles excessivement volumineuses.⁶⁰ - Profil devcontainer sécurisé (v0.121.0) : un nouveau profil client renforcé pour les devcontainers Docker utilise Bubblewrap afin d’assurer le sandbox à l’intérieur du conteneur. WSL2 est pris en charge ; WSL1 est explicitement refusé (Bubblewrap est incompatible avec la couche de compatibilité du noyau de WSL1).⁸² - Examen Guardian et hooks (v0.121.0) : les hooks sont désactivés pendant les sessions d’examen Guardian, afin que les hooks exécutés avant ou après les outils ne puissent pas interférer avec les décisions du sous-agent Guardian.⁸² Si vous utilisez des hooks pour la journalisation ou la validation, sachez qu’un examen Guardian ne les exécute pas : appuyez-vous sur l’observabilité de l’app-server si vous avez besoin d’une piste d’audit complète. - Système de fichiers /dev sous Linux (v0.105.0) : les commandes exécutées dans le sandbox sous Linux disposent désormais d’un système de fichiers /dev minimal, ce qui améliore la compatibilité avec les outils qui s’attendent à trouver des nœuds de périphérique.⁶¹

Politique ReadOnlyAccess (v0.100.0+) : une structure de politique configurable permettant un contrôle précis des accès en lecture. Utilisez-la pour limiter les dossiers que Codex peut lire, même en mode workspace-write :

[sandbox_workspace_write]
read_only_access = ["/etc", "/usr/local/share"]  # Only these paths readable outside workspace

Niveau 2 : politique d’approbation (quand demander)

La politique d’approbation détermine quand Codex s’interrompt pour demander une confirmation humaine :

on-failure figure encore dans certains anciens exemples et chemins de compatibilité, mais la documentation actuelle d’OpenAI sur la configuration le signale comme obsolète. Préférez on-request pour les exécutions interactives et never pour les exécutions non interactives qui disposent déjà d’un périmètre de sécurité externe.⁸⁷

Identifiants d’approbation distincts (v0.104.0+)

Codex attribue désormais un identifiant d’approbation distinct à chaque commande d’une exécution shell en plusieurs étapes. Les approbations sont donc précises : approuver une commande d’une séquence n’approuve pas automatiquement les suivantes au sein de la même invocation du shell.⁴⁹

Contrôles d’approbation flexibles (v0.105.0+)

Le processus d’approbation prend désormais en charge des autorisations de sandbox supplémentaires et le refus granulaire :⁶¹

• Autorisations de sandbox supplémentaires : lorsqu’une commande requiert un accès dépassant le mode de sandbox actuel, Codex peut demander des autorisations supplémentaires précises au lieu d’exiger un changement complet de mode
• Refus granulaire : refusez individuellement des appels d’outils en fournissant un retour, afin que Codex puisse adapter son approche au lieu de simplement tenter à nouveau la même commande

Demandes d’autorisations lors de l’exécution (v0.113.0+)

Codex comprend désormais un outil request_permissions intégré qui permet au modèle de demander des autorisations supplémentaires lors de l’exécution.⁶⁹ Lorsque le modèle rencontre une tâche nécessitant un accès élevé, il peut demander formellement des autorisations précises (chemins du système de fichiers, accès réseau, etc.) au moyen du processus d’approbation de la TUI, au lieu d’échouer silencieusement ou d’obliger l’utilisateur à redémarrer avec d’autres options.

Mode d’approbation des applications writes (v0.144.0+)

Les applications et connecteurs disposent d’un niveau d’approbation intermédiaire : le mode d’approbation des applications writes permet d’exécuter sans confirmation les actions déclarées en lecture seule d’une application, tout en marquant une pause pour toute opération d’écriture.¹⁰⁷ Auparavant, les approbations d’applications relevaient davantage du tout ou rien ; writes correspond au niveau de confiance réellement recherché par la plupart des opérateurs pour leurs intégrations : consulter librement, demander avant de modifier.

Approbations examinées automatiquement : --approve-for-me (v0.147.0+)

La nouvelle option CLI --approve-for-me transforme les demandes d’approbation en approbations examinées automatiquement : au lieu de vous interrompre, chaque demande est évaluée par un processus d’examen qui l’approuve ou la refuse en votre nom.¹¹⁶ Ce mode se situe entre « tout approuver » (l’approche qu’encourageait --full-auto, désormais supprimé) et « interrompre pour chaque action » : les demandes restent des points de décision, mais un examinateur y répond. Associez-le aux paramètres par défaut plus sûrs d’examen automatique introduits dans la v0.146.1 pour les modèles dotés de capacités cyber, dont cette option hérite. Traitez-le comme toute délégation d’autorité : adapté aux longues exécutions sans surveillance pour lesquelles une interruption provoquerait un blocage, mais inadapté aux sessions touchant des identifiants ou l’état de production, lorsque vous souhaitez rester l’examinateur.

Profils d’autorisations (v0.113.0+, étendus dans les v0.128.0 et v0.133.0)

Les profils d’autorisations répartissent les politiques de sandbox du système de fichiers et du réseau dans des sections nommées et réutilisables. Définissez default_permissions sur un profil intégré tel que :read-only ou :workspace, ou faites-le pointer vers une table personnalisée [permissions.<name>].⁸⁷ La v0.133.0 fait des profils une surface administrée : les listes d’APIs exposent les métadonnées des profils disponibles, les profils peuvent hériter les uns des autres, le fichier requirements.toml administré peut déclarer des exigences d’autorisation, les profils actifs s’actualisent lors de l’exécution, et la configuration du sandbox Windows utilise désormais le profil résolu plutôt qu’une politique ponctuelle distincte.⁹⁸

default_permissions = "project-safe"

[permissions.project-safe.filesystem]
"/usr/local" = "read"
glob_scan_max_depth = 3

[permissions.project-safe.filesystem.":project_roots"]
"." = "write"
"**/*.env" = "none"

[permissions.project-safe.network]
enabled = true
mode = "limited"

[permissions.project-safe.network.domains]
"api.github.com" = "allow"
"registry.npmjs.org" = "allow"

Utilisez none pour les fichiers sensibles et les motifs glob qui doivent rester illisibles même lorsque la racine du projet est accessible en écriture. Pour les exceptions ponctuelles concernant une commande, préférez des règles à un élargissement général du profil.⁸⁷

Anciennes recommandations relatives à --full-auto

Les anciens guides présentaient --full-auto comme un alias pratique pour :

codex --sandbox workspace-write --ask-for-approval on-request

Dans la v0.128.0, les notes de version indiquent que --full-auto est obsolète, et l’aide actuelle de CLI ne le répertorie plus pour les exécutions interactives. Utilisez plutôt les options explicites ci-dessus ou un profil d’autorisations nommé.⁸⁶

La v0.147.0 achève sa suppression : codex exec --full-auto n’existe plus. Un script qui transmet encore cette option génère désormais une erreur au lieu de s’exécuter. La migration est mécanique : remplacez-la par --sandbox workspace-write (ainsi que par une option d’approbation ou un profil si votre ancienne invocation dépendait du comportement d’approbation de --full-auto). Avant la mise à niveau, auditez toutes les automatisations qui invoquent codex exec par l’intermédiaire d’un shell : l’échec se manifeste par un pipeline interrompu, et non par un avertissement d’obsolescence.¹¹⁶

Fiabilité du sandbox (v0.129.0) : le renforcement du démarrage du sandbox Linux réduit les conditions de concurrence sur les systèmes de fichiers lents ou les extractions utilisant des liens symboliques ; les améliorations apportées à la fiabilité du sandbox Windows corrigent plusieurs plantages dans des cas limites au cours des longues exécutions ; enfin, la version intégrée de Bubblewrap passe à la 0.11.2 et inclut les correctifs de sécurité du projet d’origine. Aucune modification de configuration n’est nécessaire. Exécutez codex update pour en bénéficier.⁸⁹

Configurations recommandées

Développement quotidien (choix sûr par défaut) :

sandbox_mode = "workspace-write"
approval_policy = "on-request"

Utilisateur expérimenté (accès complet, avec intervention humaine) :

sandbox_mode = "danger-full-access"
approval_policy = "untrusted"

Cette combinaison constitue le « juste équilibre » recommandé par la communauté : des capacités maximales, mais une approbation requise pour chaque commande.⁸

Automatisation CI/CD :

sandbox_mode = "workspace-write"
approval_policy = "never"

Approbations intelligentes avec le sous-agent Guardian (v0.115.0+)

Les approbations intelligentes peuvent transmettre les demandes d’examen à un sous-agent Guardian au lieu d’exiger une approbation humaine pour chaque action. La session Guardian persiste d’une approbation à l’autre afin de réutiliser le cache du prompt et d’éviter le coût du démarrage. Chaque examen bénéficie d’un historique vierge, de sorte que les décisions antérieures n’influencent pas les suivantes.⁷³

Configurez l’examinateur dans config.toml :

approvals_reviewer = "guardian_subagent"   # "user" (default) or "guardian_subagent"

Cette approche est particulièrement utile pour les workflows CI/CD dans lesquels vous souhaitez un examen automatisé assorti d’un raisonnement, plutôt qu’une politique générale approval_policy = "never".

Renforcement du classificateur PowerShell (v0.142.2) : les commandes PowerShell contenant des régions exécutables de l’AST que le classificateur de sécurité ne peut pas inspecter nécessitent désormais une approbation, au lieu de passer indûment par l’approbation automatique. Ce changement comble une lacune qui permettait à du code PowerShell obscurci ou construit dynamiquement d’échapper à la classification sous Windows.¹⁰⁵

Extension de la détection des commandes dangereuses (v0.144.5) : la détection reconnaît désormais davantage de variantes forcées de rm, et les commandes refusées sont accompagnées de motifs de refus plus clairs au lieu d’un rejet opaque, ce qui s’avère utile lorsque vous ajustez les politiques d’approbation et devez comprendre pourquoi une commande a été bloquée.¹¹⁰

Activation de l’accès réseau

Codex bloque par défaut l’accès réseau en mode workspace-write. Activez-le si nécessaire :

# Per-run
codex -c 'sandbox_workspace_write.network_access=true' "install the packages"

# In config.toml
[sandbox_workspace_write]
network_access = true
writable_roots = ["/path/to/extra/dir"]   # Additional writable directories
exclude_slash_tmp = false                  # Prevent /tmp from being writable
exclude_tmpdir_env_var = false             # Prevent $TMPDIR from being writable

Prise en charge des proxys WebSocket (v0.104.0+)

Dans les environnements d’entreprise qui acheminent le trafic WebSocket par un proxy, Codex prend désormais en charge les variables d’environnement WS_PROXY et WSS_PROXY :⁴⁹

export WSS_PROXY="https://proxy.corp.example.com:8443"
codex "update the README"

Elles complètent la prise en charge existante des proxys HTTPS_PROXY et SOCKS5 (v0.93.0+).

La v0.146.0 est la version qui a véritablement étendu cette prise en charge à « toutes les couches de transport ». Les proxys configurés sont désormais utilisés pour l’authentification, le téléchargement des plugins, l’autorisation MCP, l’exécution distante, les connexions WebSocket, les redirections HTTP et les connexions à LM Studio, soit sept chemins qui, d’après le journal des modifications, ignoraient auparavant le proxy.¹¹⁴ Si vous exécutiez Codex derrière un proxy d’entreprise avant la v0.146.0 et constatiez que les connexions ou les installations de plugins échouaient alors que les appels ordinaires au modèle fonctionnaient, cette lacune en est probablement la cause.

Proxy système sous macOS (v0.142.2+) : lorsque respect_system_proxy est activé, les clients d’authentification macOS respectent les paramètres système de proxy, PAC et WPAD. Les Mac d’entreprise dont la configuration de proxy est distribuée par des profils n’ont donc plus besoin de variables d’environnement de proxy propres à chaque shell pour le trafic d’authentification.¹⁰⁵ Depuis la v0.143.0, cette prise en charge s’étend à Windows et au trafic Responses API : Codex achemine les appels d’authentification et les appels Responses API par le proxy système de macOS ou Windows, y compris avec l’autoconfiguration PAC et WPAD, ce qui comble la dernière lacune pour les réseaux d’entreprise verrouillés sur ces deux systèmes d’exploitation.¹⁰⁶

Test du sandbox

Vérifiez le comportement du sandbox avant de lui faire confiance :

codex sandbox macos --permissions-profile :workspace -- ls /etc/passwd   # macOS test
codex sandbox linux --permissions-profile :workspace -- cat /etc/shadow  # Linux test

Si le sandbox fonctionne correctement, les deux commandes doivent échouer avec une erreur d’autorisation refusée sous un profil limité à l’espace de travail. Si l’une des commandes réussit, vous devez examiner la configuration de votre sandbox.

Comment fonctionne AGENTS.md ?

AGENTS.md est le système d’instructions de projet de Codex — un standard ouvert⁹ désormais régi par l’Agentic AI Foundation de la Linux Foundation. Il est pris en charge par Codex, Cursor, Copilot, Amp, Jules (Google), Gemini CLI, Windsurf, Cline, Aider, Zed, Factory, RooCode et plus de 60 000 projets open source. Il définit le comportement de Codex au sein d’un dépôt ou d’un répertoire donné. Consultez la section Skills pour découvrir les ensembles d’expertise réutilisables qui complètent AGENTS.md.

Hiérarchie de découverte

Au démarrage de la session, Codex construit une chaîne d’instructions en parcourant l’arborescence des répertoires :

1. Global (~/.codex/) : AGENTS.override.md > AGENTS.md
2. Projet (de la racine git au répertoire courant) : à chaque niveau, Codex recherche AGENTS.override.md > AGENTS.md > les noms de fichiers de secours
3. Fusion : les fichiers sont concaténés de la racine vers le bas ; les fichiers les plus proches apparaissent plus tard dans le prompt et prévalent sur les instructions précédentes

~/.codex/AGENTS.md                     ← Global defaults
  └─ /repo/AGENTS.md                   ← Project-wide rules
      └─ /repo/services/AGENTS.md      ← Service-specific rules
          └─ /repo/services/payments/
               AGENTS.override.md      ← Overrides everything above for this dir

Projets Desktop comportant plusieurs dossiers (26.715, 23 juillet 2026) : Le parcours décrit ci-dessus correspond à CLI, qui résout tout par rapport au répertoire de travail courant. L’application ChatGPT pour ordinateur permet désormais à un projet local de couvrir plusieurs dossiers associés, mais elle effectue la découverte par rapport à un seul d’entre eux : « Les nouvelles conversations, les opérations Git et la découverte automatique de AGENTS.md, des skills et de config.toml utilisent le dossier principal. Les dossiers secondaires restent disponibles pour la recherche, la lecture et la modification de fichiers. » Vous choisissez le dossier principal dans le menu du projet via Modifier le projet.¹¹³

Ce réglage unique régit simultanément trois des cinq systèmes fondamentaux de Codex : les instructions, les skills et la configuration suivent tous le dossier principal. En pratique : un fichier AGENTS.md situé dans un dossier secondaire est un fichier que Codex peut ouvrir, et non un contrat opérationnel qu’il charge. Si le dépôt contenant vos règles est celui que vous avez joint en second, définissez-le comme dossier principal ou reprenez ces règles dans le fichier AGENTS.md du dossier principal ; il en va de même pour les dossiers de skills du dépôt dont vous attendiez la détection. Le parcours des répertoires de CLI n’a pas changé : il s’agit du périmètre des projets dans l’application pour ordinateur.

Les qualités d’un excellent AGENTS.md

D’après les recommandations directes de Codex et les pratiques de la communauté¹⁰ :

À FAIRE : - Soyez précis : "Use rg --files for discovery" est préférable à "search efficiently" - Définissez les critères d’achèvement : que signifie « terminé » ? (tests réussis, lint sans erreur, etc.) - Indiquez les commandes : build, test, lint et formatage (avec les invocations exactes) - Organisez les instructions par tâche : sections consacrées au développement, à la revue, à la publication et aux incidents/débogage - Définissez la procédure d’escalade : précisez la marche à suivre en cas de blocage ou de situation inattendue

À NE PAS FAIRE : - Insérer des guides de style entiers sans règles d’exécution - Employer des directives ambiguës (« soyez prudent », « optimisez ») - Mélanger des priorités contradictoires (rapidité + vérification exhaustive + aucun budget d’exécution) - Rédiger une documentation narrative (AGENTS.md est une politique opérationnelle, pas un README)

Exemple : AGENTS.md de production

# Repository Guidelines

## Build, Test, and Development Commands
- Run API (dev): `python3 -m uvicorn main:app --reload`
- Install deps: `pip install -r requirements.txt`
- Lint: `python3 -m ruff check .` (auto-fix: `--fix`)
- Format: `python3 -m ruff format .`
- Tests: `python3 -m pytest -v`
- Coverage: `python3 -m pytest --cov=app --cov-report=term-missing`

## Coding Style & Naming Conventions
- Python 3.11+. Type hints on all functions.
- Ruff enforced: 88-char lines, double quotes, spaces for indent.
- Naming: modules `snake_case.py`, classes `PascalCase`, functions `snake_case`.

## Commit & Pull Request Guidelines
- Conventional Commits: `feat:`, `fix:`, `docs:`, `refactor:`, `chore:`, `test:`
- Commits should be small and focused.
- PRs must include: description, test plan, and screenshots for UI changes.

## Security
- Never commit secrets. Use `.env` for local config.
- Validate all external API calls with proper error handling.

Gestion des secrets dans les sessions de l’agent

Considérez l’historique visible par Codex comme une surface de sécurité, au même titre que le code source. Les notes de version de Codex documentent les travaux consacrés aux instantanés du shell et à la suppression des variables d’environnement, tandis que le système de mémoire analyse les écritures en mémoire à la recherche de secrets. Ces protections ne rendent toutefois pas les sorties de commandes, les transcriptions de sessions, les instantanés du shell, les journaux locaux ou les scripts utilitaires suffisamment sûrs pour y afficher des identifiants.³⁷⁵⁵⁹⁵

La règle opérationnelle est simple : n’affichez pas de secrets que le modèle pourrait examiner ; conservez les identifiants des outils auxiliaires dans la configuration requise par l’environnement ; lors des audits, séparez le code source exécutable, la documentation, les caches générés, les transcriptions de sessions, les instantanés du shell, les journaux et les espaces délibérément réservés aux secrets ; expurgez l’historique local lorsqu’une forme correspondant avec une forte probabilité à un secret apparaît ; et ne déployez des hooks de prévention qu’après avoir validé la procédure manuelle d’hygiène. L’enseignement public porte sur la cartographie des surfaces et les critères d’acceptation, et non sur les valeurs privées des jetons, les chemins exacts ou le fonctionnement interne des détecteurs.⁹⁵

Le mécanisme de remplacement

À chaque niveau de répertoire, AGENTS.override.md remplace le fichier AGENTS.md normal pour le périmètre concerné. Utilisez-le pour :

• Gel des versions : « Aucune nouvelle fonctionnalité, uniquement des correctifs »
• Mode incident : « Toutes les modifications doivent être examinées par la personne d’astreinte »
• Renforcement temporaire : « Aucune mise à jour des dépendances pendant ce sprint »

Configuration

# Custom fallback filenames (in addition to AGENTS.md)
project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"]

# Increase max size for large instruction files
project_doc_max_bytes = 65536    # 64 KiB (default: 32 KiB)

Génération d’une structure initiale

codex                           # Launch TUI
/init                           # Generate AGENTS.md scaffold

Ou vérifiez votre chaîne d’instructions :

codex --ask-for-approval never "Summarize your current instructions"

Hooks

Codex a introduit les hooks dans la v0.99.0 (AfterAgent) et la v0.100.0 (AfterToolUse), puis ajouté dans la v0.114.0 un moteur de hooks expérimental comprenant les événements SessionStart et Stop.⁷⁰ Depuis la v0.124.0 (23 avril 2026), les hooks sont stables.⁸⁵ Ils peuvent désormais être configurés directement dans config.toml et requirements.toml — aucun fichier de scripts de hooks distinct n’est plus nécessaire — et ils observent les outils MCP ainsi que apply_patch et les sessions Bash de longue durée. Le système couvre maintenant le cycle de vie des sessions et l’automatisation au niveau des outils, comblant ainsi l’écart avec le modèle de hooks de Claude Code.

Événements de hook disponibles

Configuration des hooks

Les hooks sont configurés dans .codex/config.toml :

[[hooks]]
event = "AfterToolUse"
command = "echo 'Tool completed' >> /tmp/codex-log.txt"

[[hooks]]
event = "SessionStart"
command = "echo 'Current date: $(date +%Y-%m-%d)'"

La sortie standard du hook SessionStart alimente le contexte du modèle, ce qui le rend idéal pour injecter des informations dynamiques (dates, noms de branches, variables d’environnement) au démarrage de la session.

Reproduire les modèles de hooks de Claude Code

Si vous migrez depuis Claude Code, voici comment obtenir une automatisation similaire :

Conseil d’expert : Depuis la v0.124.0 (23 avril 2026), le moteur de hooks est stable. De nouveaux événements de hook continuent d’être ajoutés au fil des versions : consultez le journal des modifications de Codex.

Navigateur de hooks intégré à la TUI (v0.129.0) : Exécutez /hooks dans la TUI pour découvrir les hooks disponibles, voir ceux qui sont actuellement actifs et activer ou désactiver individuellement les hooks sans modifier config.toml. Cette fonctionnalité est utile pour diagnostiquer un hook défectueux fourni avec un plugin ou désactiver temporairement un linter AfterToolUse pendant une session de modification exigeant toute votre concentration.⁸⁹

Qu’est-ce que MCP (Model Context Protocol) ? [EXPERIMENTAL]

MCP étend les capacités de Codex en le connectant à des outils et services externes. Le groupe de commandes codex mcp est actuellement marqué comme expérimental, et les commandes ainsi que le format de configuration peuvent changer d’une version à l’autre. Codex prend en charge deux types de transport : STDIO (processus locaux) et Streamable HTTP (serveurs distants).¹¹

Modifications de MCP dans la v0.121.0 : Les outils sont désormais enregistrés avec un espace de noms, de sorte que les noms d’outils dans les listes apparaissent sous la forme <server>:<tool> plutôt que comme des noms seuls — mettez à jour les scripts ou prompts qui utilisent grep sur des noms d’outils non qualifiés. Un nouveau flag supports_parallel_tool_calls est transmis aux MCPs inclus, ce qui permet l’exécution parallèle pour les serveurs qui déclarent cette prise en charge. Les métadonnées d’état du sandbox sont désormais transmises via les métadonnées des outils MCP, afin que les serveurs puissent adapter leur comportement (par exemple, avertir s’ils s’exécutent dans un sandbox en lecture seule). La requête personnalisée codex/sandbox-state a été supprimée — utilisez plutôt le chemin des métadonnées. La phase 3 du déploiement des Apps MCP arrive ici avec la prise en charge des appels d’outils ; les appels d’outils différés aplatis sont désormais pris en charge pour les serveurs utilisant le modèle d’appel différé.⁸²

Modifications de MCP dans la v0.142.2 (25 juin 2026) : Les outils MCP utilisent désormais la recherche d’outils par défaut lorsqu’elle est prise en charge — au lieu de charger chaque définition d’outil dès le départ, Codex découvre les outils à la demande, améliorant leur découverte dans les configurations riches en outils tout en restant compatible avec les anciens modèles et fournisseurs. Les serveurs MCP stdio distants acceptent également des répertoires de travail absolus écrits au format de chemin de la plateforme distante (un chemin de style Windows depuis un client macOS, ou inversement).¹⁰⁵

Modifications de MCP dans la v0.147.0 (7 août 2026) : Codex ajoute une prise en charge facultative de la révision 2026-07-28 du protocole MCP — découverte paginée (les grands catalogues d’outils sont transmis par pages au lieu d’une seule liste surdimensionnée), requêtes à plusieurs tours (un serveur peut conserver un échange en plusieurs étapes au sein d’une requête logique) et démarrage de serveur non bloquant, avec des outils MCP mis en cache exposés avant la fin du démarrage du serveur afin qu’un serveur lent ne bloque plus le lancement de la session. Cette prise en charge est facultative ; les serveurs utilisant l’ancienne révision continuent de fonctionner sans modification.¹¹⁶

Configurer des serveurs MCP

Serveurs STDIO (processus locaux) :

# In ~/.codex/config.toml or .codex/config.toml

[mcp_servers.context7]
enabled = true
required = true                         # Fail startup if unavailable
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env = { "MY_VAR" = "value" }            # Static env vars
env_vars = ["PATH", "HOME"]             # Forward host env vars
cwd = "/path/to/project"                # Optional working directory
startup_timeout_sec = 10
tool_timeout_sec = 60
enabled_tools = ["search", "summarize"]  # Tool allowlist
disabled_tools = ["slow-tool"]           # Tool denylist

Serveurs HTTP (distants) :

[mcp_servers.figma]
enabled = true
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
http_headers = { "X-Figma-Region" = "us-east-1" }
env_http_headers = { "X-Org-Id" = "FIGMA_ORG_ID" }  # Headers from env vars
startup_timeout_sec = 10
tool_timeout_sec = 60

Gestion de CLI

codex mcp add context7 -- npx -y @upstash/context7-mcp
codex mcp add context7 --env API_KEY=... -- npx -y @upstash/context7-mcp   # With env vars
codex mcp add figma --url https://mcp.figma.com/mcp --bearer-token-env-var FIGMA_OAUTH_TOKEN
codex mcp list                          # List all configured servers
codex mcp list --json                   # JSON output
codex mcp get context7                  # Show server config
codex mcp get context7 --json           # JSON output
codex mcp login <server>                # OAuth flow for HTTP servers
codex mcp logout <server>               # Remove OAuth credentials
codex mcp remove <server>               # Delete server definition

En session : /mcp affiche les serveurs actifs et les outils disponibles. /mcp verbose (v0.123.0+)⁸⁴ renvoie les diagnostics complets du serveur, les ressources et les modèles de ressources — utile lorsqu’un serveur ne parvient pas à se charger ou que les outils n’apparaissent pas à l’endroit attendu. La commande /mcp seule reste rapide. Depuis la v0.144.0, les outils MCP peuvent demander une authentification de manière interactive sans activation expérimentale — un serveur qui nécessite une authentification en cours de session invite l’utilisateur via le flux normal, au lieu d’échouer tant que vous ne vous êtes pas préalablement authentifié avec codex mcp login.¹⁰⁷

Le chargement de MCP par plugin (v0.123.0+) accepte à la fois le schéma standard mcpServers et les mappages de serveurs de premier niveau dans .mcp.json, afin que les plugins créés selon l’une ou l’autre convention se chargent correctement.⁸⁴

Exécuter Codex EN TANT QUE serveur MCP

Codex peut s’exposer comme serveur MCP pour l’orchestration multi-agents :¹²

codex mcp-server                        # Start as MCP server (stdio transport)

Le serveur expose deux outils : 1. codex() : démarre une nouvelle session avec des paramètres de prompt, de sandbox, de modèle et d’approbation 2. codex-reply() : poursuit une session existante avec threadId et un prompt

Utilisation avec le SDK des Agents (Python) :

from agents import Agent, Runner
from agents.mcp import MCPServerStdio

async with MCPServerStdio(
    name="Codex CLI",
    params={"command": "npx", "args": ["-y", "codex", "mcp-server"]},
    client_session_timeout_seconds=360000,
) as codex_mcp_server:
    agent = Agent(name="Developer", mcp_servers=[codex_mcp_server])
    result = await Runner.run(agent, "Fix the failing tests")

Serveurs MCP notables

Modèles pratiques

Modèle 1 : développement sensible au contexte — Associez Context7 à la documentation de votre framework afin que Codex dispose toujours de références API à jour :

[mcp_servers.context7]
enabled = true
required = true
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

Modèle 2 : limites de sortie — Les réponses des outils MCP sont tronquées à environ 25 000 caractères par défaut. Pour les outils qui renvoient des charges utiles importantes (requêtes de base de données, captures de journaux), utilisez enabled_tools pour vous limiter à des outils spécifiques et conserver des réponses ciblées.

Modèle 2a : sortie d’outil multimodale (v0.107.0) — Les outils personnalisés peuvent désormais renvoyer une sortie multimodale (images, contenu enrichi) en plus du texte. Cela permet aux outils qui produisent des artefacts visuels — captures d’écran, diagrammes, rendus de graphiques — de les transmettre directement au modèle pour analyse.⁶²

Modèle 3 : gouvernance MCP en entreprise — Limitez les serveurs MCP que les développeurs peuvent utiliser via requirements.toml :

# In /etc/codex/requirements.toml — only approved servers allowed
[mcp_servers.approved-internal]
identity = { command = "npx @company/internal-mcp" }

Tout serveur ne correspondant pas à une identité dans requirements.toml sera bloqué au démarrage. Consultez Déploiement en entreprise pour la configuration complète des politiques.

Mode Code [EXPERIMENTAL]

Le mode Code (v0.114.0) fournit des flux de travail de programmation plus isolés en limitant le périmètre de l’agent aux opérations centrées sur le code.⁷⁰ Lorsqu’il est activé, l’agent se concentre sur la lecture, l’écriture et le test de code sans interactions plus larges avec le système.

Depuis la v0.139.0, le mode Code peut appeler directement une recherche web autonome — y compris depuis des appels d’outils JavaScript imbriqués — et reçoit des résultats en texte brut, de sorte qu’un flux en mode Code peut récupérer des informations en temps réel sans quitter le contexte de programmation isolé.¹²² La v0.146.0 étend la recherche web autonome aux fournisseurs de modèles personnalisés compatibles, de sorte que cette capacité n’est plus limitée aux modèles hébergés par OpenAI.¹¹⁴

La v0.146.0 permet à app-server de se connecter à des hôtes Code Mode distants via WebSocket, de sorte que le runtime du mode Code ne doit plus se trouver sur la même machine que le client.¹¹⁴

Cette fonctionnalité est expérimentale. Consultez les notes de version pour les mises à jour.

Runtime REPL JavaScript [SUPPRIMÉ]

Codex v0.100.0 a ajouté un runtime REPL JavaScript expérimental (js_repl) et la v0.106.0 l’a promu via l’interface /experimental.⁶⁰ Ces indications sont désormais historiques. Dans la v0.128.0, le journal des modifications de version inclut « Remove js_repl feature », et la liste actuelle des fonctionnalités indique que js_repl et js_repl_tools_only ont été supprimés.⁸⁶

N’ajoutez pas features.js_repl = true aux nouvelles configurations. Utilisez des commandes shell, des scripts versionnés, des outils MCP ou une skill Codex avec un dossier scripts/ lorsque vous avez besoin d’une logique exécutable reproductible.

Que sont les skills ?

Les skills sont des ensembles réutilisables de fonctionnalités propres à une tâche, que Codex charge à la demande. Ils respectent le standard ouvert agent skills.¹³

Structure d’un skill

my-skill/
  SKILL.md           (required: instructions)
  scripts/           (optional: executable scripts)
  references/        (optional: reference docs)
  assets/            (optional: images, icons)
  agents/openai.yaml (optional: metadata, UI, dependencies)

Emplacements de découverte

Codex stocke les skills installés par l’utilisateur dans $CODEX_HOME/skills (par défaut : ~/.codex/skills), y compris les skills système intégrés sous .system/. Codex prend en charge les dossiers de skills liés symboliquement.

Créer un skill

Format de SKILL.md :

---
name: security-audit
description: Run a thorough security audit on the codebase.
---

## Security Audit Procedure

1. Scan for hardcoded secrets using `rg -i "(api_key|password|secret|token)\s*=" --type py`
2. Check for SQL injection: look for string interpolation in queries
3. Verify input validation on all API endpoints
4. Check dependency vulnerabilities: `pip audit` or `npm audit`
5. Review authentication and authorization patterns
6. Report findings with severity levels (Critical/High/Medium/Low)

Métadonnées (agents/openai.yaml) :

interface:
  display_name: "Security Audit"
  short_description: "Full codebase security review"
  icon_small: "./assets/shield.svg"
  brand_color: "#DC2626"
  default_prompt: "Run a security audit on this repository"

policy:
  allow_implicit_invocation: false    # Require explicit $skill

dependencies:
  tools:
    - type: "mcp"
      value: "snyk"
      transport: "streamable_http"
      url: "https://mcp.snyk.io/mcp"

Invoquer des skills

• Explicitement : menu /skills ou mention de $skill-name dans le prompt
• Implicitement : Codex détecte automatiquement les skills correspondant à la description de la tâche (si allow_implicit_invocation: true)
• Créateur : utilisez $skill-creator pour créer un nouveau skill de manière interactive
• Programme d’installation : utilisez $skill-installer install <name> pour installer des skills communautaires
• Fourni par l’exécuteur (v0.146.0) : Codex découvre les skills proposés par l’exécuteur et lit les ressources qui leur sont associées, y compris les skills que vous sélectionnez explicitement¹¹⁴

Les budgets de contexte tronquent les catalogues de skills. La v0.146.0 conserve davantage de skills disponibles lorsque le contexte est limité et vous avertit lorsqu’un catalogue doit être tronqué.¹¹⁴ Auparavant, une vaste bibliothèque de skills pouvait être réduite silencieusement : un skill que vous pensiez disponible dans le contexte pouvait donc tout simplement ne pas être proposé. Si vous comptez sur l’invocation implicite parmi de nombreux skills, soyez attentif à cet avertissement.

Activer ou désactiver

[[skills.config]]
path = "/path/to/skill/SKILL.md"
enabled = false

Skills et slash commands

Dépanner les skills

Si un skill ne s’active pas :

1. Vérifiez sa découverte : /skills doit le répertorier dans la TUI
2. Vérifiez son chemin : assurez-vous que le dossier du skill se trouve dans un emplacement reconnu (~/.codex/skills/, racine du projet ou /etc/codex/skills/)
3. Vérifiez enabled : les skills définis avec enabled = false dans config.toml ne sont pas chargés
4. Vérifiez l’activation implicite : si vous comptez sur la détection automatique, assurez-vous que allow_implicit_invocation: true figure dans agents/openai.yaml
5. Utilisez des mots-clés : incluez dans votre prompt les termes de la description du skill pour améliorer la correspondance implicite

Exemple en production : skill de déploiement

Un skill complet composé de plusieurs fichiers, montrant comment les références et les scripts fonctionnent ensemble :

deploy-skill/
  SKILL.md
  references/
    runbook.md
    rollback-checklist.md
  scripts/
    pre-deploy-check.sh
    smoke-test.sh
  agents/openai.yaml

SKILL.md :

---
name: deploy
description: Deploy the application to staging or production. Runs pre-flight checks, executes deployment, and verifies with smoke tests.
---

## Deployment Procedure

### Pre-flight
1. Run `scripts/pre-deploy-check.sh` to verify:
   - All tests pass
   - No uncommitted changes
   - Branch is up to date with remote
2. Review the runbook at `references/runbook.md` for environment-specific steps.

### Deploy
3. Execute the deployment command for the target environment.
4. Monitor logs for errors during rollout.

### Verify
5. Run `scripts/smoke-test.sh <environment-url>` to confirm critical paths.
6. If smoke tests fail, follow `references/rollback-checklist.md`.

Invoquez-le avec : $deploy to staging ou $deploy production with canary rollout

Plugins

Les plugins regroupent les skills, les entrées MCP, les hooks et les connecteurs d’applications dans un seul package installable (v0.110.0+).⁶⁵ Depuis v0.117.0, les plugins sont des éléments de premier plan : les plugins associés au produit se synchronisent automatiquement au démarrage et /plugins fournit un navigateur intégré à la TUI pour la découverte et la gestion.⁷⁵ v0.128.0 a étendu les workflows de plugins avec l’installation depuis une marketplace, la mise en cache de bundles distants, les APIs de désinstallation à distance, les hooks fournis avec les plugins, l’état d’activation des hooks et l’import de configuration d’agents externes.⁸⁶ v0.129.0 (7 mai 2026) ajoute le partage de plugins dans l’espace de travail (envoyez un ensemble de plugins à vos coéquipiers sans les republier), des contrôles d’accès au partage (activation/désactivation par destinataire, révocation), le filtrage des sources (limitez les marketplaces dont un espace de travail extrait les plugins), ainsi que des opérations de marketplace directement accessibles depuis le navigateur /plugins plutôt que depuis la CLI.⁸⁹ v0.133.0 (21 mai 2026) rend la découverte de plugins plus facile à auditer : la sortie de liste tient compte de la marketplace, les versions installées sont visibles, les racines des marketplaces sont répertoriées et les collections de plugins distants peuvent être affichées sans devoir deviner de quel registre provient un résultat.⁹⁸ v0.130.0 (8 mai 2026) rend le packaging des plugins plus transparent et le workflow de partage plus contrôlable :⁹¹

• Les hooks fournis sont visibles dans les détails du plugin. La vue détaillée de /plugins répertorie désormais chaque hook de cycle de vie fourni par un plugin (SessionStart, UserPromptSubmit, Stop, etc.). Avant d’installer un plugin, vous pouvez voir exactement quels hooks il enregistrera pour votre session — fini les effets secondaires surprenants de hooks provenant d’un plugin auquel vous faites confiance uniquement pour ses outils.
• Métadonnées de partage de plugin dans shareContext. Lorsqu’un plugin est partagé depuis un espace de travail, la charge utile du lien de partage expose désormais les métadonnées du lien (créateur, portée, fraîcheur) afin que les sessions réceptrices puissent afficher sa provenance et décider de l’accepter ou non.
• Contrôles de découvrabilité dans les paramètres de partage. Les paramètres de partage proposent une bascule de découvrabilité afin que les équipes puissent publier des plugins dans des espaces de travail ou pour des listes de destinataires précis sans les rendre généralement répertoriables dans l’ensemble de l’organisation.

v0.143.0 (8 juillet 2026) active les plugins distants par défaut. Les plugins distants sont désormais activés sans indicateur d’opt-in, le catalogue /plugins propose des lignes plus riches (sources de marketplace npm aux côtés de git et local), et chaque entrée affiche à la fois sa version distante et sa version installée localement afin que les écarts soient visibles d’un coup d’œil.¹⁰⁶ Pour une équipe qui standardise un ensemble partagé de plugins, l’activation des plugins distants par défaut supprime l’étape d’activation par machine qui freinait auparavant le déploiement.

Sources de plugins

Depuis v0.147.0, la recherche de plugins couvre les catalogues locaux, personnels, d’espace de travail et distants dans une seule requête — vous recherchez une capacité, et non le catalogue qui la contient. Associé aux packages portables Agent Plugin, un plugin créé dans un environnement s’installe proprement dans un autre au lieu d’être lié à la machine ou à l’espace de travail où il a été rédigé.¹¹⁶

Découverte de plugins

Codex indique au modèle quels plugins sont activés au démarrage de la session (v0.111.0), ce qui améliore la découverte des MCPs, applications et skills installés.⁶⁵ Le modèle peut suggérer des plugins pertinents pendant une session en fonction du contexte de la tâche. Dans v0.117.0, les plugins associés au produit sont synchronisés au démarrage, ce qui garantit que le catalogue de plugins le plus récent est disponible sans intervention manuelle.⁷⁵ Depuis v0.142.0, le menu /plugins organise les plugins distants en sections OpenAI Curated, Workspace et Shared with me, et les tours éligibles peuvent recommander et installer des plugins pertinents directement.¹⁰⁴

Mentions @plugin (v0.112.0+)

Faites directement référence à n’importe quel plugin installé dans le chat avec @plugin-name.⁶⁸ Lorsque vous mentionnez un plugin, son contexte (capacités, outils, configuration) est automatiquement inclus dans la fenêtre de contexte du modèle — inutile de décrire ce que fait le plugin.

@deploy push this branch to staging with canary rollout
@linter check for unused imports in src/

Cela fonctionne avec tout plugin installé, y compris les skills personnalisés, les serveurs MCP et les connecteurs d’applications.

Marketplace de plugins (v0.113.0+)

La marketplace de plugins propose désormais une découverte plus riche grâce aux métadonnées, aux catégories et aux évaluations.⁶⁹ Les vérifications d’authentification à l’installation confirment que les plugins nécessitant des clés API ou OAuth disposent d’identifiants valides avant l’installation. Un point de terminaison de désinstallation supprime proprement les plugins et leur configuration associée.

Ajout de marketplaces tierces (v0.121.0+)

La documentation actuelle d’OpenAI Codex conserve la gestion des sources de marketplace sous codex plugin marketplace. Cela formalise la distribution de plugins tiers au-delà de la marketplace propriétaire d’OpenAI et prend en charge la syntaxe abrégée des dépôts GitHub, les URL Git HTTP(S), les URL SSH et les répertoires racines de marketplaces locales ; utilisez --ref pour épingler une référence Git et répétez --sparse PATH uniquement pour les dépôts de marketplace basés sur Git.⁹³

# GitHub repository (shorthand)
codex plugin marketplace add owner/repo

# Arbitrary git URL
codex plugin marketplace add https://git.example.com/team/plugins.git

# SSH Git URL
codex plugin marketplace add git@example.com:team/plugins.git

# Local directory
codex plugin marketplace add /path/to/local/marketplace

# Upgrade or remove a configured marketplace
codex plugin marketplace upgrade <marketplace-name>
codex plugin marketplace remove <marketplace-name>

Une fois ajoutés, les plugins d’une marketplace apparaissent dans le navigateur /plugins aux côtés de ceux par défaut. Les appelants du serveur d’applications (intégrations IDE/desktop) disposent d’un point de terminaison parallèle pour enregistrer les marketplaces par programmation.⁸²

Considération de sécurité : Les marketplaces tierces exécutent du code de plugin arbitraire avec vos autorisations Codex. Vérifiez les sources avant de les ajouter et privilégiez une exécution sandboxée lors des premières utilisations.

Agent Plugins : le standard inter-fournisseurs (v0.146.0–v0.147.0)

« Agent Plugins » n’est pas seulement le nom d’une fonctionnalité Codex — il s’agit d’un standard de packaging ouvert et indépendant des fournisseurs, publié sous le nom de Agent Plugins 1.0.0 le 6 août 2026, dont le site officiel le résume ainsi : « A portable package format for reusable components that extend AI agents. »¹¹⁸ Un plugin est un répertoire avec un manifeste plugin.json requis (un schéma fermé comportant exactement dix champs de premier niveau autorisés — $schema, name, version, description, author, homepage, repository, license, keywords, extensions — où « Clients MUST report and ignore each unknown field »), un dossier skills/ facultatif (chaque répertoire enfant immédiat contenant un SKILL.md constitue un skill), un mcp.json facultatif déclarant des serveurs stdio, Streamable HTTP ou l’ancien HTTP+SSE, ainsi que des répertoires facultatifs d’espace de noms client en domaine inversé que les autres clients « MUST ignore ». Sa portée normative est le packaging : la spécification « defines the canonical Agent Plugins Specification v1.0.0 for packaging reusable components that extend AI agents into distributable plugins » — les Agent Skills et MCP conservent leurs propres spécifications sous-jacentes.¹¹⁸

La gouvernance est l’élément déterminant. Vercel a initié la proposition et développé la spécification 1.0 avec Amazon, Anysphere (Cursor), GitHub, Microsoft et OpenAI ; la liste des mainteneurs du dépôt de la spécification couvre Amazon, Cursor, Microsoft, OpenAI et Vercel, et Google a annoncé le jour du lancement rejoindre les mainteneurs principaux.¹¹⁸ Les clients de lancement nommés couvrent ChatGPT, Codex, Cursor, GitHub Copilot, Kiro et VS Code. Une absence notable : Anthropic, qui a créé le format Agent Skills sous-jacent et MCP lui-même, ne fait pas partie des mainteneurs — Claude Code conserve son propre format de plugin, et Codex comble l’écart de son côté avec la source de marketplace Claude Code (v0.146.0) et /import.¹¹⁸

En termes de Codex : v0.146.0 ajoute les manifestes Agent Plugins, la publication de plugins d’espace de travail et deux marketplaces de plugins supplémentaires — Amazon Bedrock et Claude Code¹¹⁴ — et v0.147.0 boucle la boucle avec l’installation de plugins Agent Plugins portables et la recherche dans les catalogues locaux, personnels, d’espace de travail et distants.¹¹⁶ La publication dans l’espace de travail est la moitié opérationnellement utile pour les équipes : publiez des plugins dans votre propre espace de travail au lieu de mettre en place une marketplace publique ou de demander à chaque développeur d’ajouter manuellement une source Git.

Les notes de version annoncent les surfaces Codex sans publier leurs clés de configuration ni la syntaxe de la CLI. Cette entrée indique que la capacité est arrivée et ce que le standard spécifie, et non comment l’utiliser depuis Codex — considérez le workflow de création de manifeste et toute invocation de codex plugin publish comme non vérifiés tant que la documentation d’OpenAI ne les couvre pas.

Gestion des plugins

codex plugin marketplace add <src>       # Add a marketplace source
codex plugin marketplace upgrade [name]  # Upgrade one marketplace or all
codex plugin marketplace remove <name>   # Remove a configured marketplace

Dans la TUI, utilisez /plugins (v0.117.0+) pour parcourir, installer et supprimer des plugins individuellement de manière interactive sans quitter votre session.⁷⁵

Conseil d’expert : Les plugins regroupent ce qui nécessitait auparavant une configuration MCP distincte, l’installation de skills et la configuration de connecteurs d’applications. Un seul plugin peut réunir les trois — ce qui accélère l’intégration des équipes et rend la configuration plus portable.

Mode Plan et collaboration

Le mode Plan permet à Codex de concevoir une approche avant d’exécuter des modifications. Il est activé par défaut (depuis la v0.94.0).¹⁴ Consultez les cadres de décision pour l’arbre de décision « Mode Plan ou exécution directe ».

Activation du mode Plan

/plan                              # Switch to plan mode
/plan "redesign the API layer"     # Plan mode with initial prompt

En mode Plan, Codex : - Lit les fichiers et analyse la base de code - Propose un plan d’implémentation - N’apporte aucune modification sans votre approbation - Affiche progressivement le plan dans une vue TUI dédiée

Mode Steer

Le mode Steer (activé par défaut depuis la v0.98.0) vous permet d’ajouter de nouvelles instructions pendant que Codex travaille activement, sans interrompre sa tâche en cours.¹⁴

Il existe deux méthodes d’injection :

Exemples pratiques :

# Codex is refactoring the auth module...

[Enter] "Use bcrypt instead of argon2 — we already have it as a dependency"
→ Codex adjusts immediately, mid-turn

[Tab] "Once auth is done, update the migration script too"
→ Codex finishes auth refactor, then starts the migration

Le mode Steer est toujours actif dans la TUI. Si vous préférez attendre que Codex ait terminé avant de lui donner des instructions, saisissez-les simplement normalement une fois le tour achevé — aucun mode spécial n’est nécessaire.

Améliorations de la TUI (v0.105.0–v0.106.0)

Coloration syntaxique (v0.105.0) : la TUI applique désormais une coloration syntaxique aux blocs de code délimités et aux diffs affichés directement dans le contenu. Utilisez /theme pour choisir une palette de couleurs.⁶¹

Nouvelles commandes TUI (v0.105.0+) :⁶¹

Transcription vocale (v0.105.0, expérimentale) : appuyez sur la barre d’espace pour dicter vos prompts par transcription vocale. Cette fonctionnalité est expérimentale et peut nécessiter une autorisation d’accès au microphone.⁶¹ Depuis la v0.107.0, les sessions vocales en temps réel permettent de sélectionner les périphériques d’entrée et de sortie audio, afin que vous puissiez choisir un équipement audio précis.⁶² Supprimée dans la v0.140.0, rétablie dans la v0.145.0 : les commandes vocales expérimentales /realtime et leurs dépendances audio ont été retirées de la TUI dans la v0.140.0 (la transcription vocale avec la barre d’espace n’était pas concernée).¹⁰² La v0.145.0 réintroduit la voix sous une nouvelle forme : des entrées audio et des sorties d’outils audio dans les formats audio locaux courants, ainsi que des conversations V3 en temps réel et en streaming.¹¹²

Autres améliorations : - Les liens longs restent désormais cliquables même lorsqu’ils s’étendent sur plusieurs lignes de la TUI (v0.105.0)⁶¹ - Les liens vers des fichiers locaux bénéficient d’un meilleur formatage (v0.106.0)⁶⁰ - Le markdown de la TUI maintient les liens web cliquables grâce aux métadonnées OSC 8, et les tableaux trop à l’étroit sont remplacés par des enregistrements clé/valeur lisibles sans perdre les cibles des liens (v0.136.0)[^180] - La gestion de Ctrl+C pour les sous-agents a été corrigée afin de terminer correctement les processus enfants (v0.106.0)⁶⁰

Système de mémoire

Codex dispose d’un système de mémoire persistante (v0.100.0+) qui conserve les faits, les préférences et le contexte du projet entre les sessions.²⁴

Commandes de mémoire

Les souvenirs sont stockés dans des fichiers markdown sous ~/.codex/memory/. Codex les charge au début de la session et s’en sert pour adapter son comportement dans toutes les sessions ultérieures.

Éléments à mémoriser

La mémoire convient particulièrement aux préférences durables et aux informations propres au projet :

• Conventions du projet : « Ce projet utilise des tabulations, pas des espaces » ou « Les réponses de API comprennent toujours un champ meta »
• Préférences relatives aux outils : « Utilisez pnpm au lieu de npm » ou « Exécutez les tests avec pytest -x --tb=short »
• Décisions d’architecture : « Le module d’authentification se trouve dans src/core/auth/, pas dans src/middleware/ »
• Préférences de workflow : « Exécutez toujours le linter avant de m’afficher un diff »

Mémoire dans les pipelines

Lorsque vous exécutez codex exec, les souvenirs sont chargés automatiquement. Les pipelines CI/CD et les scripts bénéficient donc du même contexte que les sessions interactives — inutile de répéter les instructions à chaque invocation.

Améliorations de la mémoire (v0.101.0–v0.107.0)

• Nettoyage des secrets : les souvenirs font automatiquement l’objet d’une recherche de secrets avant leur écriture sur le disque
• Prise en compte du CWD : les fichiers de mémoire incluent désormais le contexte du répertoire de travail pour faciliter le rappel d’informations propres au projet
• Exclusion des messages destinés aux développeurs : les messages développeur/système sont exclus des données d’entrée de la phase 1 de la mémoire, ce qui améliore sa qualité en la concentrant sur les interactions avec l’utilisateur
• Oubli fondé sur les diffs (v0.106.0) : la mémoire utilise désormais les diffs pour supprimer les faits obsolètes, ce qui permet de conserver un ensemble de souvenirs concis et pertinent au fil du temps⁶⁰
• Sélection tenant compte de l’utilisation (v0.106.0) : la récupération des souvenirs tient désormais compte de leur utilisation et privilégie ceux qui sont fréquemment consultés ou pertinents depuis peu⁶⁰
• Mémoire configurable (v0.107.0) : la mémoire est désormais entièrement configurable. Utilisez codex debug clear-memories pour réinitialiser tous les souvenirs enregistrés et repartir de zéro — utile lorsque vous passez d’un projet à un autre sans rapport ou lorsque l’état de la mémoire s’est écarté du contexte actuel⁶²
• Mise à niveau du modèle de phase 2 (v0.121.0) : le modèle de consolidation de la mémoire de phase 2 est désormais gpt-5.4 (contre le modèle précédent utilisé par défaut). Le pipeline de phase 2 s’exécute entre les sessions pour condenser les transcriptions de phase 1 en faits durables ; ce changement de modèle améliore la qualité du rappel à coût en tokens identique.⁸²
• Menu de mémoire dans la TUI (v0.121.0) : une nouvelle interface intégrée à la session donne accès au mode de mémoire, à la suppression individuelle des souvenirs et à un bouton de réinitialisation. La réinitialisation de la mémoire préserve désormais les rollouts antérieurs au lieu de les invalider : elle efface ainsi les futurs éléments rappelés sans compromettre la relecture de la session.⁸²

Mémoire ou AGENTS.md

Conseil : utilisez /m_update pour les faits qui doivent être conservés indéfiniment. Pour le contexte propre à une session, indiquez-le simplement à Codex dans la conversation. Pour un contexte partagé avec l’équipe, utilisez AGENTS.md.

Gestion des sessions

Codex conserve les sessions dans ~/.codex/sessions/, ce qui permet de les reprendre, de les dupliquer et d’organiser des flux de travail multi-threads entre CLI et les interfaces de bureau.

v0.146.0 rend les threads adressables. /new et /clear acceptent désormais un nom de session, les threads importants peuvent être épinglés et les conversations annexes restent ouvertes, sans vous obliger à en fermer une pour en atteindre une autre.¹¹⁴ Concrètement, un projet de longue durée cesse d’être une liste d’horodatages que vous devez reconnaître par date. v0.147.0 ajoute des sections de conversation : les conversations s’organisent en sections persistantes ordonnées manuellement, et les longues transcriptions se parcourent progressivement au lieu d’être chargées dans leur intégralité.¹¹⁶

Reprendre

Reprenez là où vous vous étiez arrêté :

codex resume                          # Interactive picker (sorted by recency)
codex resume <SESSION_ID>             # Resume a specific session
codex exec resume --last "continue"   # Non-interactive: resume most recent

La commande slash /resume dans le TUI ouvre le même sélecteur interactif avec recherche.

Historique de threads paginé (v0.145.0) [EXPERIMENTAL] : Un historique expérimental de threads paginé permet une reprise efficace, la recherche dans l’historique, des noms de threads persistants, la prise en charge des sub-agents et les mémoires dans la gestion des sessions — l’historique se charge page par page plutôt que d’un seul coup, ce qui compte pour les répertoires de travail de longue durée comptant des centaines de sessions. Fonctionnalité expérimentale : attendez-vous à ce que cette interface évolue d’une version à l’autre.¹¹²

Dupliquer

Créez une branche d’une conversation pour explorer des alternatives sans perdre votre progression actuelle :

/fork                              # Fork current conversation
/fork "try a different approach"   # Fork with new prompt

Les duplications créent des threads indépendants partageant le même historique jusqu’au point de duplication. Depuis v0.146.0, l’historique des duplications est paginé, et les duplications peuvent être créées comme temporaires — une duplication temporaire n’apparaît pas dans les listes de threads, ce qui évite d’encombrer de tests éphémères la liste de threads que vous parcourez réellement.¹¹⁴ Les modifications apportées dans une duplication n’affectent pas l’autre. Cela permet de comparer des approches (par exemple, « dupliquez et essayez Redis au lieu de Memcached ») ou d’explorer des modifications risquées en toute sécurité.

Duplication de threads en sub-agents (v0.107.0) : Les threads peuvent désormais être dupliqués en sub-agents indépendants, ce qui permet à une conversation de générer des flux de travail parallèles s’exécutant de manière autonome. Cela étend le modèle de duplication existant — au lieu de simplement créer une branche de la conversation, le thread dupliqué devient un sub-agent avec son propre contexte d’exécution.⁶² Depuis v0.117.0, les sub-agents utilisent des adresses basées sur des chemins (par exemple, /root/agent_a) avec une messagerie inter-agents structurée, ce qui rend la coordination multi-agent plus explicite et plus facile à déboguer.⁷⁵

Messages inter-agents chiffrés (v0.138.0+) : Multi-agent v2 chiffre désormais le texte de tâche qu’un agent parent envoie lorsqu’il génère un sub-agent ou lui adresse un message. Les paramètres de message de spawn_agent, send_message et followup_task sont marqués comme chiffrés : les Responses API chiffrent la charge utile lorsque le modèle parent émet l’appel d’outil, Codex exécuté localement ne transporte que le texte chiffré (InterAgentCommunication.encrypted_content, avec un contenu en texte clair vide), et les API le déchiffrent côté serveur lorsqu’ils le transmettent au modèle destinataire.¹⁰⁸ Trois conséquences pratiques :

• Vos journaux de session locaux ne contiennent plus le texte clair des délégations. Vous pouvez voir qu’un parent a généré un sub-agent et ce qui est revenu, mais pas l’instruction exacte qu’il lui a envoyée. Si vous auditez ou déboguez des exécutions multi-agent depuis l’historique des sessions, cet enregistrement a disparu ; l’issue de régression ouverte qui suit ce problème n’avait aucun correctif associé à la mi-juillet 2026.¹⁰⁹ Les événements du cycle de vie des extensions (démarrage/arrêt de sub-agent, exécution d’outil, métadonnées de tour — v0.133.0+) et l’observabilité de l’app-server restent les points d’accroche pour reconstituer ce qui s’est passé.⁹⁸
• Les modèles de fournisseurs personnalisés peuvent ne plus fonctionner. Un endpoint de modèle non configuré pour l’utilisation d’outils chiffrés rejette le schéma spawn_agent chiffré avec une erreur 400 ("declares encrypted parameters but is not configured for encrypted tool use"). Si la délégation multi-agent échoue avec cette erreur chez un fournisseur personnalisé, elle provient du changement de chiffrement, pas de votre configuration.¹⁰⁹
• Les notifications générées par Codex restent lisibles. Les notifications de fin des agents enfants sont produites par Codex lui-même ; elles restent donc en texte clair et s’affichent désormais comme des éléments agent_message typés plutôt que comme des enveloppes JSON sérialisées.¹⁰⁸

OpenAI n’a pas publié le modèle de menace qui sous-tend cette modification ; la PR décrit le flux de texte chiffré sans préciser contre quoi il protège.

Multi-agent v2 stabilisé (v0.145.0, opt-in) : L’expérience multi-agent v2, apparue dans v0.137.0 et enrichie de la délégation chiffrée dans v0.138.0, est désormais stabilisée comme fonctionnalité opt-in. v0.145.0 ajoute des modèles de sub-agent configurables, des niveaux de raisonnement par sub-agent, une concurrence configurable, le rétablissement des rôles multi-agent et une navigation améliorée entre les agents. Si vous avez différé l’adoption de v2 pendant les ajustements des versions v0.137/v0.138, c’est la version où la surface de configuration se stabilise — les choix de modèle et de raisonnement des sub-agents se trouvent désormais dans la configuration plutôt que d’être imposés par le runtime.¹¹²

Liste des threads

Affichez et gérez les sessions actives :

/status                            # Current session info and token usage
/ps                                # Show background terminals in session

Dans l’application de bureau, les threads sont visibles dans la barre latérale, avec l’historique complet et des aperçus des différences.

Cycle de vie des sessions

Les sessions se synchronisent entre CLI et l’application de bureau — commencez dans l’une et poursuivez dans l’autre.

Mode non interactif (codex exec)

codex exec exécute Codex de manière non interactive pour les scripts, la CI/CD et l’automatisation.¹⁵

Utilisation de base

codex exec "summarize the repository structure"
codex exec --sandbox workspace-write --ask-for-approval on-request "fix the CI failure"
codex exec --json "triage open bugs" -o result.txt

Par défaut, codex exec écrit la progression et les événements dans stderr, et le message final de l’agent dans stdout. Cette conception permet de l’intégrer aux pipelines Unix standard.

Archivage des sessions (v0.136.0)

Les sessions peuvent être archivées afin de ne conserver que les éléments pertinents dans la liste de reprise ou de fork, sans supprimer l’historique. Archivez-les depuis la TUI avec /archive, ou depuis le shell :[^180]

codex archive <session-id>     # archive a session
codex unarchive <session-id>   # restore it

Une session archivée ne peut faire l’objet d’aucune opération de reprise ou de fork tant que vous ne la désarchivez pas — une protection contre la reprise accidentelle d’une session que vous souhaitiez abandonner. Dans la même version, codex app-server --stdio lance l’app-server en mode stdio pour les intégrations avec des éditeurs ou des hôtes, et /diff ne peut désormais plus exécuter les assistants Git fournis par le dépôt (un correctif de sécurité des commandes). Sous Windows, un parcours de provisionnement en version alpha ajoute codex sandbox setup --elevated pour les administrateurs.[^180]

Sortie en lignes JSON

Avec --json, stdout devient un flux d’événements JSONL :

codex exec --json "fix the tests" | jq

Types d’événements : thread.started, turn.started/completed/failed, item.started/completed, error

{"type":"thread.started","thread_id":"019c5c94-..."}
{"type":"turn.started"}
{"type":"item.started","item":{"id":"item_1","type":"command_execution","status":"in_progress"}}
{"type":"item.completed","item":{"id":"item_3","type":"agent_message","text":"..."}}
{"type":"turn.completed","usage":{"input_tokens":24763,"cached_input_tokens":24448,"output_tokens":122}}

Sortie structurée

Imposez la structure de la réponse avec un schéma JSON :

codex exec "Extract project metadata" \
  --output-schema ./schema.json \
  -o ./project-metadata.json

-o / --output-last-message écrit le message final dans un fichier.

Reprise et examen d’une session

codex exec resume --last "continue where you left off"
codex exec resume <SESSION_ID> "fix the remaining issues"
codex exec review --base main           # Code review against a branch

Principaux flags

Authentification en CI

codex exec prend en charge CODEX_API_KEY pour l’authentification non interactive dans les environnements d’automatisation.

Bannière de démarrage de codex exec (v0.130.0). La bannière de démarrage de codex exec n’affiche plus l’ancienne mention « research preview ». Si votre CI analyse la sortie au démarrage, le texte de la bannière est désormais plus concis ; les événements structurés de --json restent inchangés.⁹¹

codex remote-control (v0.130.0+)

codex remote-control est une commande de premier niveau qui démarre un app-server headless conçu pour être piloté par un autre processus — extensions d’IDE, orchestrateurs personnalisés ou plans de contrôle distants. Elle remplace l’invocation de codex app-server comportant plusieurs flags que de nombreux intégrateurs assemblaient manuellement, et offre aux outils tiers un point d’entrée unique et stable vers le même environnement d’exécution app-server que celui livré avec les interfaces de bureau et d’IDE.⁹¹ La v0.133.0 améliore le mode d’exécution de la commande : elle peut fonctionner comme une commande au premier plan, attendre que le service soit prêt, signaler l’état de la machine et proposer malgré tout des commandes explicites start / stop de type daemon pour les configurations de contrôleur de longue durée.⁹⁸ La v0.143.0 ajoute codex remote-control pair, qui génère un code d’appairage manuel à partir d’un daemon en cours d’exécution afin qu’un contrôleur puisse se connecter sans passer par la détection automatique — utile lorsque le processus de contrôle se trouve sur un autre hôte ou segment réseau que le daemon.¹⁰⁶

# Start a headless, remotely controllable app-server
codex remote-control

# Generate a manual pairing code for an out-of-band controller (v0.143.0+)
codex remote-control pair

# Same lifecycle as a TUI session: thread store, hooks, plugins, MCP, sandbox
# all initialize from your normal config.toml.

Associez codex remote-control aux APIs de pagination de l’app-server ci-dessous lorsque vous créez des interfaces utilisateur qui doivent parcourir de longs historiques de threads sans charger simultanément chaque tour en mémoire.

Pagination des threads de l’app-server (v0.130.0+)

Les clients de l’app-server peuvent désormais parcourir les longs threads page par page grâce à trois vues distinctes des éléments de tour :⁹¹

Associez la pagination à l’interface ThreadStore introduite dans la v0.121.0 pour parcourir efficacement les threads de longue durée, en particulier dans les déploiements remote-control où l’orchestrateur peut se trouver sur une autre machine que les fichiers de rollout.⁸² La v0.143.0 étend les possibilités d’inspection d’un contrôleur : les clients de l’app-server peuvent désormais énumérer les environnements disponibles, répertorier les threads descendants d’un thread et créer un fork de l’historique à partir d’un tour précis — les primitives dont une interface utilisateur a besoin pour créer une branche d’une exécution depuis un point antérieur sans devoir la rejouer jusqu’à ce point.¹⁰⁶

Actualisation à chaud de la configuration de l’app-server (v0.130.0+)

Les threads actifs de l’app-server prennent désormais en compte les modifications de config.toml sans redémarrage : modifiez la configuration, enregistrez-la, et le thread en cours appliquera les nouvelles valeurs dès son prochain tour. Ce correctif complète codex remote-control : un serveur headless de longue durée peut être reconfiguré sur place sans devoir être arrêté.⁹¹

Exécuteurs distants chiffrés (v0.141.0)

Depuis la v0.141.0 (stable, 18 juin 2026), les exécuteurs distants se connectent par des canaux de relais Noise authentifiés et chiffrés de bout en bout — le plan de contrôle et l’exécuteur n’ont plus besoin de faire confiance au relais qui les relie, ce qui est essentiel lorsque votre orchestrateur pilote un app-server au-delà d’une frontière réseau. Cette même version permet à l’exécution distante multiplateforme de préserver le dossier de travail et le shell natifs de l’exécuteur : lorsqu’un contrôleur exécuté sur un système d’exploitation pilote un exécuteur sur un autre, les chemins et la sémantique du shell ne sont plus réécrits à son insu. TLS accepte également désormais les signatures de certificat P-521 pour assurer la compatibilité avec les proxys d’entreprise.¹⁰³

Codex Cloud et tâches en arrière-plan [EXPERIMENTAL]

Statut : Codex Cloud est une fonctionnalité expérimentale. Les interfaces, les tarifs et la disponibilité peuvent évoluer. OpenAI gère les environnements cloud, et vous ne contrôlez pas l’infrastructure.

Codex Cloud exécute les tâches de manière asynchrone dans des environnements gérés par OpenAI.⁴ Consultez également Action GitHub et CI/CD pour intégrer Codex à votre pipeline de CI.

Fonctionnement

1. Envoyez une tâche (via chatgpt.com/codex, l’intégration Slack ou CLI)
2. Codex clone votre dépôt dans un sandbox cloud isolé
3. L’agent travaille de manière autonome : il lit le code, exécute les tests et apporte des modifications
4. Une fois le travail terminé, Codex crée une PR ou fournit un diff à examiner
5. Appliquez les résultats localement avec codex apply <TASK_ID>

Accès à Internet dans le cloud

L’accès de l’agent à Internet est désactivé par défaut et se configure séparément pour chaque environnement :

• Désactivé : aucun accès de l’agent à Internet (par défaut)
• Activé : liste facultative de domaines autorisés et restrictions des méthodes HTTP

Allowed domains: pypi.org, npmjs.com, github.com
Allowed methods: GET, HEAD, OPTIONS

Les scripts de configuration peuvent toujours utiliser Internet pour installer des dépendances, même lorsque l’accès de l’agent à Internet est désactivé.

Intégration Slack

Mentionnez @Codex dans un canal ou un thread Slack pour lancer une tâche cloud.

Prérequis : 1. Un abonnement ChatGPT éligible (Plus, Pro, Business, Enterprise ou Edu) 2. Un compte GitHub connecté 3. Au moins un environnement cloud configuré 4. L’application Slack installée dans votre workspace

Codex répond avec un lien vers la tâche et publie les résultats une fois celle-ci terminée.

CLI cloud

codex cloud exec --env <ENV_ID> "Fix failing tests"  # Start a cloud task
codex cloud status <TASK_ID>                          # Check task progress
codex cloud diff <TASK_ID>                            # View task diff
codex cloud list                                      # List recent tasks
codex cloud list --json                               # JSON output
codex cloud apply <TASK_ID>                           # Apply from cloud subcommand
codex apply <TASK_ID>                                 # Apply diff (top-level shortcut)

L’application de bureau Codex

L’application de bureau Codex (macOS et Windows) offre une interface graphique optimisée pour la gestion de plusieurs projets.¹⁶ La version Windows a été lancée le 4 mars 2026 avec une prise en charge native de PowerShell et une sandbox Windows native.⁶⁶

Installation

codex app                      # Auto-downloads and installs on first run

Ou téléchargez-la directement : Codex.dmg (macOS) | Disponible dans le Microsoft Store (Windows)

Fonctionnalités principales

Appshots, commentaires dans le navigateur et Computer Use

Les mises à jour de l’application du 21 mai font de l’application de bureau une interface contextuelle plus complète, et non plus un simple gestionnaire de threads. Utilisez Appshots lorsque Codex doit connaître l’état d’une autre application Mac avant de pouvoir agir : Codex capture la fenêtre au premier plan et le texte visible ou hors écran mis à disposition par l’application, puis stocke la pièce jointe localement dans l’historique de la session.⁹⁹

Pour le développement web et frontend, commencez par utiliser le navigateur intégré si la page ne nécessite pas d’authentification : Codex et vous disposez ainsi d’un aperçu partagé du rendu. Ce navigateur prend en charge des actions comme les clics, les captures d’écran, le téléchargement de ressources et l’inspection en lecture seule JavaScript. Il vous permet également de signaler des zones de la page avec des commentaires que Codex pourra traiter au tour suivant.⁹⁹ Pour les sites nécessitant une connexion, continuez à utiliser l’extension Chrome.

N’utilisez Computer Use que lorsqu’une intégration structurée ou un aperçu dans le navigateur ne permet pas de vérifier la tâche. Cette fonctionnalité peut inspecter et utiliser les applications Mac autorisées, mais les approbations et les règles de sandbox de Codex continuent de s’appliquer aux modifications de fichiers et aux commandes shell. L’utilisation verrouillée reste strictement limitée : après le verrouillage du Mac, Codex peut accéder temporairement aux applications autorisées pendant les tours Computer Use actifs et approuvés, avec des mesures de reverrouillage et une détection des entrées locales.⁹⁹

Modes de thread

Chaque thread s’exécute dans l’un des trois modes suivants, sélectionné lors de sa création :

Mécanismes d’isolation des worktrees :

Lorsque vous démarrez un thread Worktree, l’application de bureau : 1. Crée un nouveau git worktree (git worktree add) dans un répertoire temporaire 2. Extrait une nouvelle branche à partir de votre HEAD actuel 3. Exécute l’agent dans le worktree — toutes les modifications de fichiers sont isolées 4. Présente les diffs à examiner une fois la tâche terminée — vous choisissez les modifications à réintégrer

Plusieurs threads Worktree peuvent ainsi s’exécuter simultanément sur le même dépôt sans conflit. Chacun dispose de sa propre branche et de son propre répertoire de travail.

Automatisations

Les automatisations s’exécutent localement dans l’application. Celle-ci doit donc être ouverte et le projet disponible sur le disque :

• Dans les dépôts Git, les automatisations utilisent des worktrees dédiés en arrière-plan, isolés de votre répertoire de travail
• Dans les projets sans Git, les exécutions ont lieu directement dans le répertoire du projet
• Les automatisations utilisent vos paramètres de sandbox par défaut

Configuration d’une automatisation : 1. Ouvrez un projet dans l’application de bureau 2. Cliquez sur l’onglet Automations dans la barre latérale 3. Définissez un déclencheur (planification, webhook ou déclenchement manuel) 4. Rédigez le prompt et sélectionnez le mode d’exécution (local ou worktree) 5. Définissez le niveau de raisonnement de l’exécution automatisée (App v26.312)⁷² 6. Les automatisations s’exécutent selon la planification et placent les résultats dans une file d’attente pour examen

Exemples de cas d’usage : - Triage des issues : classez automatiquement les nouvelles issues par catégorie et par priorité - Surveillance de la CI : surveillez les échecs de build et suggérez des correctifs - Réponse aux alertes : réagissez aux alertes de surveillance en réalisant une analyse diagnostique - Mises à jour des dépendances : recherchez et appliquez les correctifs de sécurité

Les résultats apparaissent dans une file d’attente pour examen et approbation humaine.

Prise en charge de Windows

L’application de bureau Codex a été lancée sous Windows le 4 mars 2026 (App v26.304) avec une prise en charge native de PowerShell, une sandbox Windows native et toutes les fonctionnalités, notamment les skills, les automatisations et les worktrees, sans nécessiter WSL.⁶⁶

Action GitHub et CI/CD

L’Action GitHub officielle intègre Codex à votre pipeline CI/CD.¹⁸

Utilisation de base

# .github/workflows/codex.yml
name: Codex
on:
  pull_request:
    types: [opened]

jobs:
  codex:
    runs-on: ubuntu-latest
    outputs:
      final_message: ${{ steps.run_codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
      - name: Run Codex
        id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          sandbox: workspace-write
          safety-strategy: drop-sudo

Options de configuration

Sortie : final-message, le texte de la réponse finale de Codex destiné aux étapes ou jobs en aval.

Stratégies de sécurité

Contrôles d’accès

with:
  allow-users: "admin,maintainer"     # Limit who can trigger
  allow-bots: false                   # Block bot-triggered runs

Par défaut : seuls les collaborateurs disposant d’un accès en écriture peuvent déclencher les workflows Codex.

Codex SDK

Le TypeScript SDK intègre les capacités d’agent de Codex dans des applications personnalisées.¹⁹

Installation

npm install @openai/codex-sdk

Utilisation de base

import { Codex } from "@openai/codex-sdk";

const codex = new Codex();
const thread = codex.startThread();

// Multi-turn conversation
const turn1 = await thread.run("Diagnose CI failures and propose a fix");
console.log(turn1.finalResponse);

const turn2 = await thread.run("Implement the fix and add tests");
console.log(turn2.items);

// Resume a previous session
const resumed = codex.resumeThread("<thread-id>");
await resumed.run("Continue from previous work");

Fonctionnalités avancées de SDK

• runStreamed(...) : flux d’événements asynchrone pour les mises à jour intermédiaires
• Authentification de Python SDK (v0.132.0+) : la connexion par clé API, les flux ChatGPT via navigateur/code d’appareil, l’inspection du compte et la déconnexion constituent des parcours SDK de premier plan.⁹⁷
• Praticité pour les tours en texte seul (v0.132.0+) : les APIs de tour de Python acceptent des chaînes simples et renvoient des métadonnées TurnResult plus riches avec les éléments collectés, la durée et l’utilisation.⁹⁷
• outputSchema : impose une sortie finale au format JSON
• Entrée multimodale : transmettez du texte + des images locales ({ type: "local_image", path: "..." })
• Flux de travail d’image (v0.117.0) : view_image renvoie des URL, les images générées peuvent être rouvertes et l’historique des images est conservé lors de la reprise d’une session⁷⁵
• view_image multi-environnements (v0.130.0) : pour les sessions couvrant plusieurs environnements (introduites en v0.124.0 avec la sélection de l’environnement et du répertoire de travail à chaque tour, puis affinées en v0.125.0 avec des environnements persistants), view_image résout désormais les chemins de fichiers via l’environnement sélectionné, plutôt que via le système de fichiers local de l’orchestrateur. Une image jointe depuis un environnement distant est récupérée relativement au répertoire de travail de cet environnement, et non depuis l’hôte exécutant le SDK.⁹¹

Configuration des threads et du client

// Custom working directory, skip git check
const thread = codex.startThread({
  workingDirectory: "/path/to/project",
  skipGitRepoCheck: true,
});

// Custom environment and config overrides
const codex = new Codex({
  env: { CODEX_API_KEY: process.env.MY_KEY },
  config: { model: "gpt-5.5" },
});

Les sessions sont conservées dans ~/.codex/sessions.

Runtime : Node.js 18+.

Optimisation des performances

Gestion du contexte

Les fenêtres de contexte varient selon le modèle. L’actuelle famille GPT-5.6 (Sol, Terra, Luna) utilise une fenêtre de 272K ; GPT-5.5, le modèle phare de génération précédente, offre 400K dans Codex (1M dans le API) ; GPT-5.4 / GPT-5.4-mini (retirés de Codex le 31 août 2026) offrent 1M / 400K ; l’ancienne famille GPT-5.3-Codex utilisait 272K en entrée + 128K en sortie (budget total de 400K). Tous se remplissent plus vite qu’on ne l’imagine — gérez-les de manière proactive :

1. Utilisez régulièrement /compact : résume l’historique de la conversation pour libérer des tokens
2. Fournissez une documentation locale : un AGENTS.md et une documentation locale de qualité réduisent la surcharge d’exploration (qui consomme du contexte)
3. Utilisez @ pour joindre des fichiers précis : référencez directement les fichiers au lieu de demander à Codex de les trouver
4. Gardez des prompts ciblés : des prompts délimités avec des fichiers précis consomment moins de contexte qu’une exploration ouverte

Efficacité des tokens

Optimisation de la vitesse

1. gpt-5.3-codex-spark : variante à plus faible latence pour le travail en binôme interactif
2. --profile fast : gpt-5.6-luna préconfiguré avec un raisonnement faible
3. Exécution parallèle des outils : Codex exécute simultanément les lectures et vérifications indépendantes ; structurez donc les prompts pour le permettre
4. Boucles orientées résultats : demandez « implémentez, testez, corrigez, arrêtez-vous lorsque tout est au vert » plutôt que des instructions étape par étape

Comment déboguer les problèmes ?

Problèmes courants et solutions

Référence des messages d’erreur

Que fait codex doctor ?

codex doctor est la commande unique à exécuter avant de signaler un bug ou de déboguer une installation défectueuse. Elle recueille dans un seul rapport l’environnement d’exécution local, la configuration, l’authentification, le terminal, le réseau et l’état, et le modèle de ticket du projet vous demande d’y coller sa sortie.¹²⁰

codex doctor                           # Full human-readable report (the default)
codex doctor --summary                 # Compact view
codex doctor --json                    # Redacted structured JSON, for bug reports
codex doctor --all                     # Expand truncated lists
codex doctor --no-color                # Strip ANSI color

Le rapport est organisé en sections stables ; vous pouvez donc parcourir directement celle dont vous avez besoin :¹²⁰

Chaque vérification comporte un marqueur d’état – ✓ ok, ✗ échec, ⚠ avertissement, ○ inactif – ainsi qu’une ligne de synthèse. --json associe chaque vérification à un identifiant stable, ce qui permet de l’utiliser dans une CI ou un script de support, et pas seulement à l’œil nu.¹²⁰

La commande s’est enrichie au fil des versions : elle est apparue dans la v0.131.0, a gagné les rapports sur l’environnement, Git, le terminal, app-server et l’inventaire des threads dans la v0.135.0, puis a ajouté les détails sur l’éditeur et le pager (avec les valeurs sensibles masquées dans JSON) dans la v0.139.0.⁹⁶[^179]¹²²

Utilisez-la en premier, pas en dernier. La plupart des signalements « Codex est défectueux » se résolvent par un élément que doctor indique déjà : un mode d’authentification obsolète, un config.toml qui n’a pas pu être analysé, ou une seconde installation qui masque celle présente dans votre PATH.

Outils de diagnostic

codex doctor                           # Full local diagnostic (start here)
codex --version                        # Check CLI version
codex login status                     # Verify authentication
codex mcp list                         # Check MCP server status
codex debug app-server --help          # Debug app server issues

Diagnostics TUI en session :

/status                                # Token/session overview
/config                                # Inspect effective config values and sources
/compact                               # Summarize history to reclaim context

Remarque : codex --verbose n’est pas un indicateur de niveau supérieur valide. Utilisez les sous-commandes de débogage et les diagnostics TUI ci-dessus.

Réinstallation propre

npm uninstall -g @openai/codex && npm install -g @openai/codex@latest

Préserve ~/.codex/ (authentification, configuration, sessions). Pour épingler une version exacte, rétrograder après une mauvaise version, ou effacer entièrement l’état, consultez Mettre à jour, rétrograder ou désinstaller.

Mode débogage

codex debug app-server send-message-v2  # Test app-server client

Signaler des problèmes

/feedback                              # Send logs to Codex maintainers (in TUI)

Vous pouvez également signaler des problèmes sur github.com/openai/codex/issues.¹

Codex Security [PREVIEW]

Codex Security est entré en research preview le 6 mars 2026, apportant une revue de sécurité applicative contextuelle à la pile Codex.⁷⁷ Il est disponible pour les clients ChatGPT Pro, Enterprise, Business et Edu via Codex web.

Fonctionnement : Codex Security analyse les dépôts afin de construire un modèle de menace propre au projet, identifie les vulnérabilités classées selon leur impact réel et met les résultats à l’épreuve dans un environnement sandbox pour les valider. L’agent fait remonter les constats les plus fiables avec des correctifs, réduisant ainsi le bruit causé par les bugs insignifiants.

Performances : Pendant la research preview, Codex Security a analysé 1,2 million de commits et identifié 10 561 vulnérabilités de gravité élevée. Sa précision s’est améliorée au fil du temps — réduisant le bruit de 84 %, les surévaluations de gravité de plus de 90 % et divisant par deux les taux de faux positifs. Le système a découvert de véritables vulnérabilités dans OpenSSH, GnuTLS et Chromium, avec 14 CVE attribués.⁷⁷

Remarque : Codex Security est distinct du modèle de sécurité sandbox intégré à CLI. Le sandbox protège votre machine de Codex ; Codex Security protège votre codebase des vulnérabilités.

Déploiement en entreprise

Contrôles administrateur (requirements.toml)

Les administrateurs appliquent la politique d’entreprise via requirements.toml, un fichier de configuration imposé par l’administrateur qui limite les paramètres sensibles pour la sécurité que les utilisateurs ne peuvent pas remplacer :²¹

v0.146.0 ajoute la reconnaissance des forfaits Enterprise et des contrôles administrateur sur les mises à jour dans l’application.¹¹⁴ Dans un parc géré, c’est la différence entre des développeurs qui mettent eux-mêmes à jour CLI dès qu’ils remarquent une nouvelle version et l’administrateur qui décide du moment où une version est déployée. Les notes de version annoncent ce contrôle sans publier sa clé requirements.toml — considérez le nom exact du paramètre comme non vérifié tant qu’OpenAI ne l’a pas documenté.

# /etc/codex/requirements.toml

# Restrict which approval policies users can select
allowed_approval_policies = ["untrusted", "on-request", "never"]

# Limit available sandbox modes
allowed_sandbox_modes = ["read-only", "workspace-write"]

# Control web search capabilities
allowed_web_search_modes = ["cached"]

# Allowlist MCP servers by identity (both name and identity must match)
[mcp_servers.approved-server]
identity = { command = "npx approved-mcp-server" }

# Admin-enforced command restrictions
[[rules.prefix_rules]]
pattern = [{ token = "rm" }, { any_of = ["-rf", "-fr"] }]
decision = "forbidden"
justification = "Recursive force-delete is prohibited by IT policy"

[[rules.prefix_rules]]
pattern = [{ token = "sudo" }]
decision = "prompt"
justification = "Elevated commands require explicit approval"

Contrairement au config.toml au niveau utilisateur, qui définit des préférences, requirements.toml constitue une couche de contraintes strictes qui restreint les valeurs que les utilisateurs peuvent sélectionner, sans possibilité de remplacement. Les règles d’exigences administrateur peuvent uniquement demander confirmation ou interdire (jamais autoriser silencieusement).

Configuration MDM macOS

Distribuez via MDM en utilisant le domaine de préférences com.openai.codex.²¹ Codex respecte les charges utiles MDM macOS standard (Jamf Pro, Fleet, Kandji, etc.). Encodez TOML en base64, sans retour à la ligne :

Priorité (de la plus élevée à la plus faible) :

1. Préférences gérées macOS (MDM)
2. Exigences récupérées depuis le cloud (ChatGPT Business / Enterprise)
3. /etc/codex/requirements.toml (système de fichiers local)

Les exigences cloud ne remplissent que les champs d’exigences non définis, de sorte que les couches gérées de priorité supérieure prévalent toujours. Les exigences cloud sont fournies au mieux ; si la récupération échoue ou expire, Codex continue sans la couche cloud.

Intégration OpenTelemetry

Codex prend en charge la propagation du contexte de trace OpenTelemetry à partir des variables d’environnement OTel standard jusqu’aux appels API d’OpenAI. Définissez les variables d’environnement standard avant de lancer Codex :

# Point Codex at your OTel collector
export OTEL_EXPORTER_OTLP_ENDPOINT="https://otel-collector.internal:4318"
export OTEL_SERVICE_NAME="codex-cli"
export OTEL_RESOURCE_ATTRIBUTES="team=platform,env=production"

# Launch Codex — trace context propagates to all OpenAI API calls
codex

• Les variables d’environnement OTEL_* standard sont respectées (endpoint, nom du service, attributs de ressource)
• Le contexte de trace se propage via Codex jusqu’aux appels API, ce qui permet une observabilité de bout en bout
• Utilisez les attributs de ressource pour étiqueter les traces par équipe, environnement ou projet
• Tenez compte des exigences de confidentialité lorsque vous activez la journalisation des prompts/outils — les traces peuvent contenir des extraits de code
• Métadonnées de trace OpenTelemetry configurables (v0.130.0+). Au-delà de l’enveloppe OTEL_RESOURCE_ATTRIBUTES standard, le crate codex-otel expose désormais des métadonnées de trace configurables afin que les administrateurs puissent étiqueter les traces avec des dimensions propres à l’organisation (centre de coûts, ID de projet, référence de ticket) sans devoir reconstruire OTEL_RESOURCE_ATTRIBUTES depuis zéro à chaque invocation. Associez cela aux analyses enrichies de révision et de feedback fournies dans la même version pour un débogage et un triage unifiés entre les sessions CLI, app-server et de contrôle à distance.⁹¹

Accès Enterprise

• ChatGPT Business / Enterprise / Edu : accès contrôlé par l’administrateur de l’organisation, avec application automatique des exigences récupérées depuis le cloud. Prend en charge le SSO via SAML/OIDC par l’intermédiaire de votre fournisseur d’identité (Okta, Entra ID, etc.)
• API : authentification, facturation et contrôles d’organisation/projet API standard. OpenAI publie des rapports SOC 2 Type II et SOC 3 ; un BAA HIPAA est disponible pour le niveau Enterprise
• Codex SDK : intégrez-le à vos outils et workflows internes
• Application des politiques à grande échelle : utilisez requirements_toml_base64 distribué par MDM ou /etc/codex/requirements.toml au niveau du système de fichiers

Gestion des données et conformité : - Les entrées/sorties API ne sont pas utilisées à des fins d’entraînement selon les conditions Business/Enterprise/API d’OpenAI - Concernant la résidence des données, le trafic API d’OpenAI transite par défaut par une infrastructure basée aux États-Unis ; pour les exigences de résidence des données dans l’UE, consultez l’équipe commerciale Enterprise d’OpenAI - Les transcriptions de session sont stockées localement ; seuls les appels API quittent la machine - ChatGPT Enterprise prend en charge des cadres de conformité, notamment SOC 2, le RGPD et le CCPA

Stratégie de déploiement

Déploiement progressif recommandé pour les organisations :

1. Pilote (Semaine 1-2) : déployez auprès de 3 à 5 ingénieurs seniors avec requirements.toml imposant le mode sandbox untrusted et la recherche web cached. Recueillez les retours sur les modèles AGENTS.md et les besoins en serveurs MCP.
2. Extension à l’équipe (Semaine 3-4) : déployez auprès de toute l’équipe. Distribuez le config.toml standard de l’équipe via MDM ou le dépôt. Activez le sandbox workspace-write pour les dépôts de confiance.
3. Intégration CI (Semaine 5-6) : ajoutez codex-action aux pipelines CI/CD pour automatiser la révision des PR et la génération de tests. Utilisez --ephemeral pour conserver des coûts prévisibles.
4. À l’échelle de l’organisation (Mois 2+) : déployez via MDM avec requirements.toml imposant les serveurs MCP approuvés, les politiques de sandbox et les listes autorisées de modèles.

Modèles d’audit

Suivez l’utilisation de Codex et appliquez la conformité :

• Traces OpenTelemetry : surveillez le volume d’appels API, l’utilisation des tokens et la latence par équipe
• Persistance des sessions : auditez ~/.codex/sessions/ lors des revues de conformité (désactivez-la avec --ephemeral dans les contextes sensibles)
• Application de l’identité MCP : requirements.toml journalise les tentatives de serveur bloquées — examinez-les afin de détecter toute utilisation non autorisée d’outils
• Piste d’audit Git : toutes les modifications de fichiers Codex passent par git standard — examinez-les via l’historique des branches et les différences de PR

Bonnes pratiques et anti-modèles

Modèles de prompts

1. Prompts guidés par des contraintes : Commencez par les limites. « Ne modifiez PAS les contrats de API. Refactorisez uniquement l’implémentation interne. »
2. Étapes de reproduction structurées : Les étapes numérotées produisent de meilleures corrections de bugs que des descriptions vagues
3. Demandes de vérification : Terminez par « Exécutez le lint et la plus petite suite de tests pertinente. Indiquez les commandes et les résultats. »
4. Références de fichiers : Utilisez @filename pour joindre des fichiers précis au contexte
5. Boucles guidées par le résultat : « Implémentez, exécutez les tests, corrigez les échecs, ne vous arrêtez que lorsque tous les tests réussissent. » Codex itère jusqu’à la finalisation

Philosophie des tests

La communauté converge vers une collaboration avec l’IA guidée par les tests :²²

• Définissez les tests dès le départ comme signaux d’achèvement
• Laissez Codex itérer jusqu’à ce que les tests réussissent (rouge → vert → refactorisation)
• Adoptez les modèles de programmation Tiger Style
• Fournissez le texte exact des fichiers lorsque vous demandez des correctifs. Codex utilise une correspondance stricte, et non des correctifs flous basés sur l’AST

Bonnes pratiques de gestion du contexte

• Fournissez une documentation locale de qualité plutôt que de vous appuyer sur la recherche web
• Maintenez du markdown structuré avec des tables des matières et des fichiers de progression (« divulgation progressive »)
• Normalisez les fins de ligne (LF ou CRLF) dans les fichiers suivis afin d’éviter les échecs de correctifs
• Gardez AGENTS.md concis, car les longues instructions sont repoussées hors du contexte

Workflow Git

• Créez toujours une nouvelle branche avant d’exécuter Codex sur des dépôts inconnus
• Utilisez des workflows basés sur des correctifs (git diff / git apply) plutôt que des modifications directes
• Examinez les suggestions de Codex comme des PR de revue de code
• Utilisez /diff pour vérifier les modifications avant de les valider

Skills et prompts communautaires

Le dépôt feiskyer/codex-settings fournit des configurations maintenues par la communauté :²³

Prompts réutilisables (dans ~/.codex/prompts/) : - deep-reflector : Extraire les enseignements des sessions de développement - github-issue-fixer [issue-number] : Analyse systématique des bugs et création de PR - github-pr-reviewer [pr-number] : Workflows de revue de code - ui-engineer [requirements] : Développement frontend de qualité production

Skills communautaires : - claude-skill : Transférer des tâches à Claude Code avec des modes d’autorisation - autonomous-skill : Automatisation de tâches sur plusieurs sessions avec suivi de la progression - deep-research : Orchestration parallèle de sous-tâches - kiro-skill : Pipeline exigences → conception → tâches → exécution

Anti-modèles

Erreurs courantes qui gaspillent des tokens, produisent de mauvais résultats ou créent des workflows frustrants.

Anti-modèles de coût

Anti-modèles de contexte

Anti-modèles de workflow

Anti-modèles de prompts

Recettes de workflow

Modèles de bout en bout pour les scénarios de développement courants.

Recette 1 : Configuration d’un nouveau projet

mkdir my-app && cd my-app && git init
codex

> Create a FastAPI project with: main.py, requirements.txt, Dockerfile,
  basic health endpoint, and a README. Use async throughout.

> /init

Examinez le AGENTS.md généré, modifiez-le pour qu’il corresponde à vos conventions, puis :

> Run the health endpoint test and confirm it passes

Recette 2 : Flux de développement quotidien

cd ~/project && git checkout -b feature/user-auth
codex

> @src/models/user.py @src/api/auth.py
  Add password reset functionality. Requirements:
  1. POST /api/auth/reset-request (email → sends token)
  2. POST /api/auth/reset-confirm (token + new password)
  3. Tests for both endpoints
  Run tests when done.

Examinez avec /diff, puis validez.

Recette 3 : Refactorisation complexe avec le mode Plan

codex

> /plan Migrate the database layer from raw SQL to SQLAlchemy ORM.
  Constraints: don't change any API contracts, keep all existing tests passing.

Examinez le plan. Approuvez-le ou orientez-le :

[Tab] Also add a migration script using Alembic

Après l’exécution par Codex, vérifiez :

> Run the full test suite and report results
> /diff

Recette 4 : Revue de PR avec codex exec

codex exec --model gpt-5.6-luna \
  "Review the changes in this branch against main. \
   Flag security issues, missed edge cases, and style violations. \
   Format as a markdown checklist." \
  -o review.md

Recette 5 : Débogage avec Cloud Tasks [EXPERIMENTAL]

codex cloud exec --env my-env "Diagnose why the /api/orders endpoint returns 500 \
  for orders with > 100 line items. Check the serializer, database query, \
  and pagination logic. Propose a fix with tests."

Vérifiez la progression plus tard :

codex cloud status <TASK_ID>
codex cloud diff <TASK_ID>

Appliquez le correctif localement une fois terminé :

codex apply <TASK_ID>

Guide de migration

Depuis Claude Code

Principales différences à comprendre :

• Le sandbox est au niveau du système d’exploitation : Codex utilise Seatbelt/Landlock, et non des conteneurs. Les restrictions s’appliquent au niveau du noyau, sous la couche applicative.
• Les hooks s’étendent : Codex prend désormais en charge 5 événements de hook : SessionStart, Stop et UserPromptSubmit (v0.114.0–v0.116.0, expérimental), ainsi que AfterAgent (v0.99.0) et AfterToolUse (v0.100.0). Le système couvre le cycle de vie des sessions, l’interception des prompts et l’automatisation au niveau des outils, bien que les 12+ événements de cycle de vie de Claude Code offrent toujours une couverture plus large. Pour les modèles d’automatisation qui ne sont pas encore couverts, utilisez les instructions AGENTS.md ou les skills.
• Sous-agents v2 (v0.117.0) : Les sous-agents utilisent désormais des adresses basées sur les chemins (par exemple, /root/agent_a), avec une messagerie structurée entre agents et une liste des agents.⁷⁵ Cela étend le mécanisme existant (6 simultanés maximum, contre 12 dans v0.91.0). Les rôles multi-agents restent personnalisables via la configuration (v0.104.0+).⁴⁷ La v0.105.0 a ajouté spawn_agents_on_csv pour la répartition sur plusieurs lignes, avec suivi de la progression et estimation de l’heure d’arrivée.⁶¹ Codex ne propose toujours pas l’expérience utilisateur explicite de l’outil Task de Claude Code pour une délégation dirigée par l’utilisateur — utilisez les cloud tasks ou l’orchestration SDK pour les modèles de délégation.
• AGENTS.md est inter-outils : Votre AGENTS.md fonctionne dans Cursor, Copilot, Amp, Jules, Gemini CLI et plus de 60 000 projets open source. CLAUDE.md est réservé à Claude.
• Les profils remplacent le changement manuel : Au lieu de modifier les indicateurs à chaque exécution, définissez des profils dans config.toml.

Depuis GitHub Copilot

Ce que vous gagnez : - Sandbox au niveau du système d’exploitation (Seatbelt/Landlock — appliqué par le noyau plutôt que basé sur des conteneurs) - Délégation de cloud tasks avec codex apply - Profils de configuration pour changer de workflow - Application de bureau avec isolation par worktree

Depuis Cursor

Carte de référence rapide

╔═══════════════════════════════════════════════════════════════╗
║                    CODEX CLI QUICK REFERENCE                  ║
╠═══════════════════════════════════════════════════════════════╣
║                                                               ║
║  LAUNCH                                                       ║
║  codex                      Interactive TUI                   ║
║  codex "prompt"             TUI with initial prompt           ║
║  codex exec "prompt"        Non-interactive mode              ║
║  codex app                  Desktop app                       ║
║  codex resume               Resume previous session           ║
║  codex fork                 Fork a session                    ║
║                                                               ║
║  FLAGS                                                        ║
║  -m, --model <model>        Select model                      ║
║  -p, --profile <name>       Load config profile               ║
║  -s, --sandbox <mode>       Sandbox mode                      ║
║  -C, --cd <dir>             Working directory                 ║
║  -i, --image <file>         Attach image(s)                   ║
║  -c, --config <key=value>   Override config                   ║
║  --ask-for-approval <p>     Approval policy                   ║
║  --oss                      Use local models (Ollama)         ║
║  --search                   Enable live web search            ║
║                                                               ║
║  SLASH COMMANDS (in TUI)                                      ║
║  /compact      Free tokens   /diff        Git diff            ║
║  /review       Code review   /plan        Plan mode           ║
║  /model        Switch model  /status      Session info        ║
║  /fork         Fork thread   /goal        Persisted goal      ║
║  /vim          Modal Vim     /hooks       Browse/toggle hooks ║
║  /init         AGENTS.md scaffold                             ║
║  /mcp          MCP tools     /skills      Invoke skills       ║
║  /ps           Background    /personality Style               ║
║  /permissions  Approval mode /statusline  Footer config       ║
║  /fast         Toggle fast mode (default: on)                 ║
║  /copy         Copy last response to clipboard                ║
║  /clear        Clear screen  /theme       Syntax highlighting ║
║                                                               ║
║  TUI SHORTCUTS                                                ║
║  @              Fuzzy file search                             ║
║  !command       Run shell command                             ║
║  Ctrl+G         External editor                               ║
║  Ctrl+L         Clear screen                                  ║
║  Enter          Inject instructions (while running)           ║
║  Esc Esc        Edit previous messages                        ║
║                                                               ║
║  EXEC MODE (CI/CD)                                            ║
║  codex exec --sandbox workspace-write "task" Sandboxed auto   ║
║  codex exec --json -o out.txt "task"    JSON + file output    ║
║  codex exec --output-schema s.json      Structured output     ║
║  codex exec resume --last "continue"    Resume session        ║
║                                                               ║
║  MCP MANAGEMENT [EXPERIMENTAL]                                ║
║  codex mcp add <name> -- <cmd>    Add STDIO server            ║
║  codex mcp add <name> --url <u>   Add HTTP server             ║
║  codex mcp list                    List servers               ║
║  codex mcp login <name>           OAuth flow                  ║
║  codex mcp remove <name>          Delete server               ║
║                                                               ║
║  PLUGINS                                                      ║
║  codex plugin marketplace add <src>     Add marketplace       ║
║  codex plugin marketplace upgrade       Upgrade marketplaces  ║
║                                                               ║
║  CLOUD [EXPERIMENTAL]                                         ║
║  codex cloud exec --env <ID> Start cloud task                 ║
║  codex cloud status <ID>     Check task progress              ║
║  codex cloud diff <ID>       View task diff                   ║
║  codex cloud list            List tasks                       ║
║  codex apply <TASK_ID>       Apply cloud diff locally         ║
║                                                               ║
║  CONFIG FILES                                                 ║
║  ~/.codex/config.toml        User config                      ║
║  .codex/config.toml          Project config                   ║
║  ~/.codex/AGENTS.md          Global instructions              ║
║  AGENTS.md                   Project instructions             ║
║  requirements.toml           Enterprise policy constraints    ║
║                                                               ║
║  SANDBOX MODES                                                ║
║  read-only          Read files only, no mutations             ║
║  workspace-write    Read/write in workspace + /tmp            ║
║  danger-full-access Full machine access                       ║
║                                                               ║
║  APPROVAL POLICIES                                            ║
║  untrusted     Prompt for all mutations                       ║
║  on-request    Prompt for boundary violations                 ║
║  never         No prompts                                     ║
║                                                               ║
║  MODELS (Aug 2026)                                            ║
║  gpt-5.6-sol           Recommended default ("Power", 272K)    ║
║  gpt-5.6-terra         Everyday model (272K)                  ║
║  gpt-5.6-luna          Fast + affordable (272K)               ║
║  gpt-5.5               Previous-gen flagship (400K in Codex)  ║
║  gpt-5.4 / -mini       Retire from Codex Aug 31, 2026         ║
║                                                               ║
╚═══════════════════════════════════════════════════════════════╝

Journal des modifications