Codex CLI : la référence technique ultime

En bref : Codex est un agent de développement multisurface : il lit votre base de code, 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 et d’approbation, AGENTS.md, MCP et les skills – et il démultipliera votre efficacité. Quel modèle choisir : la documentation d’OpenAI sur les modèles recommande désormais GPT-6 Sol (gpt-6-sol, disponible dans le sélecteur CLI depuis la v0.156.1) pour les tâches de développement courantes et complexes, GPT-6-Astra pour les travaux de bout en bout les plus exigeants (il reste le modèle intégré par défaut de CLI lorsqu’aucun modèle n’est défini) et GPT-6 Luna pour les tâches ciblées à gros volume. Leur disponibilité dépend de votre forfait, des paramètres de votre espace de travail et du déploiement en cours ; les modèles GPT-5.6 restent disponibles entre-temps. GPT-5.5 sera retiré de Codex pour les connexions via ChatGPT le 14 octobre 2026.¹⁴⁶¹⁷¹ Vous débutez ? Passez directement à l’installation et au démarrage rapide. Vous suivez les nouvelles versions ? La dernière version stable est la v0.157.1 (26 septembre 2026) ; les temps forts des versions commencent par un résumé de l’état actuel (ce qui est activé par défaut et ce qui reste expérimental), puis détaillent chaque version, tandis que le journal des modifications répertorie toutes les mises à jour du guide.¹¹⁶¹⁷⁴

Codex fonctionne comme un agent de développement multisurface, et non comme un chatbot qui écrit du code. CLI lit votre base de code, exécute des commandes dans un sandbox, modifie des fichiers, se connecte à des services externes via MCP et délègue au cloud les tâches de longue durée. Il s’exécute localement, mais raisonne à l’échelle globale ; la même intelligence alimente cinq interfaces distinctes selon votre façon de travailler, notamment l’extension de navigateur (Chrome, Edge, Brave, Opera et Vivaldi), qui exécute Codex dans votre navigateur sans en prendre le contrôle.⁹⁰¹²⁷

La différence entre une utilisation occasionnelle et une utilisation efficace de Codex repose sur cinq systèmes fondamentaux. Maîtrisez-les et Codex démultipliera votre efficacité :

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

Pendant plusieurs mois, j’ai utilisé Codex aux côtés de Claude Code sur des bases de code en production, des pipelines CI/CD et des workflows d’équipe. Ce guide synthétise cette expérience pour constituer la référence complète que j’aurais aimé avoir à mes débuts. Chaque fonctionnalité est accompagnée de sa syntaxe exacte, d’exemples de configuration concrets et des cas limites qui prennent au piège même les utilisateurs expérimentés.

Points clés

• Cinq interfaces, un seul cerveau : CLI, l’application de bureau, l’extension IDE, les tâches cloud et l’extension de navigateur (Chrome, Edge, Brave, Opera et Vivaldi) partagent tous la même famille de modèles ; choisissez donc l’interface adaptée à votre flux de travail.⁹⁰
• Sandboxing au niveau du système d’exploitation : Codex applique les restrictions relatives au système de fichiers et au réseau au niveau du noyau (Seatbelt sous macOS, Landlock + seccomp sous Linux), et non dans des conteneurs.
• AGENTS.md fonctionne avec plusieurs 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-les une fois, utilisez-les 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 passez de l’un à l’autre avec --profile.
• La gestion du contexte est essentielle : le catalogue Codex intégré offre à GPT-6 Astra, Sol et Luna, ainsi qu’à la famille GPT-5.6, une fenêtre de contexte de 272K (le API indique 1.05M pour GPT-6 Sol et Luna) ; GPT-5.5 propose 400K dans Codex jusqu’à son retrait de cette plateforme le 14 octobre 2026. Utilisez /compact, des prompts ciblés et des références @file pour gérer les budgets de tokens de manière proactive.⁸³¹¹²

Comment utiliser ce guide

Cette référence compte plus de 3 300 lignes — commencez par la section adaptée à votre niveau d’expérience :

La fiche de référence rapide située à la fin fournit un récapitulatif facile à parcourir de toutes les commandes principales.

Points forts des dernières versions : changements récents

Voici l’historique version par version, de la plus récente à la plus ancienne, pour les lecteurs qui suivent le rythme des versions de Codex. Vous découvrez Codex ? Passez au démarrage rapide ; rien de ce qui suit n’est nécessaire pour être opérationnel. Les détails de vérification (comparaisons, listes de commits, contrôles de la documentation) figurent dans les notes de bas de page.

État actuel

Codex CLI au 26 septembre 2026

• Version stable : v0.157.1, publiée le 26 septembre (npm latest), est un correctif Windows qui complète la v0.157.0 (25 septembre).
• Version alpha : la balise npm alpha correspond à la version 0.159.0-alpha.4. La branche 0.158 n’a donné lieu à aucune version stable.
• Activés par défaut depuis la v0.157.0 : la transcription en plein écran, le démarrage automatique du serveur en arrière-plan et le contexte de thread Guardian. Pour en désactiver un, définissez fullscreen_transcript = false sous [tui], daemon_auto_start = false sous [features] (ou lancez Codex avec --no-daemon) ou thread_context = false sous [features.guardianv2].
• Activés par défaut depuis la v0.156.0 : /voice, les worktrees gérés et la réutilisation par Guardian de la compaction du parent (clés [features] realtime_conversation, worktrees, guardian_reuse_parent_compaction).
• Toujours facultatifs ou expérimentaux : la gestion expérimentale du contexte, Codex Cloud et le mode code.
• Modèles : GPT-6 Sol (gpt-6-sol) pour les tâches de programmation courantes et complexes, GPT-6-Astra pour les travaux de bout en bout les plus difficiles (toujours le modèle par défaut intégré de la CLI lorsqu’aucun modèle n’est défini), GPT-6 Luna pour les tâches à fort volume. GPT-5.5 quitte Codex pour les connexions via ChatGPT le 14 octobre 2026.
• Épinglage : npm install -g @openai/codex@0.157.1, puis vérifiez la version avec codex --version.¹⁷⁴¹⁷⁵

v0.157.1 (26 septembre 2026)

Un correctif Windows composé de quatre corrections rétroportées depuis la branche principale. Codex n’ouvre plus de fenêtre de console lorsqu’il démarre l’hôte du mode code ou un serveur MCP stdio local. Le serveur en arrière-plan peut désormais se lancer lorsque Windows maintient le processus dans un objet de tâche externe, et un serveur en arrière-plan détaché ne garde plus ouverts les canaux de sortie du lanceur, ce qui pouvait laisser la commande appelante en attente après la fermeture de celui-ci. Les notes de version de la GitHub et l’entrée du journal des modifications indiquent uniquement que les points forts « ne pouvaient pas être déterminés » ; la liste ci-dessus provient des commits de cette version.

Que faire : effectuez la mise à niveau si vous utilisez Codex sous Windows. Ces quatre corrections concernent exclusivement Windows.¹⁷⁴

v0.157.0 (25 septembre 2026)

Cette version active trois nouveaux comportements par défaut.

• La transcription en plein écran est activée par défaut. L’interface plein écran proposée par la v0.156.0 via /tui est désormais celle qui s’ouvre au début d’une session, y compris lorsque la configuration ne contient aucune section [tui]. Pour conserver l’historique de défilement du terminal, sélectionnez Scrollback dans /tui ou définissez fullscreen_transcript = false sous [tui] ; --no-alt-screen et tui.alternate_screen = "never" restent prioritaires. Maj-clic permet désormais d’étendre une sélection dans la transcription.
• Le serveur en arrière-plan démarre automatiquement pour les lancements interactifs compatibles, et l’option quitte /experimental. Les lancements avec --no-daemon, --oss, --profile ou la plupart des substitutions -c ne l’utilisent pas. Si les paramètres d’un serveur en cours d’exécution ne correspondent pas à ceux de la session, Codex propose de poursuivre sans lui, de le redémarrer avec les paramètres requis ou d’annuler (choix par défaut). Pour désactiver le démarrage automatique, définissez daemon_auto_start = false sous [features].
• Le contexte de thread Guardian est activé par défaut pour les révisions synchrones et asynchrones, indépendamment de l’option enabled de Guardian v2. Pour le désactiver, définissez thread_context = false sous [features.guardianv2].

Modèles : GPT-6 Sol et Luna, apparus pour la première fois dans la v0.156.1, figurent également dans cette version, et les catalogues Amazon Bedrock les proposent désormais, GPT-6 Sol remplaçant GPT-5.6 Sol comme modèle Bedrock par défaut. GPT-5.6 Sol perd son niveau de service ultrafast ; seul Fast reste disponible. Le catalogue intégré n’indique plus que GPT-6-Astra prend en charge la gestion expérimentale du contexte (voir Gestion du contexte).

Autres nouveautés : le raccourci f duplique une conversation ouverte dans une autre application tout en conservant les brouillons et les invites en file d’attente ; /import fonctionne dans les sessions distantes et celles utilisant le serveur en arrière-plan ; le terminal affiche les puces Unicode, les cases à cocher et les équations alignées. Les corrections maintiennent les conversations vocales lorsque vous changez de thread, récupèrent les réponses non envoyées à la fin d’un tour, respectent les paramètres de souris de tmux, acheminent les connexions en temps réel et la recherche web autonome par les proxys configurés, réessaient les téléversements de fichiers interrompus avec un délai maximal de cinq minutes et appliquent les restrictions réseau aux redirections ainsi qu’aux connexions HTTP et WebSocket ouvertes. Sous Windows, l’accès aux objets du sandbox est limité à la session de connexion de l’exécuteur.¹⁷⁴

v0.156.1 (23 septembre 2026)

Un correctif ne comportant qu’une seule modification, qui apporte GPT-6 Sol et GPT-6 Luna à la CLI stable. Les deux apparaissent désormais dans le sélecteur /model sous GPT-6-Astra, qui reste en première position et demeure le modèle par défaut intégré lorsque config.toml ne définit aucun modèle. Le sélecteur présente la famille GPT-5.6 comme d’anciens modèles (GPT-5.6 Sol est décrit comme « Ancien modèle de programmation pour les tâches complexes ») et GPT-5.5 comme un « Modèle de programmation hérité ». Lorsque vous approchez d’une limite de débit, l’invite de changement suggère maintenant gpt-6-luna au lieu de gpt-5.6-luna.

Si votre configuration désigne un ancien modèle, attendez-vous à une invite de migration unique : les sélections enregistrées de gpt-5.6-sol, gpt-5.6-terra, gpt-5.5 et gpt-5.4 redirigent vers GPT-6 Sol, tandis que gpt-5.6-luna et gpt-5.4-mini redirigent vers GPT-6 Luna. Les catalogues Amazon Bedrock ne changent pas dans cette version : ils ne proposent ni GPT-6 Sol ni Luna, et GPT-5.6 Sol reste le modèle Bedrock par défaut.

Un détail tarifaire que la documentation ne mentionne pas : le catalogue intégré définit Fast (priority) comme niveau de service par défaut pour GPT-6 Sol et Luna. Une session TUI sans service_tier défini peut donc démarrer en mode Fast, facturé 2,5 fois plus de crédits Standard avec une connexion via ChatGPT. Vérifiez avec /fast status ; /fast off repasse en Standard.

Que faire : effectuez la mise à niveau, puis essayez codex -m gpt-6-sol sur une tâche familière. La disponibilité dépend de votre offre, des paramètres de votre espace de travail et du déploiement ; les administrateurs Enterprise doivent d’abord activer les nouveaux modèles.¹⁷¹

v0.156.0 (22 septembre 2026)

Cette version active trois comportements par défaut à la fois ; le journal des modifications de la documentation a annoncé les deux premiers le jour même.

• La voix est activée par défaut. /voice démarre une conversation en direct sur les builds compatibles sans passer par /experimental. Autres nouveautés associées : une touche F8 configurable pour activer ou désactiver la fonction, un sélecteur /voice settings permettant de choisir la voix des conversations futures, des environnements d’exécution vocaux intégrés pour Linux et Windows, ainsi que la prise en charge de la réduction des animations.
• Les worktrees gérés sont activés par défaut. --worktree et /worktree ne nécessitent plus de feature flag. Les sessions de worktree peuvent se connecter à un daemon local existant et être créées depuis la vue d’ensemble des agents.
• La réutilisation par Guardian de la compaction du parent est activée par défaut : lorsque Guardian redémarre une session de révision, il peut réutiliser la compaction chiffrée du thread parent.

Les lignes consacrées à /voice et /worktree dans le tableau des slash commands, ainsi que la section Guardian, expliquent comment désactiver chaque fonctionnalité.

Autres nouveautés : une TUI plein écran facultative, sélectionnée avec /tui, comprenant la recherche dans la transcription, la sélection et la copie à la souris, la copie par clic droit, des liens cliquables et une visionneuse d’avertissements ; six thèmes intégrés dans le sélecteur /theme ; le tableau de bord analytique /usage ; le rendu des diagrammes Mermaid et des expressions mathématiques TeX dans le terminal, chacun avec sa propre option ; un menu /daemon et un flag --no-daemon ; les résumés de raisonnement désactivés par défaut pour les nouveaux threads TUI. Les correctifs de sécurité comblent sous Windows des failles du sandbox liées au trafic entrant, aux sockets privilégiés et aux handles de fichiers en lecture seule, tandis que codex doctor n’affiche plus les valeurs de configuration dans ses erreurs. Les corrections de bugs conservent les réponses diffusées après l’échec ou l’interruption d’un tour, réparent le transfert du presse-papiers dans tmux et SSH, rétablissent le mode Plan lors de la reprise et permettent à la connexion de fonctionner de nouveau avec les proxys système.¹⁶⁹

v0.155.1 (18 septembre 2026)

Un correctif urgent ne comportant qu’une seule correction. Dans la version 0.155.0, un nouveau thread TUI local dépourvu de model_reasoning_summary dans sa configuration demandait des résumés detailed, et les fournisseurs ne prenant pas en charge les résumés de raisonnement rejetaient entièrement la requête. La version 0.155.1 rétablit none comme valeur de secours : une clé non définie ne demande donc aucun résumé. Les paramètres explicites auto, concise et detailed ont toujours été respectés et le restent. Cette même modification d’une ligne a également été intégrée à la branche principale et publiée dans la version 0.156.0.

Que faire : si de nouvelles sessions TUI sous 0.155.0 échouaient avec un fournisseur autre qu’OpenAI ou auto-hébergé, effectuez la mise à niveau. Si vous souhaitez obtenir des résumés, définissez explicitement la clé (voir la référence de configuration).¹⁵⁸

v0.155.0 (17 septembre 2026)

La voix est arrivée dans la TUI stable sous la forme d’une fonctionnalité expérimentale facultative : /voice ouvrait une conversation en direct avec une transcription en continu et des commandes de microphone, activée via /experimental sur les builds compatibles, avec un raccourci configurable pour couper le son et des ressources vocales signées dans les paquets macOS. La v0.156.0 l’a activée par défaut cinq jours plus tard. Les worktrees gérés restaient désactivés par défaut dans cette version.

Également dans la version 0.155.0 :

• Vérification de l’utilisateur MCP : vérification par Touch ID des requêtes MCP, signée par la Secure Enclave, dans les sessions TUI locales sur les Mac compatibles, avec restriction de l’identité à l’espace de travail et vérification native dans les continuations d’outils MCP.
• La slash command Windows /sandbox-add-read-dir est supprimée.
• Gestion des worktrees : masquez, archivez et supprimez des sessions de worktree dans la vue d’ensemble des agents, consultez les détails de propriété et confirmez avant de supprimer un worktree géré propre.
• Les résumés de raisonnement en direct sont diffusés dans la ligne d’état de la TUI, avec l’heure de fin pour les travaux terminés.
• Daemon : calendriers de mise à jour configurables, commande codex app-server daemon update et récupération des threads après le redémarrage du daemon.
• Commandes d’identifiants AWS pour Amazon Bedrock et publication des Python SDK alignée sur les versions stables de la CLI.

Les correctifs de sécurité bloquent les échappements par l’interopérabilité WSL et l’exposition d’identifiants dans les instantanés du shell. Memory v2 n’apporte ici que les fondations du stockage et de la consolidation, sans fonctionnalité utilisable.¹⁵⁶

v0.154.0 (9 septembre 2026)

Cette version a été créée approximativement à la limite de la 0.154.0-alpha.6. Tout ce qui est apparu pour la première fois dans l’alpha.7 (voix en direct dans la TUI, vérification de l’utilisateur MCP, Memory v2, configuration de la mise à jour automatique du daemon et épinglage de l’effort de raisonnement) a donc attendu la version 0.155.

Suppression : codex mcp-server et le binaire autonome codex-mcp-server. Migrez les intégrations vers le protocole app-server ou le plugin Codex pour Claude Code ; codex mcp, qui connecte Codex à des serveurs MCP externes, n’est pas concerné (voir Exécuter Codex EN TANT QUE serveur MCP). Les anciens parcours de révision des approbations Guardian ont également disparu, et les approbations sont désormais rejetées lorsque de nouvelles instructions de l’utilisateur les invalident.

Nouveautés :

• Worktrees gérés expérimentaux via --worktree ou /worktree, avec prise en charge de codex exec et navigateur de worktrees dans la TUI.
• Messages utilisateur asynchrones : répondez aux questions intégrées pendant que Codex continue de travailler, sans perdre votre brouillon.
• Prise en charge des services Windows : provisionnement du sandbox, daemon app-server sous Windows et mises à jour gérées du daemon.
• Profils d’autorisation distants, détectés depuis l’app server et sélectionnables par leur nom dans la TUI.
• Mode de remplacement Vim R, état en direct de la compaction du contexte et gestion expérimentale du contexte conditionnée par les capacités du modèle au démarrage de la session.

Sécurité : les assistants PATH ne s’exécutent plus avant que la confiance accordée à l’espace de travail soit établie, et le sandbox macOS est renforcé contre l’injection de saisies dans le terminal. Les connexions MCP coordonnent les actualisations des jetons OAuth, les reprises et duplications distantes conservent les autorisations enregistrées, et la reprise d’une conversation ouverte dans une autre application affiche une transcription en lecture seule. La voix n’a été publiée que sous forme d’infrastructure d’exécution, et les premières références au code Daybreak ont été intégrées sans documentation publique.¹⁵²¹⁵³

v0.153.3 et v0.153.4 (4 septembre 2026)

Des correctifs publiés le même jour qui ont intégré le lancement de GPT-6-Astra à la CLI. La v0.153.3 a ajouté Astra aux catalogues Amazon Bedrock (GPT-5.6 Sol restant le modèle Bedrock par défaut) et corrigé les consignes d’Astra concernant les demandes de clarification asynchrones. La v0.153.4 a ajouté Astra au sélecteur de modèles, en a fait le modèle par défaut intégré lorsqu’aucun modèle n’est configuré et a adapté les consignes relatives aux questions asynchrones en fonction de la disponibilité des outils.

Que faire : Astra fonctionne avec -m gpt-6-astra à partir de la v0.153.1 et apparaît dans le sélecteur à partir de la v0.153.4 ; aucune version minimale de la CLI n’étant documentée, considérez-les comme les versions minimales requises. Si votre compte n’a pas accès au modèle choisi par défaut par le catalogue intégré, définissez explicitement model dans config.toml au lieu de compter sur la valeur par défaut.^145146147148

v0.153.1 et v0.153.2 (3 septembre 2026)

La v0.153.1 fait respecter les exigences du modèle par l’évaluation de l’utilisation de l’ordinateur de Guardian : les évaluations limitées à l’utilisation de l’ordinateur et les décisions d’approbation rapides ne s’exécutent que lorsque les métadonnées du modèle actif définissent node_repl_auto_review_required. En outre, un changement vers un modèle qui ignore l’évaluation invalide les scores antérieurs ou en cours, de sorte qu’un retour au modèle précédent ne puisse pas réactiver une approbation obsolète. Le corps de la version ne mentionne qu’une entrée de catalogue GPT-6-Astra rétroportée, configurable via le API ; le sélecteur et le modèle par défaut n’ont changé qu’avec la v0.153.4. La v0.153.2 corrige la description du niveau Fast d’Astra, qui passe de « vitesse 1,5x » à « vitesse 2x, utilisation accrue » (texte d’affichage uniquement).¹⁴²¹⁴³

v0.153.0 (3 septembre 2026)

• Annulation et rétablissement dans Vim : u et Ctrl+R restaurent les brouillons complets du champ de saisie, y compris le contenu collé et les images jointes ; vim_normal.redo est une action de raccourci configurable.
• Marketplaces de plugins distantes : la CLI de plugins peut répertorier, installer et supprimer des plugins distants, tandis que codex plugin list affiche la source, la version, la politique d’installation et la politique d’authentification.
• tui.auto_recap = false désactive les récapitulatifs automatiques ; la commande manuelle /recap continue de fonctionner.
• Avertissements de limite de débit plus précoces pour Plus et Team lorsqu’il reste moins de la moitié de l’allocation sur une fenêtre d’environ cinq heures ; les autres offres conservent les seuils de 75/90/95 %.
• Le périmètre de Guardian suit le mode d’approbation : Full Access ignore les révisions Guardian pour les actions nécessitant uniquement une confirmation, tandis que le mode d’approbation User ignore l’évaluation et le préchauffage en arrière-plan.
• features.context_management.experimental_mode (désactivé par défaut) active le contexte fondé sur un budget de jetons, les notes d’historique et l’outil new_context pour les sessions Plus, Pro et Pro Lite compatibles sur le backend Codex.
• tui.disable_paste_burst remplace la clé de premier niveau, qui continue de fonctionner comme solution de secours.

Corrections : les sessions TUI se reconnectent après une interruption de l’app server en conservant leurs brouillons, l’historique des révisions Guardian survit à la compaction, aux redémarrages et aux duplications, et les approbations MCP mémorisées sont limitées au compte sélectionné.¹⁴⁰

v0.152.0 et v0.152.1 (1er septembre 2026)

update_plan devient facultatif : tools.update_plan.enabled vaut false par défaut. Tant qu’il est désactivé, les consignes update_plan intégrées sont retirées des invites du modèle, du mode collaboration, du mode multi-agent, de la compaction, du préchauffage et de la poursuite des objectifs (voir Mode Plan et collaboration). Autres nouveautés : recherche Vim avec / et ?, puis n/N, combinable avec les opérateurs, les nouveaux brouillons démarrant en mode Insert ; bannières exploitables de limite de débit ; progression de l’actualisation des identifiants, notamment pour la réauthentification Amazon Bedrock ; noms de serveurs MCP au format paquet (:, @, / et . sont autorisés) ; requêtes de formulaire MCP openai/elicitation ; output_token_limit MCP propre à chaque outil ; identifiants des tâches cloud limités aux origines fiables ; délais d’expiration thread/shellCommand configurables ; budgétisation des jetons activée par défaut via les métadonnées du modèle. La v0.152.1 permet à la révision des approbations Guardian de tirer sa politique Node REPL des métadonnées du modèle.¹³⁸¹³⁹

v0.151.0 (29 août 2026)

• /recap résume la conversation à la demande, et Codex récapitule automatiquement les conversations compatibles qui sont inactives et ne sont pas au premier plan.
• Les hôtes du mode code abandonnent le transport WebSocket (stdio et gRPC uniquement).
• Les threads persistants utilisent par défaut un historique paginé lorsque le stockage le permet.
• L’effort de raisonnement persistent arrive avec des outils d’horloge et des consignes de proactivité intégrées.
• Guardian v2 utilise par défaut des révisions d’utilisation de l’ordinateur avec des images.
• Vim ajoute les déplacements de recherche jusqu’au caractère f/F/t/T, ainsi que gg/G.
• La saisie dans les terminaux avec élévation peut exiger une nouvelle approbation (write_stdin_approval, désactivé par défaut).
• Un délai de grâce configurable pour les serveurs MCP facultatifs (mcp_optional_startup_grace_ms, 1 000 ms par défaut), et les extensions peuvent inspecter ou remplacer les résultats des outils MCP.

Les corrections empêchent /cd d’affaiblir les restrictions du sandbox et les classifications Guardian obsolètes d’autoriser des actions après une modification des permissions. Le corps de la version ne répertorie que les dernières PR ; l’ensemble complet des modifications figure dans la comparaison.¹³⁴¹³⁵

v0.150.0 et v0.150.1 (26-27 août 2026)

Les hooks ajoutent un événement Interrupt qui s’exécute lorsqu’un tour actif de premier niveau est interrompu (délai d’expiration de 1 seconde par défaut, plafonné à 3 secondes, jamais pour les sous-agents). /copy ouvre un sélecteur pour la réponse complète, les blocs de code individuels ou les citations. Les tâches deviennent adressables par des mentions @, les agents peuvent lire, créer et envoyer des messages aux tâches, et /rename suggère un titre modifiable. Les liens Markdown sont affichés sous forme de libellés cliquables, les raccourcis peuvent faire défiler les modes d’autorisation, Vim ajoute la répétition ., et les projets non fiables ne fournissent plus d’instructions AGENTS.md au niveau du projet. features.network_proxy.credential_broker et review_scope.computer_use_only de Guardian v2 apparaissent comme options configurables, désactivées par défaut. La v0.150.1 comptabilise les images conservées dans le budget de jetons de la compaction distante.¹³²¹³³

v0.149.0 et v0.149.1 (20-24 août 2026)

La politique d’approbation untrusted est retirée ; remplacez-la par on-request dans les configurations qui la mentionnent. Nouveautés : tableau de bord interactif codex agents, /cd, /pwd et /cwd, codex queue pour envoyer des messages aux sessions locales ou distantes existantes, davantage de mouvements de modification Vim, version enrichie de codex doctor (protection des points de terminaison, défaillances du réseau et du proxy, état de l’application de bureau, connectivité des mises à jour), et efforts de raisonnement max/ultra dans les SDKs. Les threads repris et dupliqués restaurent leur profil d’autorisation. La v0.149.1 ajoute codex exec --thread-source <SOURCE> (user, subagent, memory_consolidation ou le nom d’une fonctionnalité ; threadSource dans le TypeScript SDK).

Tarification sur la même période : OpenAI a réduit de plus de 20 % le tarif de GPT-5.6 Sol pendant trois mois à compter du 21 août (au moins jusqu’au 21 novembre 2026), et le coût en crédits Codex de Sol est passé de 125/12,5/750 à 100/10/500 crédits par million de jetons d’entrée, en cache et de sortie.^120121126

v0.147.0 et v0.148.0 (7-18 août 2026)

La v0.147.0 supprime codex exec --full-auto (obsolète depuis la v0.128) ; utilisez --sandbox workspace-write avec un flag d’approbation ou un profil. Elle ajoute également --approve-for-me, des Agent Plugins portables avec recherche dans les catalogues, le protocole MCP 2026-07-28 facultatif et des sections de conversation. La v0.148.0 ajoute /export vers Markdown, codex exec fork, une estimation des crédits ou du coût dans /status, Amazon Bedrock Runtime comme fournisseur intégré, des hooks asynchrones pouvant invoquer MCP, ainsi que des restrictions du sandbox qui bloquent l’opération en cas de chemins refusés ou illisibles.¹¹⁶¹¹⁸

Versions antérieures (mai-juillet 2026)

• v0.146.0 et v0.146.1 (29 juillet, 5 août) : les proxys configurés couvrent tous les transports ; manifests d’Agent Plugins, ainsi que marketplaces Amazon Bedrock et Claude Code ; attribution de noms aux sessions avec épinglage des threads ; skills fournis par l’exécuteur ; valeurs par défaut renforcées pour les révisions automatiques des modèles dotés de capacités cyber.¹¹⁴¹¹⁵
• v0.145.0 (21 juillet) : /import depuis Cursor ainsi que Claude Code ; retour de la voix sous forme de conversations V3 en temps réel et en streaming ; stabilisation de l’expérience multi-agent v2 facultative ; historique paginé expérimental des threads et connexion à Amazon Bedrock ; migration des sélections GPT-5.4 intégrées vers GPT-5.6 Terra et Luna. La v0.144.6 a défini les fenêtres de contexte de GPT-5.6 à 272 000 jetons.¹¹¹¹¹²
• v0.140.0 (15 juin) : /usage, codex delete et /delete, /import depuis Claude Code, menu unifié des mentions @, authentification Amazon Bedrock par clé API, et stockage local chiffré des identifiants OAuth de la CLI et de MCP ; les anciennes commandes vocales /realtime ont été supprimées.¹⁰²
• v0.139.0 (9 juin) : le mode code peut appeler directement la recherche web, les schémas d’outils conservent oneOf/allOf, codex doctor fournit des informations sur l’éditeur et le paginateur, et les sources des marketplaces apparaissent dans la sortie JSON.¹⁶⁵
• v0.138.0 (8 juin) : /app transfère une session de la CLI à l’application de bureau, et le texte des tâches envoyées du parent au sous-agent est chiffré dans multi-agent v2.¹⁶⁶¹⁰⁸
• v0.137.0 (4 juin) : multi-agent v2, raccourcis TUI F13-F24 et extension v1 des skills.¹⁶⁷
• De la v0.132.0 à la v0.135.0 (20-28 mai) : recherche dans l’historique local des conversations, --profile comme sélecteur principal de profil, objectifs activés par défaut, héritage des profils d’autorisation et requirements.toml géré, démarrage et arrêt de codex remote-control, versions enrichies de codex doctor et /status, objets textuels Vim, profils d’autorisation nommés dans /permissions, authentification des Python SDK et préréglages Sandbox, ainsi que codex exec resume --output-schema. La mise à jour de l’application du 21 mai a ajouté Appshots, la disponibilité générale du mode Goal et Computer Use verrouillé en option.^{96979899100101176}

L’ancien --full-auto est supprimé depuis la v0.147.0, et js_repl reste supprimé.^86878991116

Remarque sur la stabilité : surfaces stables et documentées : la CLI principale et la TUI, le sandbox et les politiques d’approbation, config.toml, AGENTS.md, les skills, hooks, plugins, outils multi-agent, objectifs, profils d’autorisation, /voice et les worktrees gérés (par défaut depuis la v0.156.0), ainsi que la transcription en plein écran et le démarrage automatique du serveur en arrière-plan (par défaut depuis la v0.157.0). Browser, Computer Use et Appshots sont des surfaces documentées destinées aux utilisateurs, dont la disponibilité dépend de la plateforme et de l’offre. Fonctionnalités expérimentales ou en cours de développement : Codex Cloud, le mode code, la gestion expérimentale du contexte, Memory v2, le tableau local de messages des agents et tout ce qui porte la mention [EXPERIMENTAL] dans ce guide ou figure sous /experimental ; ces éléments peuvent changer d’une version à l’autre. Éléments supprimés : --full-auto (v0.147.0), la politique d’approbation untrusted (v0.149.0), codex mcp-server (v0.154.0) et js_repl.

Canal alpha : les builds alpha sont publiés plusieurs fois par jour, les corps de version des branches alpha sont rudimentaires et des builds hors cycle issus de bases plus anciennes apparaissent régulièrement (les plus récents : 0.155.0-alpha.16.4, 0.157.0-alpha.11.1, 0.158.0-alpha.15.1 et 0.158.0-alpha.2.1). À au moins deux reprises, la balise npm alpha a désigné l’un d’eux ; @alpha installait donc un build plus ancien que latest. La branche 0.158 est passée de la 0.158.0-alpha.2 (23 septembre) à l’alpha.15 (25 septembre) sans version stable ; le 25 septembre, la balise alpha a basculé vers la branche 0.159, qui en est à la version 0.159.0-alpha.4. Si vous suivez les versions alpha, consultez npm view @openai/codex dist-tags et installez une version exacte plutôt que @alpha.¹⁷²¹⁷⁵ Un historique daté montrant comment les branches alpha récentes ont abouti aux versions stables figure dans ¹⁷³.

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 cet outil. Le système fonctionne sur cinq interfaces reposant sur une couche d’intelligence commune :

┌─────────────────────────────────────────────────────────┐
│                    CODEX SURFACES                       │
├─────────────────────────────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐   │
│  │   CLI    │  │ Desktop  │  │   IDE    │  │ Cloud  │   │
│  │ Terminal │  │   App    │  │Extension │  │  Tasks │   │
│  └──────────┘  └──────────┘  └──────────┘  └────────┘   │
│  Local exec     Multi-task    Editor-native  Async      │
│  + scripting    + worktrees   + inline edits detached   │
│  ┌──────────┐                                           │
│  │ Browser  │  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 (on-request → 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 alimente l’ensemble du système. Au 23 septembre 2026, la génération actuelle est GPT-6 : gpt-6-sol pour les tâches de programmation quotidiennes et complexes, gpt-6-astra pour les travaux de bout en bout les plus difficiles (ainsi que comme modèle par défaut intégré à CLI lorsqu’aucun modèle n’est configuré) et gpt-6-luna pour les tâches ciblées à grand volume. Les modèles GPT-5.6 (Sol, Terra, Luna) restent disponibles pendant le déploiement ; gpt-5.5 (contexte de 400K dans Codex, 1M dans le API) sera retiré de Codex pour les connexions avec ChatGPT le 14 octobre 2026, tandis que gpt-5.4 a été retiré de Codex le 31 août 2026.^{83117146148149171} Cette couche lit les fichiers, écrit des correctifs, exécute des commandes shell et raisonne sur votre base de code. Lorsque le contexte est plein, 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. Sous 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étermine ensuite quand 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 applications se connectent aux connecteurs ChatGPT. La recherche web apporte du contexte en temps réel depuis Internet.

Couche d’interface : CLI s’adresse aux utilisateurs avancés du terminal et à l’automatisation. L’application de bureau permet une gestion de projets multithread. L’extension IDE prend en charge les cycles modification-compilation-test. Cloud permet d’exécuter des tâches asynchrones de manière indépendante.

L’idée essentielle : la plupart des utilisateurs n’emploient qu’une seule interface. Les utilisateurs avancés utilisent les cinq : Cloud pour les tâches de longue durée, CLI pour les opérations déterministes sur les dépôts, l’extension IDE pour les cycles de développement courts, l’application de bureau pour la planification et la coordination, et l’extension de navigateur pour les workflows nécessitant une connexion dans le navigateur.

Table des matières

1. Comment installer Codex ?
2. Démarrage rapide : votre première session
3. Principales interfaces d’interaction
4. Exploration approfondie du système de configuration
5. Quel modèle choisir ?
6. Combien coûte Codex ?
7. Cadres de décision
8. Comment fonctionnent le sandbox et le système d’approbation ?
9. Comment fonctionne AGENTS.md ?
10. Hooks
11. Qu’est-ce que MCP (Model Context Protocol) ?
12. Mode Code
13. Environnement d’exécution REPL JavaScript
14. Que sont les skills ?
15. Plugins
16. Mode Plan 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 diagnostiquer les problèmes ? – notamment codex doctor
26. Déploiement en entreprise
27. Bonnes pratiques et anti-patterns
28. Recettes de workflows
29. Guide de migration
30. Fiche 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 intègre une commande de mise à jour automatique ; toutes les autres opérations passent par le gestionnaire de paquets utilisé pour l’installation.⁸⁶ Depuis la v0.146.0, les artefacts de version, les métadonnées des canaux et les alias des programmes d’installation sont distribués 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 d’OpenAI — grâce à cette solution de repli, une omission dans la liste d’autorisation entraîne une dégradation discrète plutôt qu’un échec manifeste.

# Check what you are running
codex --version                          # -> codex-cli 0.157.1
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 solution lorsqu’une mise à jour provoque des problèmes. Codex suit un cycle de versions stables rapide ; par conséquent, installer une version précise constitue le moyen le plus rapide de revenir en arrière — signalez le problème, épinglez la version et poursuivez votre travail. Vérifiez le retour à la version précédente avec codex --version, car une seconde installation masquée dans votre PATH continuera silencieusement à fournir l’ancien binaire (codex doctor signale précisément ce problème sous Environment).

La désinstallation du paquet ne supprime pas vos données. L’authentification, la configuration et l’historique des sessions se trouvent dans ~/.codex/. Conservez ce dossier pour préserver les connexions et l’historique lors d’une réinstallation ; supprimez-le uniquement pour repartir réellement de zéro — rm -rf ~/.codex efface également config.toml, auth.json et toutes les sessions enregistrées.

Script d’installation directe (v0.106.0+)

Pour macOS et Linux, un script d’installation en une ligne est disponible comme 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 binaire approprié et l’ajoute à votre PATH.

Téléchargement des binaires

Pour les environnements sans npm ni Homebrew, téléchargez les binaires propres à chaque plateforme depuis les versions de GitHub¹ :

Configuration 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 (sorti du statut expérimental 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 modes d’authentification :

1. Compte ChatGPT (recommandé) : connectez-vous avec votre abonnement Plus, Pro, Team, Business, Edu ou Enterprise existant. Accès à toutes les fonctionnalités, y compris les tâches cloud.
2. Clé API : définissez-la à l’aide de la variable d’environnement CODEX_API_KEY ou de codex login --with-api-key. Certaines fonctionnalités, comme les fils de discussion cloud, peuvent être indisponibles.

Conseil d’expert : le stockage des identifiants peut être configuré avec cli_auth_credentials_store dans config.toml. Options : file (par défaut), keyring (trousseau du système d’exploitation) ou auto (trousseau s’il est disponible, fichier comme solution de repli).

Connexion à Amazon Bedrock (v0.145.0, expérimentale) : les équipes dont l’accès aux modèles passe par Amazon Bedrock disposent d’un mode de connexion expérimental prenant en charge un endpoint personnalisé et l’authentification, 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 Fournisseurs de modèles personnalisés). GPT-5.6 Sol est le modèle Bedrock par défaut.¹¹² La v0.150.0 corrige la compression des conversations et la compatibilité multi-agent pour les modèles Amazon Bedrock.¹³² La v0.151.0 ajoute une option Amazon Bedrock soumise à un feature flag dans les parcours de connexion TUI admissibles : l’intégration détecte les profils AWS et les identifiants d’environnement existants, propose une configuration manuelle pour les profils, les clés d’accès, les variables d’environnement et les clés API Bedrock, demande la région AWS, masque les secrets lors de leur saisie et redémarre le serveur intégré lorsque le fournisseur change.¹³⁵ La v0.152.0 affiche la progression de l’actualisation des identifiants : la TUI et codex exec indiquent la progression pendant qu’un fournisseur de modèles actualise des identifiants expirés, y compris lors de la réauthentification d’une session Amazon Bedrock. Ce mécanisme s’appuie sur les notifications stables modelProvider/authRecoveryStarted et modelProvider/authRecoveryCompleted de l’app-server, qui transmettent le fil de discussion, le tour, le fournisseur et un message destiné à l’utilisateur.¹³⁸

Complétion 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.157.1

Démarrage rapide : votre première session

Passez de zéro à une utilisation productive en 5 minutes.

1. Installez Codex 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

La TUI interactive s’affiche. Codex lit automatiquement la structure de votre projet.

4. Posez une question :

> What does this project do? Summarize the architecture.

Codex lit les fichiers essentiels et explique la base de code. Une question comme celle-ci n’entraîne aucune modification — Codex ne corrige les fichiers que lorsque vous demandez un changement, tandis que le sandbox et la politique d’approbation déterminent les cas dans lesquels il doit d’abord solliciter votre accord.

5. Effectuez une modification :

> Add input validation to the login endpoint

Codex propose les modifications sous forme de diff. Examinez-les et approuvez-les avec y, ou refusez-les 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 ce plan, puis approuvez-le pour lancer l’exécution.

7. Vérifiez votre travail :

> /diff

Consultez toutes les modifications apportées par Codex pendant la session en cours.

Pour aller plus loin : - Configurez AGENTS.md avec les instructions du projet (voir Comment fonctionne AGENTS.md ?) - Configurez un profil adapté à votre workflow (voir Profils) - Essayez codex exec pour l’automatisation non interactive (voir Mode non interactif)

Principales interfaces d’interaction

Codex propose cinq interfaces distinctes reposant sur la même intelligence. Chacune est optimisée pour un type de workflow différent.

1. CLI interactif (interface utilisateur de terminal)

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

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

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

Principaux raccourcis TUI :

Modification de la ligne d’état (v0.121.0) : l’ancienne jauge de fenêtre de contexte dans la ligne d’état a été remplacée par un indicateur de pourcentage du contexte, qui montre le niveau de remplissage de votre fenêtre de contexte. Si des scripts ou des hooks analysent la ligne d’état, tenez compte de ce changement de format.⁸² Codex affichera également une annonce de mise à jour de CLI lorsqu’une nouvelle version sera disponible.

Slash commands disponibles dans la TUI :

Refonte du sélecteur de workflow (v0.129.0) : la reprise et la création de forks sont désormais plus faciles d’accès depuis un sélecteur repensé. Un nouveau mode de défilement brut vous permet en outre de parcourir la transcription sans rendu lorsque vous devez copier mot pour mot des commandes ou la sortie du modèle. Pratique pour analyser une longue session de débogage ou transmettre la sortie à un autre outil.⁸⁹

Menu unifié des mentions @ (v0.140.0) : saisir @ dans la zone de saisie ouvre désormais par défaut un menu unique de mentions regroupant fichiers, plugins et skills, en remplacement du flux qui permettait uniquement de joindre des fichiers — une seule touche suffit 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 fonctionnalités dont le CLI ne dispose pas :

• Multitâche : exécutez simultanément plusieurs agents en parallèle sur différents projets
• Isolation par worktree git : chaque fil travaille sur une copie isolée de votre dépôt
• Revue du diff intégrée : indexez, annulez et commitez les modifications sans quitter l’application
• Terminal intégré : un terminal propre à chaque fil pour exécuter des commandes
• Création de forks de conversation : créez des branches de conversation afin d’explorer différentes possibilités
• Fenêtres flottantes détachables : détachez les conversations dans des fenêtres déplaçables
• Automatisations : planifiez des tâches récurrentes (tri des issues, surveillance de la CI, réponse aux alertes)
• Appshots : joignez à un fil la fenêtre 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 des zones, puis laissez Codex traiter ces retours visuels précis
• Computer Use : laissez Codex piloter les applications Mac autorisées pour des tâches graphiques délimitées ; l’utilisation verrouillée est proposée sur activation pour les tours Computer Use éligibles sur Mac distant

ChatGPT Voice, optimisé par GPT-Live (desktop 26.715, 23 juillet 2026) : l’application de bureau peut désormais être pilotée à la voix — discutez de votre travail et coordonnez vos tâches dans Chat, Work et Codex sans saisir de texte. Sur macOS, l’activation de Screen context partage avec la conversation un appshot de la fenêtre au premier plan : vous pouvez ainsi poser des questions sur ce que vous regardez au lieu de le décrire. Disponible avec les forfaits Plus, Pro, Business, Edu et Enterprise, dans l’application de bureau et via Remote sur iOS. Il s’agit de la fonctionnalité vocale de l’interface de bureau. Le CLI possède ses propres fonctionnalités vocales distinctes : les conversations en direct /voice dans la TUI (activées par défaut depuis la v0.156.0) et la dictée avec la barre d’espace (ajoutée à titre expérimental dans la v0.105.0).¹¹³¹⁶⁹

Instantanés partagés des fils (20 août 2026) : avec tous les forfaits Codex, l’application de bureau macOS permet de partager un instantané en lecture seule d’un fil Codex local. L’instantané n’est pas actualisé lorsque le fil d’origine change ; les liens de comptes personnels sont accessibles à toute personne disposant du lien, tandis que les liens de comptes d’espace de travail sont réservés aux membres de l’espace d’origine. Codex masque les motifs de secrets connus avant le partage, mais OpenAI vous demande de vérifier le contenu partagé, car des informations sensibles peuvent subsister. Consultez ou révoquez les liens dans les contrôles des données ChatGPT, sous Shared links.¹²⁸

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 revue visuelle du diff. Utilisez le CLI lorsque vous recherchez la composabilité du terminal, l’écriture de scripts ou l’intégration CI/CD.

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

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

• Mode agent par défaut : lit les fichiers, effectue des modifications et exécute des commandes
• Modifications intégrées : suggestions tenant compte du contexte dans vos fichiers actifs
• Sessions partagées : synchronisation des sessions 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 de 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 :

• Lancer et oublier : placez dans la file d’attente des tâches qui s’exécutent indépendamment de votre machine locale
• Exécution parallèle : exécutez plusieurs tâches cloud simultanément
• Création de PR : Codex crée des pull requests à partir du travail terminé
• Application locale : récupérez les résultats du 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. Extension de navigateur (Chrome, Edge, Brave, Opera, Vivaldi)

Codex est proposé sous forme d’extension pour Google Chrome, Microsoft Edge, Brave, Opera et Vivaldi, ajoutant une cinquième interface aux côtés du CLI, de l’application de bureau, de l’extension IDE et du cloud. L’extension a été lancée pour Chrome en mai 2026 ; le changelog du 25 août 2026 a ajouté les quatre autres navigateurs, avec une configuration depuis Settings > Computer Use dans l’application de bureau ChatGPT. Tous les cinq prennent en charge les mentions d’onglets et le contrôle du navigateur ; Opera ne prend pas en charge les conversations latérales, vous devez donc démarrer ses tâches depuis l’application de bureau. L’extension est conçue pour accompagner votre navigation habituelle sans en prendre le contrôle : Codex travaille en parallèle dans plusieurs onglets en arrière-plan, tandis que vous gardez la maîtrise des sites auxquels il accède.⁹⁰¹²⁷

• Exécution parallèle dans les onglets : Codex intervient simultanément dans plusieurs onglets sans verrouiller celui qui se trouve au premier plan.
• Contrôle par site : vous placez sur liste blanche les sites web avec lesquels Codex peut interagir ; par défaut, aucun accès n’est autorisé.
• Le navigateur comme espace de travail : l’extension convient particulièrement aux tâches liées aux applications et aux sites web où la page constitue 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 : l’extension de navigateur utilise la même intelligence GPT-5.x-Codex que les autres interfaces. Les conventions d’une configuration AGENTS.md ou de skills fonctionnant dans le CLI s’appliquent donc également au travail piloté depuis le navigateur.

Installez-la depuis la documentation de l’extension de navigateur, la page auparavant intitulée Codex for 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é la plus élevée) : flags CLI (--model, --sandbox, --ask-for-approval, --search, --enable/--disable, --profile) et remplacements -c key=value
2. Configuration du projet (.codex/config.toml, recherchée depuis le CWD en remontant jusqu’à la racine du projet ; le dossier le plus proche l’emporte)
3. Configuration utilisateur ($CODEX_HOME/config.toml, 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é la plus faible)

requirements.toml agit comme une couche de contraintes de stratégie 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 dossier ~/.codex par défaut. Pratique pour les environnements CI/CD ou les configurations à plusieurs comptes.

Projets Desktop comprenant plusieurs dossiers (26.715, 23 juillet 2026) : un projet local dans l’application de bureau ChatGPT peut désormais regrouper plusieurs dossiers associés, dont l’un est désigné comme dossier principal (menu du projet → Modifier le projet). La détection automatique de config.toml s’effectue uniquement dans le dossier principal ; les dossiers secondaires restent disponibles pour la recherche, la lecture et la modification de fichiers, mais ne fournissent aucune configuration. Un fichier .codex/config.toml placé dans un dossier secondaire est un fichier que Codex peut lire, et non une configuration qu’il charge. Il s’agit d’une règle de portée des projets propre à l’application de bureau, et non d’une modification des règles de priorité ci-dessus : CLI détermine toujours la configuration du projet en remontant depuis le dossier de travail actuel.¹¹³

Référence complète de la configuration

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

# ─── Model Selection ───────────────────────────────────
model = "gpt-6-sol"                    # Docs' example default; unset = bundled default (gpt-6-astra)
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-6-sol"             # 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"          # on-request|never (untrusted retired in v0.149.0)

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

# ─── Tools ─────────────────────────────────────────────
tools.update_plan.enabled = false       # Planning tool opt-in (v0.152.0); exposes update_plan when true

# ─── 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 (global; per-tool MCP overrides in v0.152.0)
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             # Browser-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-command network proxy (experimental); boolean or table, see below
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

features.network_proxy accepte le type boolean | table. La forme booléenne se contente de démarrer ou d’arrêter le proxy ; la forme tableau contient la stratégie. Ce proxy applique les règles de domaine du profil d’autorisations aux commandes exécutées dans la sandbox : lorsqu’il est désactivé, les règles de domaine [permissions.<name>.network] ne sont pas appliquées et l’accès réseau des commandes est direct. Il ne filtre ni la recherche web, ni les applications, ni les serveurs MCP, ni les autres outils hébergés.¹³⁰

[features.network_proxy]
enabled = true
allow_local_binding = false
proxy_url = "http://127.0.0.1:3128"

[features.network_proxy.domains]
"api.github.com" = "allow"
"*.npmjs.org" = "allow"          # subdomains only
"**.example.com" = "deny"        # apex plus subdomains; deny wins on conflicts

Les exigences experimental_network gérées par l’administrateur dans requirements.toml peuvent démarrer le proxy sans features.network_proxy.¹³⁰

Profils

Préréglages de configuration nommés adaptés à différents modes de travail. Depuis Codex 0.134.0, chaque profil dispose de son propre fichier — ~/.codex/<name>.config.toml, qui contient uniquement des clés de premier niveau — et --profile <name> superpose ce fichier à ~/.codex/config.toml. Les anciennes tables [profiles.<name>] dans config.toml et le sélecteur de premier niveau profile = "<name>" ne sont plus lus ; si une table [profiles.<name>] subsiste, --profile <name> refuse de démarrer tant que vous n’avez pas déplacé ses clés dans le fichier du profil.¹²²

# ~/.codex/fast.config.toml
model = "gpt-6-luna"
# GPT-6 Sol/Luna start on the Fast tier (2.5x credits) unless service_tier is set; check /fast status
model_reasoning_effort = "low"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
personality = "pragmatic"

# ~/.codex/careful.config.toml
model = "gpt-6-astra"
model_reasoning_effort = "xhigh"
approval_policy = "on-request"   # `untrusted` retired in v0.149.0
sandbox_mode = "read-only"

# ~/.codex/auto.config.toml
model = "gpt-6-sol"
# GPT-6 Sol/Luna start on the Fast tier (2.5x credits) unless service_tier is set; check /fast status
model_reasoning_effort = "medium"
approval_policy = "never"
sandbox_mode = "workspace-write"

Un fichier de profil constitue une couche située au-dessus de votre configuration utilisateur de base et en dessous des configurations du projet et de CLI. Il ne doit donc contenir que les valeurs qui diffèrent de votre configuration de base.¹²²

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 une session donnée 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é abandonné pour les modèles hébergés par OpenAI, qui a 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 le flag --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 (septembre 2026)

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

GPT-5.5 sera retiré de Codex pour les connexions avec ChatGPT le 14 octobre 2026 – la documentation des modèles limite ce retrait à ChatGPT, ChatGPT Work et Codex pour toutes les offres (y compris grand public, Business, Enterprise et Edu) et précise qu’il ne concerne pas API d’OpenAI.¹⁵⁵ Les recommandations de remplacement ont changé avec le lancement de GPT-6 : avec Plus, Pro, Business, Enterprise et Edu, choisissez gpt-6-sol ; avec Free et Go, choisissez gpt-6-luna dans l’application de bureau, dans les deux cas « lorsqu’il est disponible ». Remplacez gpt-5.5 dans les valeurs par défaut des espaces de travail, les paramètres de modèle enregistrés, les configurations administrées, les agents personnalisés, les tâches planifiées et les scripts.¹⁷¹

GPT-5.4 et GPT-5.4 mini ont été retirés de Codex pour les connexions avec ChatGPT le 31 août 2026.¹¹⁷ La documentation des modèles désigne désormais gpt-6-sol et gpt-6-luna comme leurs remplaçants (dans Enterprise et Edu, un administrateur doit d’abord activer Luna) ; l’utilisation avec une clé API n’est pas affectée.⁶⁴¹⁷¹ La liste exacte des modèles varie selon le compte et le stade du déploiement. Vérifiez votre cache local : ~/.codex/models_cache.json.

Remarque sur l’obsolescence (11 mars 2026) : les modèles GPT-5.1 ne sont plus disponibles dans ChatGPT. Les conversations existantes se poursuivent 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.⁷¹⁸⁸

Remarque sur l’offre gratuite (5 mai 2026) : GPT-5.5 Instant a été déployé dans l’offre gratuite de ChatGPT le 5 mai 2026. Cela élargit l’audience de la famille GPT-5.5 au-delà des offres payantes, même si l’accès à Codex CLI continue d’exiger 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, dotée d’un contexte de 400K pour 0,75 $/4,50 $ par MTok — elle n’utilise que 30 % du quota de GPT-5.4. Idéale pour déléguer à des sous-agents : confiez la planification et la coordination à GPT-5.4, tandis 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, examen 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 native de trois variantes du modèle GPT-5.6 hébergées sur Amazon Bedrock, notamment du niveau d’effort de raisonnement max. Pour les équipes dont l’accès aux modèles passe par un fournisseur Bedrock, elles se sélectionnent de la même manière que les autres modèles de fournisseurs personnalisés (consultez Fournisseurs de modèles personnalisés) ; le niveau d’effort max vise les charges de raisonnement et agentiques les plus difficiles.¹⁰⁶ La v0.144.6 (18 juillet 2026) a actualisé les instructions intégrées de Sol, Terra et Luna et corrigé leurs fenêtres de contexte à 272 000 tokens.¹¹¹ La v0.145.0 (21 juillet 2026) ajoute une connexion expérimentale à Bedrock avec prise en charge des points de terminaison et de l’authentification personnalisés, fait de GPT-5.6 Sol le modèle Bedrock par défaut et migre les sélections intégrées de modèles GPT-5.4 vers les variantes Terra et Luna correspondantes.¹¹²

GPT-6-Astra (lancé le 3 septembre 2026 ; dans Codex via les v0.153.1 à v0.153.4) : voici la chronologie, avec les dates précises : la v0.153.1 a préparé une entrée de catalogue réservée à API le 3 septembre 2026 ; OpenAI a annoncé GPT-6-Astra le même jour ; et la v0.153.4 a ajouté l’entrée au sélecteur et fait basculer la valeur par défaut intégrée de CLI le 4 septembre. L’annonce décrit un déploiement progressif commençant par un nombre limité d’organisations (d’abord les partenaires du programme de cybersécurité), puis étendu à ChatGPT Plus, Pro, Business et Enterprise « au cours des prochains jours », ainsi qu’à API d’OpenAI et AWS – les informations sur le déploiement proviennent de la presse (CNBC, Axios, Forbes, Al Jazeera, 9to5Mac).¹⁴⁵ Dépassé depuis le 4 septembre : OpenAI a annoncé sur X que GPT-6 Astra « est désormais disponible pour tous les utilisateurs Pro, Enterprise et Business Premium dans ChatGPT Work et Codex » et « disponible dans API », tandis que Plus et Business étaient attendus dans les jours suivants ; le responsable de Codex, Tibo Sottiaux, a ajouté le soir même : « Astra est désormais aussi déployé auprès de tous les utilisateurs Plus et Business. » Dans la pratique, les droits d’accès restent inégaux – des témoignages publiés par la communauté le 5 septembre montrent que certains comptes Plus ne voient encore que les modèles GPT-5.6 dans Codex – et la ligne sur la disponibilité dans la documentation des modèles citée ci-dessous reste inchangée : elle demeure donc la référence officielle applicable.¹⁴⁹ La documentation officielle est disponible : la page du modèle API présente gpt-6-astra comme le modèle phare, « Notre modèle le plus performant, conçu pour les travaux de bout en bout les plus difficiles » – 10 $/MTok en entrée, 50 $/MTok en sortie aux tarifs standard de contexte court, une fenêtre de contexte de 1,05M tokens avec un maximum de 922 000 tokens d’entrée, une sortie maximale de 128K et des connaissances arrêtées au 30 avril 2026 – avec un niveau documenté pour les contextes longs : les invites dépassant 272K tokens d’entrée sont facturées 2 fois le tarif d’entrée et 1,5 fois le tarif de sortie pour l’intégralité de la requête, soit 20 $/MTok en entrée et 75 $/MTok en sortie sur la page des tarifs – au-dessus de GPT-5.6 Terra (équilibré) et Luna (économique). La documentation Codex présente Astra comme le modèle Codex recommandé, avec une disponibilité qui « dépend du déploiement, de votre méthode de connexion et de votre client » et une éligibilité mentionnée pour les comptes Pro, Business (100 $) et Enterprise. L’échelle de raisonnement Codex documentée pour Astra est la suivante : Low, Medium, High, Extra High, Max, Ultra – la page des modèles de la documentation indique Medium comme valeur par défaut, tandis que le catalogue intégré de la v0.153.4 définit default_reasoning_level sur low ; considérez donc que la valeur par défaut effective dépend de l’interface et vérifiez /status dans une session. L’échelle reste inchangée lors de la nouvelle vérification du 15 septembre, avec désormais des descriptions pour chaque niveau du sélecteur (Ultra, verbatim : « Maximum reasoning with automatic task delegation »), et les niveaux Max et Ultra sont confirmés par SDK – la version 0.154.0 de Python SDK (10 septembre 2026) ajoute les valeurs d’effort de raisonnement max et ultra (#39662).^146148153 Dans CLI, Astra est configurable via API depuis la v0.153.1 (-m gpt-6-astra), rejoint les catalogues Amazon Bedrock dans la v0.153.3 (GPT-5.6 Sol est resté le modèle Bedrock par défaut jusqu’à son remplacement par GPT-6 Sol dans la v0.157.0¹⁷⁴) et figure dans le sélecteur de modèles ainsi que comme modèle intégré par défaut lorsqu’aucun modèle n’est explicitement configuré depuis la v0.153.4 – aucune version minimale de CLI n’étant documentée, considérez ces versions comme les seuils effectifs. Ce changement de modèle par défaut relève du catalogue intégré de CLI, pas de toutes les interfaces – même si l’écart avec le cloud s’est depuis résorbé : les vérifications des 4 et 7 septembre indiquaient qu’Astra n’était pas disponible pour Codex cloud (GPT-5.6 Sol l’était), tandis que celle du 15 septembre montre Astra comme également disponible pour Codex cloud dans la matrice de disponibilité ; la page précise toujours : « Actuellement, vous ne pouvez pas modifier le modèle par défaut des conversations Codex cloud. » Mise en garde concernant le déploiement : les droits d’accès varient selon le compte et, avec CLI 0.153.4+, un compte encore hors déploiement dispose d’un modèle intégré par défaut qu’il ne peut pas utiliser – épinglez un modèle dans config.toml (ou transmettez -m) pour garantir une sélection déterministe ; depuis la v0.156.1, l’exemple de la documentation utilise model = "gpt-6-sol". La facturation du mode Fast d’Astra est documentée, même si la page des modèles ne mentionne aucun niveau Fast : la documentation sur la vitesse de Codex la fixe à 2,5 fois les crédits Standard avec une connexion ChatGPT (« lorsqu’il est disponible »), tandis que la page de tarification de API indique pour le mode Fast des tarifs exactement 2 fois supérieurs aux tarifs Standard applicables (20 $/100 $ par MTok pour un contexte court, 40 $/150 $ pour un contexte long). La mention « 2x speed » dans la chaîne du catalogue de la v0.153.2 reste uniquement un texte affiché par le catalogue – la page consacrée à la vitesse ne précise aucun multiplicateur de vitesse pour Astra.^145146147148 Partiellement dépassé depuis le 23 septembre 2026 : la documentation des modèles ne présente plus Astra comme le modèle Codex recommandé. Sa section « Recommended models » commence désormais par GPT-6 Sol et Luna, réserve Astra aux « travaux de bout en bout les plus difficiles », indique qu’Astra n’est pas disponible pour Codex cloud et donne Light (low) comme effort initial pour Astra, ce qui correspond au catalogue intégré. Astra reste le modèle intégré par défaut de CLI lorsqu’aucun modèle n’est configuré.¹⁷¹

Préréglages Power avec Astra (ajout à la documentation, au plus tard le 6 septembre 2026) : le passage de la documentation des modèles Codex consacré au sélecteur de modèles associe désormais les options Power du sélecteur aux niveaux de raisonnement de GPT-6-Astra – il s’agit de la première correspondance documentée entre les préréglages Power et Astra – dans un paragraphe absent lors de la nouvelle vérification du 5 septembre dans ¹⁴⁶ et dont la présence a été confirmée le 7 septembre. Verbatim : « For eligible Pro, Business ($100), and Enterprise accounts, the Astra rollout updates the Power options to Terra Light, Sol Light, Sol Medium, Astra Light, Astra Medium, and Astra Extra High. Options can differ by plan and rollout stage. » La phrase précédente de la documentation précise que les illustrations du sélecteur montrent encore les commandes de GPT-5.6. À lire conjointement avec le tableau des modèles ci-dessus : « Power » désignait GPT-5.6 Sol avec un raisonnement medium ; sur un compte disposant des droits requis, la même échelle de préréglages couvre désormais Terra, Sol et Astra avec des niveaux de raisonnement fixes, et les options continuent de dépendre de l’offre et du stade du déploiement. Le paragraphe reste inchangé mot pour mot lors de la nouvelle vérification du 15 septembre 2026.¹⁴⁶ Mise à jour du 23 septembre 2026 : après le lancement de GPT-6 Sol et Luna, la documentation énumère les six préréglages Power comme suit : « Luna High, Sol Light (le préréglage initial), Sol Medium, Astra Light, Astra Medium et Astra Extra High ». Elle précise que certaines offres payantes n’incluent pas Astra Extra High et suggère de commencer par Medium pour Sol, High pour Luna et Light (low) pour Astra.¹⁷¹

Remarques expérimentales intercontextes (Astra, publiées dans la documentation, sur inscription volontaire) : la page de documentation des modèles Codex comporte une section intitulée « Experimental context management », verbatim : « On supported Codex clients, users signed in with ChatGPT Plus or Pro can opt in to experimental context management. Astra keeps notes across context windows and can search earlier messages and tool results from the same task. This experiment is off by default and isn’t available with Business, Enterprise, or API-key sign-in at launch. » Le mécanisme d’activation volontaire est décrit ainsi, verbatim : « To opt in, set features.context_management.experimental_mode = true in your config.toml, then start a new task. » Il s’agit de la même interface features.context_management.experimental_mode introduite dans la v0.153.0 (consultez Gestion du contexte) – la page de documentation l’associe désormais explicitement à Astra et aux connexions Plus et Pro, alors que les notes de publication de la v0.153.0 mentionnaient les sessions Plus, Pro et Pro Lite éligibles. La v0.154.0 renforce les contrôles côté code : l’éligibilité à l’expérience dépend désormais des capacités du modèle actif au démarrage de la session (#43147). La section de la documentation reste inchangée mot pour mot lors de la nouvelle vérification du 15 septembre 2026. Cette fonctionnalité est expérimentale et désactivée par défaut ; attendez-vous à ce que son comportement et ses critères d’éligibilité évoluent.^140146152 v0.157.0 : le catalogue intégré des modèles n’indique plus que GPT-6-Astra, ni aucun autre modèle intégré, prend en charge le contexte expérimental (#47397), et CLI n’active l’expérience que pour un modèle ainsi marqué. Avec le catalogue intégré, l’activation n’a donc aucun effet ; rien n’indique si le catalogue fourni aux comptes connectés diffère. Au 26 septembre 2026, la documentation des modèles décrit toujours cette activation volontaire.¹⁷⁴

Arbre de décision pour choisir un modèle

Is this a quick fix, extraction, or other well-defined repeatable task?
├─ Yes → gpt-6-luna (most efficient; docs suggest starting at High)
└─ No
   ├─ Do you need real-time pairing speed?
   │  ├─ Yes → gpt-5.3-codex-spark (near-instant, Pro only)
   │  └─ No
   │     ├─ Hardest end-to-end work across many steps and tools?
   │     │  ├─ Yes → gpt-6-astra (strongest; bundled default when no model is set)
   │     │  └─ No → gpt-6-sol (everyday and complex coding; start at Medium)
   └─ GPT-6 not yet available on your account? → gpt-5.6-sol

Effort de raisonnement

Contrôlez le temps que le modèle consacre à « réfléchir » avant de répondre :

Les niveaux pris en charge dépendent du modèle. minimal n’est disponible que pour les modèles GPT-5. Tous les modèles ne prennent pas en charge tous les niveaux.

Détails sur persistent (v0.151.0) : les tours exécutés avec l’effort persistent activent par défaut le rappel de l’heure actuelle et l’outil interruptible clock.sleep (les paramètres explicites de features.current_time_reminder et les exigences administrées sont conservés), et incluent des instructions intégrées de proactivité et de suivi que les métadonnées du modèle peuvent remplacer ou désactiver via persistent_instructions.¹³⁵

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

Conseil d’expert : pour une même invite, le raisonnement xhigh peut consommer 3 à 5 fois plus de tokens que medium. Réservez-le aux problèmes réellement difficiles pour lesquels ce raisonnement supplémentaire est rentable.

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

Changement de modèle

Changez de modèle en cours de session avec la slash command /model, ou définissez-en un 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 également Sélection du modèle pour connaître les capacités et Cadres de décision pour choisir le modèle adapté à chaque tâche.

Accès via les offres ChatGPT

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

Mise à jour tarifaire d’avril 2026 : le tarif annuel de Business est passé de 25 à 20 $ par licence et par mois. Des licences Codex uniquement avec paiement à l’utilisation sont désormais proposées pour les espaces de travail Business et Enterprise : aucun frais de licence fixe, la facturation dépend de la consommation de tokens.⁷⁹ La page tarifaire présente désormais les limites sous forme de plages propres à chaque modèle (voir le tableau ci-dessus), et non plus les multiplicateurs promotionnels 2x du lancement de Codex Desktop App en février 2026.¹⁶¹⁶²

Relèvement des limites d’utilisation en mai 2026 (expiré le 31 mai 2026) : avec l’offre Plus, Codex bénéficiait d’une limite sur 5 heures multipliée par 25 (contre le multiplicateur standard de 20), tandis que le niveau à 100 $/mois voyait sa limite doubler pendant la même période.⁸⁹

Expérience utilisateur des limites d’utilisation dans la TUI (v0.152.0-v0.153.0) : atteindre une limite n’est plus une impasse. La v0.152.0 affiche au-dessus de la zone de saisie des bannières de limite d’utilisation proposant des actions concrètes – vérifier l’utilisation, gérer les crédits, réinitialiser les limites, avertir le propriétaire de l’espace de travail et gérer les offres – filtrées selon le compte et l’utilisateur authentifiés ; les données d’utilisation sont actualisées après une erreur de limite et, lorsque la bannière l’indique, Codex bascule vers le premier modèle de secours disponible sans modifier les autres paramètres du fil.¹³⁸ La v0.153.0 ajoute des avertissements plus précoces pour les offres Plus et Team : une alerte se déclenche lorsqu’il reste moins de la moitié de l’allocation dans une fenêtre d’utilisation d’environ 5 heures, tandis que les autres offres et durées de fenêtre conservent les seuils existants de 75 %, 90 % et 95 %.¹⁴⁰

Coût en crédits

Les opérations Codex consomment les crédits alloués à votre offre :

Ces tarifs correspondent à la vitesse Standard, et la page tarifaire indique que ceux de GPT-5.6 Sol, Terra et Luna « restent inchangés » après le lancement de GPT-6. En pratique, « l’utilisation de GPT-5.6 consomme en moyenne 5 à 30 crédits par message » (la page indiquait 5 à 40 lors de l’ouverture de l’accès en août) ; le mode Fast coûte 2,5 fois le tarif en crédits du mode Standard pour GPT-6 Astra, Sol et Luna « lorsqu’il est disponible », et le catalogue intégré fait de Fast le niveau par défaut de GPT-6 Sol et Luna dans la TUI, sauf si vous définissez service_tier. Vérifiez donc /fast status si vos crédits s’épuisent plus vite que prévu. La génération d’images consomme les limites incluses 3 à 5 fois plus vite que des interactions comparables uniquement textuelles.¹⁶²¹⁷¹

Les crédits des offres Enterprise et Edu évoluent selon l’allocation contractuelle. Consultez /status dans la TUI pour connaître votre utilisation actuelle.

Facturation API

Lorsque vous utilisez Codex via l’API, OpenAI facture l’utilisation par token selon le tarif OpenAI API standard du modèle sélectionné, avec les éventuelles remises applicables à la mise en cache des prompts. Tarifs API actuels pour 1 million de tokens : GPT-6 Sol, 2 $ en entrée / 10 $ en sortie ; GPT-6 Luna, 0,10 $ / 0,50 $ ; GPT-6 Astra, 10 $ / 50 $. Pour les trois modèles, les prompts dépassant 272 000 tokens d’entrée coûtent 2 fois plus cher en entrée et 1,5 fois plus cher en sortie pour l’ensemble de la requête, tandis que le mode Fast coûte 2 fois plus cher.¹⁴⁶¹⁷¹ Les multiplicateurs de crédits ChatGPT ne s’appliquent pas à la connexion par clé API. Consultez la page tarifaire officielle de l’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-6-luna et model_reasoning_effort = "low" pour les tâches courantes
2. Réservez le raisonnement approfondi : n’utilisez xhigh que pour les problèmes réellement difficiles, car il consomme 3 à 5 fois plus de tokens
3. Utilisez --ephemeral : désactivez la persistance des sessions en CI/CD afin de réduire la surcharge
4. Limitez les résumés de raisonnement : définissez model_reasoning_summary = "none" lorsque vous n’avez pas besoin d’explications
5. Regroupez les tâches avec le mode exec : codex exec évite la surcharge de la TUI pour les workflows d’automatisation
6. Surveillez l’utilisation : consultez /status dans la TUI ainsi que les tableaux de bord de facturation de votre organisation — depuis la v0.148.0, /status, les lignes d’état et les titres de terminal affichent une estimation des crédits ou du coût du fil pour les espaces de travail éligibles¹¹⁸

Exemples de coûts réels

Coûts API représentatifs pour des tâches courantes (instantané tarifaire de gpt-5.3-codex à la mi-2026, avec un raisonnement moyen — les proportions restent comparables 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 d’en réduire sensiblement le coût. Les tokens d’entrée mis en cache bénéficient d’un tarif réduit.

Surcoût caché en tokens

Chaque appel d’outil ajoute des tokens en plus de ceux de votre prompt visible :

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

Gestion des coûts en équipe

Stratégies de maîtrise des coûts en équipe : - Définissez requirements.toml pour imposer des limites de modèle et d’effort de raisonnement à l’échelle de l’organisation - Utilisez gpt-5.6-luna pour la CI/CD — les pipelines automatisés nécessitent rarement un raisonnement maximal - Budgétisation par profil — définissez des profils ci, review et dev avec des plafonds de coûts adaptés - Surveillez l’utilisation via OpenTelemetry — les déploiements Enterprise peuvent exporter les données télémétriques d’utilisation vers les plateformes d’observabilité existantes

Cadres décisionnels

Quand utiliser chaque interface

Quand utiliser chaque mode sandbox

Quand utiliser chaque niveau de raisonnement

Mode Plan ou 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 : Entrée ou Tab

Règle générale : Entrée = « arrêtez-vous, écoutez ceci maintenant ». Tab = « lorsque vous aurez terminé, faites également ceci ».

Application de bureau ou 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 choisir ?

Faites correspondre votre tâche à un profil préconfiguré :

Fichiers de profil (un par préréglage, dans ~/.codex/ ; l’ancienne structure à fichier unique profile = "default" + [profiles.*] n’est plus lue depuis la version 0.134.0¹²²) :

# ~/.codex/fast.config.toml
model = "gpt-6-luna"
# GPT-6 Sol/Luna start on the Fast tier (2.5x credits) unless service_tier is set; check /fast status
model_reasoning_effort = "low"

# ~/.codex/careful.config.toml
model = "gpt-6-astra"
model_reasoning_effort = "xhigh"

# ~/.codex/pair.config.toml
model = "gpt-5.3-codex-spark"
model_reasoning_effort = "high"

# ~/.codex/ci.config.toml
model = "gpt-6-luna"
# GPT-6 Sol/Luna start on the Fast tier (2.5x credits) unless service_tier is set; check /fast status
model_reasoning_effort = "low"
sandbox_mode = "workspace-write"

Changez de profil pour une 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 Déploiement en entreprise pour connaître les contraintes de requirements.toml que les administrateurs imposent à l’échelle de l’organisation.

Renforcement de la v0.148.0 : les restrictions du sandbox fonctionnent désormais en mode fermé en cas d’échec : un chemin refusé ou illisible est considéré comme bloqué au lieu d’être silencieusement autorisé, sous Linux comme sous Windows.¹¹⁸

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 propre à chaque plateforme :

• macOS : framework Seatbelt d’Apple via sandbox-exec, avec des profils propres à chaque mode compilés à l’exécution et appliqués par le noyau⁶. Depuis la v0.121.0, les profils sandbox macOS peuvent autoriser explicitement certains sockets Unix (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 de défense en profondeur.⁵ Bubblewrap (bwrap) est intégré et compilé dans le cadre du build Linux (il n’est plus facultatif depuis la v0.100.0)⁷. La v0.117.0 a amélioré la fiabilité du sandbox sur les anciennes distributions 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é en amont ; 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 fichiers binaires d’exécution de l’application de bureau, afin que le sandbox Windows puisse résoudre ces fichiers de manière fiable pour les utilisateurs d’un sandbox limité à l’espace de travail.⁹¹

Pourquoi est-ce important ? Contrairement à l’isolation fondée sur des conteneurs (Docker), celle assurée au niveau du système d’exploitation est plus rapide, plus légère 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 fork de zsh (v0.106.0) : correction d’une vulnérabilité permettant à l’exécution shell par fork de 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 par entrée 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 l’isolation au sein du conteneur. WSL2 est pris en charge ; WSL1 est explicitement refusé (Bubblewrap est incompatible avec la couche de compatibilité du noyau de WSL1).⁸² - Révision Guardian et hooks (v0.121.0) : les hooks sont désactivés pendant les sessions de révision Guardian afin que les hooks exécutés avant ou après les outils ne puissent pas influencer les décisions du sous-agent Guardian.⁸² Si vous comptez sur les hooks pour la journalisation ou la validation, sachez qu’une révision Guardian les ignore ; appuyez-vous sur l’observabilité de l’app server si vous avez besoin d’une piste d’audit complète. - Système de fichiers Linux /dev (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ériques.⁶¹

Politique ReadOnlyAccess (v0.100.0+) : une structure de politique configurable permettant de contrôler précisément les 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 sur la configuration d’OpenAI 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.⁸⁷

Depuis la v0.150.0, vous pouvez associer un raccourci clavier permettant de faire défiler les modes d’autorisation depuis la zone de saisie : configurez-le avec /keymap.¹³²

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 granulaires : 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 nécessite un accès dépassant le mode de sandbox actuel, Codex peut demander des autorisations supplémentaires précises plutôt qu’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 retenter la même commande

Demandes d’autorisations à 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 à 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.) par l’intermédiaire du processus d’approbation de la TUI, au lieu d’échouer silencieusement ou d’obliger l’utilisateur à redémarrer avec d’autres flags.

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

Les apps et connecteurs bénéficient d’un niveau d’approbation intermédiaire : le mode d’approbation des apps writes permet aux actions déclarées en lecture seule d’une app de s’exécuter sans confirmation, tout en continuant à suspendre celles qui écrivent.¹⁰⁷ Auparavant, les approbations des apps étaient davantage fondées sur le tout ou rien ; writes correspond au niveau de confiance réellement recherché par la plupart des opérateurs pour les intégrations : consulter librement, demander avant de modifier.

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

Le nouveau flag CLI --approve-for-me transforme les demandes d’approbation en approbations révisées automatiquement : au lieu de vous interrompre, chaque demande est évaluée lors d’une passe de révision, puis approuvée ou refusée en votre nom.¹¹⁶ Ce mécanisme se situe entre « tout approuver » (la posture autrefois encouragée par --full-auto, désormais supprimé) et « interrompre pour chaque action » : les demandes restent des points de décision, mais un réviseur y répond. Associez-le aux réglages d’auto-révision plus sûrs de la v0.146.1 pour les modèles dotés de capacités cyber, dont ce flag hérite. Traitez-le comme toute délégation d’autorité : il convient aux longues exécutions sans surveillance, où une interruption provoquerait un blocage, mais pas aux sessions qui touchent à des identifiants ou à l’état de production et pour lesquelles vous souhaitez assurer vous-même la révision.

Approbation des entrées envoyées à un terminal élevé (v0.151.0)

Le feature flag write_stdin_approval — désactivé par défaut — exige une nouvelle approbation avant l’envoi d’une entrée non vide à un terminal unified-exec élevé. Ces révisions transitent par les hooks, Guardian, l’app server et la TUI sous forme d’approbations writeStdin ; l’environnement du terminal, son dossier de lancement et son état d’élévation persistent d’un tour à l’autre, et l’identité du processus est de nouveau validée après l’approbation, avant l’écriture du moindre octet. L’action entièrement mise en forme et le motif de l’approbation doivent tenir dans 8 000 octets : les actions trop volumineuses ou tronquées sont refusées avant toute demande d’approbation ou tout envoi au terminal.¹³⁵

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

Les profils d’autorisation divisent les politiques de sandbox du système de fichiers et du réseau en 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 [permissions.<name>] personnalisée.⁸⁷ La v0.133.0 fait des profils une surface administrable : les listes de APIs exposent les métadonnées des profils disponibles, les profils peuvent hériter les uns des autres, un fichier requirements.toml administré peut déclarer des exigences d’autorisation, les profils actifs sont actualisés à l’exécution, et la configuration du sandbox Windows utilise désormais le profil résolu plutôt qu’une politique ad hoc 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 plutôt que d’élargir excessivement un profil.⁸⁷

v0.151.0 : les threads de l’app server restaurés conservent leurs profils d’autorisation au lieu d’être aplatis en anciens remplacements du sandbox par tour : les profils persistent lors du routage des tours et des changements de dossier compatibles effectués avec /cd. Une commande /cd qui ne peut pas représenter le profil restauré de manière sûre sous la forme d’un ancien mode de sandbox est refusée au lieu d’affaiblir silencieusement les restrictions.¹³⁴

Conseils concernant l’ancien --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 signalent --full-auto comme obsolète, et l’aide actuelle de CLI ne le mentionne plus pour les exécutions interactives. Utilisez plutôt les flags explicites ci-dessus ou un profil d’autorisation nommé.⁸⁶

La v0.147.0 achève la suppression : codex exec --full-auto n’existe plus. Un script qui transmet encore ce flag produit désormais une erreur au lieu de s’exécuter. La migration est mécanique : remplacez-le par --sandbox workspace-write (ainsi qu’un flag d’approbation ou un profil si votre ancienne invocation dépendait du comportement d’approbation de --full-auto). Auditez toute automatisation qui appelle codex exec par l’intermédiaire du shell avant d’effectuer la mise à niveau : 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 dépôts extraits par l’intermédiaire de 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 ; et la version intégrée de Bubblewrap passe à la 0.11.2, avec les correctifs de sécurité en amont. Aucune modification de configuration n’est nécessaire. Exécutez codex update pour en bénéficier.⁸⁹

Configurations recommandées

Développement quotidien (valeur par défaut sûre) :

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

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

sandbox_mode = "danger-full-access"
approval_policy = "on-request"   # `untrusted` retired in v0.149.0

Des articles de la communauté recommandent cette combinaison comme un « juste équilibre »⁸ ; comprenez ce qu’elle fait réellement avant de reprendre ce conseil : les demandes d’approbation apparaissent lorsqu’une commande doit sortir du sandbox ou accéder au réseau, tandis que danger-full-access supprime ces deux limites. Il ne reste donc presque plus rien à faire remonter par on-request. Il s’agit de capacités maximales avec un minimum de demandes, et non de capacités maximales assorties d’un contrôle humain pour chaque commande ; si vous recherchez ce dernier fonctionnement, conservez workspace-write et laissez la limite du sandbox déclencher les demandes.¹²³

Automatisation CI/CD :

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

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

Smart Approvals peut acheminer les demandes de révision vers un sous-agent Guardian au lieu d’exiger une approbation humaine pour chaque action. La session Guardian persiste entre les approbations afin de réutiliser le cache du prompt et d’éviter le coût du démarrage. Chaque révision bénéficie d’un historique vierge (les décisions précédentes ne se répercutent pas sur les révisions ultérieures).⁷³

Configurez le réviseur dans config.toml :

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

Cette approche est particulièrement utile pour les workflows CI/CD où vous souhaitez une révision automatisée et argumentée plutôt qu’un simple approval_policy = "never" appliqué sans discernement.

Inversion des valeurs par défaut de Guardian v2 (v0.151.0) : Guardian v2 utilise désormais par défaut des révisions de type computer-use avec des images. features.guardianv2.review_scope.computer_use_only vaut true par défaut — définissez-le sur false pour conserver le périmètre plus large de révision des outils — et features.guardianv2.transcript.include_images vaut true par défaut — définissez-le sur false pour exclure les images des transcriptions Guardian. Ces deux fonctionnalités ont été livrées dans la v0.150.0 sous forme de surfaces configurables désactivées par défaut ; c’est dans la v0.151.0 qu’elles ont été activées par défaut.¹³⁵

Le périmètre de Guardian suit le mode d’approbation (v0.153.0) : deux modes ignorent désormais les opérations Guardian qui ne peuvent pas changer le résultat. En mode Full Access (qui associe déjà approvalPolicy: "never" à des autorisations sans restriction), les demandes Guardian et MCP limitées à une confirmation sont approuvées sans révision synchrone, préchauffage de l’échantillonneur ni évaluation en arrière-plan : les environnements en attente, défaillants ou restreints ne sont pas considérés comme Full Access, et l’état actif des autorisations est réévalué à chaque tour afin qu’un thread existant puisse entrer en mode Full Access ou en sortir en toute sécurité. En mode d’approbation utilisateur (approvals_reviewer = "user"), le préchauffage de Guardian et l’évaluation asynchrone sont ignorés, tandis que les confirmations ordinaires d’exécution de node_repl.js sont acceptées automatiquement ; les vérifications d’actions sensibles et les demandes de saisie adressées à l’utilisateur conservent leur comportement existant.¹⁴⁰ Cela restreint les situations dans lesquelles Guardian s’exécute, et non la couche d’approbation humaine : le comportement de demande décrit dans ce guide pour danger-full-access sous on-request relève de la politique d’approbation, qui constitue un mécanisme distinct. La v0.152.1 permet en outre à la révision des approbations par Guardian d’obtenir sa politique Node REPL à partir des métadonnées du modèle (auto_review.node_repl_policy), avec repli sur la politique intégrée lorsque ce champ est absent.¹³⁹

L’évaluation computer-use de Guardian respecte les exigences du modèle (v0.153.1) : l’évaluation Guardian limitée à computer-use et les décisions d’approbation rapides ne s’exécutent désormais que lorsque le modèle actif définit node_repl_auto_review_required dans ses métadonnées. Les évaluations antérieures ou en cours sont invalidées lorsqu’un changement de modèle désactive l’évaluation ; revenir ensuite à un modèle révisé ne peut donc pas réactiver une ancienne décision d’approbation. Il s’agit du changement majeur du correctif v0.153.1, bien qu’il ne figure pas dans le corps des notes de version : le numéro #42422 (un cherry-pick de 38ba8cdc) ne peut être vérifié qu’en comparant rust-v0.153.0…rust-v0.153.1.¹⁴²

La réutilisation de la compaction parente par Guardian est activée par défaut (v0.156.0) : le numéro #46522 fait de guardian_reuse_parent_compaction une fonctionnalité stable et l’active par défaut, ce qui permet à Guardian de réutiliser la compaction chiffrée du thread parent lorsqu’il redémarre une session de révision. D’après les tests de la PR, les sessions de révision mises en cache sont toujours invalidées lorsque l’historique parent change. Pour rétablir le comportement précédent : définissez guardian_reuse_parent_compaction = false sous [features] dans config.toml, ou exécutez codex features disable guardian_reuse_parent_compaction.¹⁶⁹¹⁷¹

Le contexte du thread Guardian est activé par défaut (v0.157.0) : le numéro #47275 fait de guardianv2.thread_context une fonctionnalité stable et l’active pour les révisions Guardian synchrones et asynchrones, afin que celles-ci utilisent le contexte propre au thread. Ce réglage est indépendant de l’option enabled de Guardian v2, et les configurations explicites ainsi que les remplacements de profil sont conservés. Pour le désactiver : définissez thread_context = false sous [features.guardianv2] dans config.toml.¹⁷⁴

Durcissement du classificateur PowerShell (v0.142.2) : les commandes PowerShell qui contiennent 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 faille permettant à 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 est 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 au 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 l’intermédiaire d’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 respectés pour l’authentification, le téléchargement de plugins, l’autorisation MCP, l’exécution à distance, les connexions WebSocket, les redirections HTTP et les connexions à LM Studio : sept parcours qui, d’après le changelog, ignoraient auparavant le proxy.¹¹⁴ Si vous utilisiez Codex derrière un proxy d’entreprise avant la v0.146.0 et que les connexions ou les installations de plugins échouaient alors que les appels ordinaires aux modèles 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 réglages de proxy système, PAC et WPAD. Ainsi, les Mac d’entreprise dont la configuration de proxy est imposée par des profils n’ont plus besoin de variables d’environnement de proxy propres à chaque shell pour le trafic d’authentification.¹⁰⁵ Depuis la v0.143.0, cela s’étend à Windows et au trafic Responses API : Codex achemine les appels d’authentification et Responses API par l’intermédiaire du proxy système de macOS ou Windows, y compris l’autoconfiguration PAC et WPAD, ce qui comble la dernière lacune pour les réseaux d’entreprise verrouillés sur les 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 de refus d’autorisation lorsqu’un profil limité à l’espace de travail est utilisé. Si l’une d’elles 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 — une norme ouverte⁹ désormais régie 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 précis. Consultez la section Skills pour découvrir les modules 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 remplacent les directives 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

Les projets non approuvés ignorent le fichier AGENTS.md du projet (v0.150.0) : le parcours ci-dessus suppose que le projet est approuvé. Depuis la v0.150.0, « les projets non approuvés ne fournissent plus d’instructions AGENTS.md au niveau du projet, et les règles administrées d’interdiction de lecture restent appliquées après les modifications d’autorisations » – la découverte propre au projet est ignorée, tandis que les instructions utilisateur de ~/.codex/AGENTS.md sont conservées. Ainsi, un dépôt extrait non approuvé ne peut pas injecter de contrat opérationnel avant que vous ne l’approuviez.¹³²

Projets de bureau multidossiers (26.715, 23 juillet 2026) : le parcours ci-dessus décrit le CLI, qui résout tout par rapport au répertoire de travail courant. L’application de bureau ChatGPT permet désormais à un projet local de couvrir plusieurs dossiers associés, mais la découverte s’effectue 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 accessibles pour rechercher, lire et modifier des 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 reste un fichier que Codex peut ouvrir, mais ne constitue pas un contrat opérationnel chargé automatiquement. Si le dépôt contenant vos règles est celui que vous avez ajouté en second, définissez-le comme dossier principal ou reformulez 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 du CLI n’a pas changé — il s’agit du périmètre des projets de l’application de bureau.

Comment créer 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 : compilation, tests, lint et formatage (avec les commandes exactes) - Organisez les instructions par tâche : sections consacrées au développement, à la revue, à la publication et aux incidents/au débogage - Définissez la procédure d’escalade : que faire en cas de blocage ou de situation inattendue

À NE PAS FAIRE : - Copier 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 de la documentation en prose (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 d’agent

Considérez l’historique visible par Codex comme une surface de sécurité, et pas seulement le code source. Les notes de version de Codex documentent les travaux sur les instantanés du shell et la rédaction des variables d’environnement, tandis que le système de mémoire recherche des secrets lors des écritures en mémoire. Ces protections ne rendent toutefois pas sûrs les sorties de commandes, les transcriptions de sessions, les instantanés du shell, les journaux locaux ou les scripts auxiliaires dans lesquels des identifiants seraient affichés.³⁷⁵⁵⁹⁵

La règle opérationnelle est simple : n’affichez pas de secrets pour que le modèle les examine ; 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 emplacements réservés intentionnellement aux secrets ; expurgez l’historique local lorsqu’un motif 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 destiné au public porte sur la cartographie des surfaces et les critères d’acceptation, pas sur les valeurs de jetons privées, 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 ce périmètre. Utilisez-le pour :

• Gel des publications : « Aucune nouvelle fonctionnalité, uniquement des correctifs »
• Mode incident : « Toutes les modifications doivent être examinées par la personne d’astreinte »
• Durcissement 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 de la 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 les versions v0.99.0 et v0.100.0 sous les anciens noms AfterAgent et AfterToolUse, puis a ajouté un moteur de hooks expérimental dans la v0.114.0 avec SessionStart et Stop,⁷⁰ avant de stabiliser les hooks dans la v0.124.0 (23 avril 2026).⁸⁵ Le moteur livré dans rust-v0.150.0 enregistre douze événements (HOOK_EVENT_NAMES dans codex-rs/hooks/src/lib.rs) – onze dans la v0.149.1, auxquels Interrupt a été ajouté comme douzième événement dans la v0.150.0¹³² – et les anciens noms ont disparu de la surface configurable : AfterToolUse n’apparaît plus nulle part dans l’arborescence des sources, tandis que AfterAgent ne subsiste que comme nom interne de la charge utile de l’ancien pont notify.¹²⁴ Les hooks exécutent des scripts ou des outils MCP pendant la boucle agentique. Tous les hooks correspondants provenant de plusieurs fichiers s’exécutent, plusieurs hooks de commande correspondant à un même événement sont lancés simultanément, et chaque hook non géré doit être examiné et approuvé avant son exécution.¹²⁴ La v0.148.0 étend le moteur : les hooks peuvent exécuter des commandes de manière asynchrone et invoquer des outils MCP – définissez async = true sur un gestionnaire de commande pour l’exécuter en arrière-plan pendant que Codex poursuit son travail, ou utilisez un gestionnaire mcp_tool pour accéder aux mêmes serveurs MCP que ceux utilisés par l’agent.¹¹⁸¹²⁴

Événements de hook disponibles

Les outils hébergés tels que WebSearch ne passent pas par le chemin des hooks, et certains chemins d’outils spécialisés peuvent s’en exempter ; selon la formulation d’OpenAI, il s’agit d’« un garde-fou utile, et non d’une frontière d’application complète ».¹²⁴

Configuration des hooks

Les hooks sont organisés sur trois niveaux – un événement, un groupe de filtres et un ou plusieurs gestionnaires – et se trouvent soit dans hooks.json (~/.codex/hooks.json, <repo>/.codex/hooks.json ou le fichier hooks/hooks.json d’un plugin), soit directement dans config.toml et requirements.toml. Les hooks locaux au projet ne sont chargés que lorsque la couche .codex/ du projet est approuvée.¹²⁴ Voici la forme TOML intégrée :

# ~/.codex/config.toml or <repo>/.codex/config.toml
[[hooks.SessionStart]]
matcher = "startup|resume"

[[hooks.SessionStart.hooks]]
type = "command"
command = "python3 ~/.codex/hooks/session_start.py"
additionalContextLimit = 5000

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = '/usr/bin/python3 "$(git rev-parse --show-toplevel)/.codex/hooks/pre_tool_use_policy.py"'
timeout = 30
statusMessage = "Checking Bash command"

[[hooks.PostToolUse]]
matcher = "^Bash$"

[[hooks.PostToolUse.hooks]]
type = "command"
command = "python3 ~/.codex/hooks/post_tool_use_review.py"
async = true
timeout = 120

Champs des gestionnaires : type (command ou mcp_tool ; les gestionnaires prompt et agent sont analysés mais ignorés), command, timeout en secondes (600 par défaut ; 1 seconde pour SessionEnd, jusqu’à 3), statusMessage, additionalContextLimit (quantité de additionalContext transmise au modèle avant que Codex n’enregistre le texte intégral sur le disque et n’envoie un aperçu), commandWindows (remplacement réservé à Windows) et async. Les commandes utilisent le cwd de la session comme répertoire de travail ; les hooks locaux au dépôt doivent donc résoudre les chemins à partir de git rev-parse --show-toplevel plutôt que d’utiliser un chemin relatif .codex/hooks/....¹²⁴

Examen et approbation. Codex enregistre l’approbation en fonction du hash actuel de chaque hook non géré ; les hooks nouveaux ou modifiés sont marqués comme devant être examinés et sont ignorés jusqu’à leur approbation. Exécutez /hooks pour inspecter les sources des hooks, les examiner, les approuver ou désactiver certains d’entre eux ; lorsque des hooks doivent être examinés au démarrage, Codex affiche un avertissement renvoyant vers /hooks. Les hooks gérés provenant du système, de MDM, du cloud ou de sources requirements.toml sont approuvés par la stratégie et ne peuvent pas être désactivés depuis le navigateur de hooks de l’utilisateur. --dangerously-bypass-hook-trust exécute les hooks activés sans approbation persistante pour une seule invocation, à destination des automatisations qui vérifient les sources des hooks ailleurs.¹²⁴

La sortie stdout du hook SessionStart est intégrée au contexte du modèle, ce qui convient parfaitement à l’injection d’informations dynamiques (dates, noms de branches, variables d’environnement) au démarrage de la session.

Reproduction des modèles de hooks Claude Code

Codex utilise les mêmes noms d’événements que Claude Code pour les événements qu’il implémente. La plupart des configurations de hooks peuvent donc être portées en déplaçant le JSON dans hooks.json, puis en l’approuvant via /hooks :

Conseil d’expert : De nouveaux événements de hook continuent d’être ajoutés au fil des versions – la v0.150.0 a introduit l’événement Interrupt (¹³²) – consultez donc HOOK_EVENT_NAMES dans codex-rs/hooks/src/lib.rs ainsi que le journal des modifications de Codex pour connaître la liste actuelle.

Navigateur de hooks intégré à la TUI (v0.129.0) : Exécutez /hooks dans la TUI pour découvrir les hooks disponibles, voir lesquels 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 PostToolUse pendant une session d’édition intensive.⁸⁹

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é expérimental, et les commandes comme 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).¹¹

Changements MCP de la v0.121.0 : les outils sont désormais enregistrés avec un namespace, si bien que les noms d’outils apparaissent dans les listings sous la forme <server>:<tool> plutôt qu’en nom nu — mettez à jour tout script ou prompt qui filtre sur des noms d’outils non qualifiés. Un nouvel indicateur supports_parallel_tool_calls est transmis aux MCPs inclus, ce qui active l’exécution parallèle pour les serveurs qui déclarent la prendre en charge. Les métadonnées d’état du sandbox circulent maintenant dans les métadonnées d’outil MCP, ce qui permet aux serveurs d’adapter leur comportement (par exemple, avertir en cas d’exécution sous un sandbox read-only). La requête personnalisée codex/sandbox-state a été supprimée — passez plutôt par les métadonnées. La phase 3 du déploiement des MCP Apps 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 qui utilisent le motif d’appel différé.⁸²

Changements MCP de 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 d’emblée chaque définition d’outil, Codex découvre les outils à la demande, ce qui améliore la découverte dans les configurations riches en outils tout en restant compatible avec les modèles et fournisseurs plus anciens. 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 l’inverse).¹⁰⁵

Changements MCP de la v0.147.0 (7 août 2026) : Codex ajoute une prise en charge optionnelle de la révision 2026-07-28 du protocole MCP — découverte paginée (les grands catalogues d’outils arrivent par pages au lieu d’un listing surdimensionné), requêtes multi-tours (un serveur peut mener un échange en plusieurs étapes au sein d’une même 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, si bien qu’un serveur lent ne retarde plus le lancement de la session. Cette prise en charge est optionnelle : les serveurs restés sur l’ancienne révision continuent de fonctionner sans changement.¹¹⁶

Changements MCP de la v0.151.0 (29 août 2026) : les serveurs MCP optionnels bénéficient d’un délai de grâce configurable au démarrage – mcp_optional_startup_grace_ms (1 000 ms par défaut) contrôle combien de temps la capture du catalogue d’outils attend les serveurs optionnels, 0 désactive le délai de grâce partagé afin que les serveurs optionnels se rabattent sur leur startup_timeout_sec configuré, et les valeurs mises à jour s’appliquent pendant l’exécution comme lors des rechargements de configuration MCP. Les extensions peuvent également inspecter ou remplacer les résultats d’outils MCP avant qu’ils n’atteignent le modèle : ToolLifecycleContributor::on_mcp_tool_result s’exécute avant la publication de la complétion MCP et avant la préparation du résultat pour le modèle, aussi bien pour les résultats réussis que pour les erreurs, y compris via Code Mode.¹³⁴

Changements MCP de la v0.152.0 (1er septembre 2026) : trois ajouts. Les requêtes de formulaire openai/elicitation arrivent : Codex annonce la prise en charge des formulaires lorsque le client déclare une capacité form à valeur d’objet, traite les requêtes openai/elicitation/create et transmet leurs métadonnées ainsi que leur schéma opaque à travers l’app server sous le nom openaiForm (en préservant les annotations x-openai-*) ; la gestion héritée de openai/form reste indépendante, et la TUI refuse automatiquement les requêtes de formulaire qu’elle ne peut pas afficher. Limites de sortie par outil : chaque entrée sous la configuration tools d’un serveur MCP accepte un output_token_limit positif (par exemple [mcp_servers.context7.tools.search] avec output_token_limit = 2000) ; la limite la plus restrictive l’emporte lorsque les politiques du plugin et de l’utilisateur se chevauchent, et le budget effectif est transporté dans l’historique de conversation afin que la sortie des outils, les réponses des hooks post-outil et les sessions reprises soient tronquées à la même limite – cet ajout vient compléter le tool_output_token_limit global. Noms de serveurs de style paquet : les noms de serveurs MCP peuvent désormais contenir :, @, / et . (si bien que npm:@modelcontextprotocol/server-sequential.thinking est un nom valide), préservés à travers mcp add/get/list/remove, les namespaces d’outils à l’exécution et la recherche d’identifiants OAuth, les noms non nus étant mis entre guillemets dans les indications de récupération générées pour config.toml.¹³⁸

Configurer les 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 l’ensemble des diagnostics du serveur, des ressources et des modèles de ressources — utile lorsqu’un serveur ne parvient pas à se charger ou que des outils n’apparaissent pas là où on les attend. /mcp seul reste rapide. Depuis la v0.144.0, les outils MCP peuvent demander une authentification de manière interactive, sans opt-in expérimental — un serveur qui a besoin d’une authentification en cours de session vous la demande via le flux normal au lieu d’échouer jusqu’à ce que vous vous authentifiiez au préalable avec codex mcp login.¹⁰⁷

Le chargement MCP des plugins (v0.123.0+) accepte à la fois le schéma standard mcpServers et les cartes de serveurs de premier niveau dans .mcp.json, si bien que les plugins écrits selon l’une ou l’autre convention se chargent proprement.⁸⁴

Vérification utilisateur MCP (v0.155.0, Mac compatibles) : les sessions TUI locales sur les Mac compatibles peuvent vérifier les requêtes MCP avec Touch ID, signé par la Secure Enclave (#43624, #43712, #43715). L’identité de vérification est restreinte à l’espace de travail dans lequel elle a été enregistrée (#43524), et la vérification se propage nativement aux continuations d’outils MCP (#44346). D’abord surveillée sur la checklist de promotion de la v2.68, écartée de la 0.154.0 avec le cluster alpha.7, livrée dans la 0.155.0.¹⁵⁶

Exécuter Codex EN TANT QUE serveur MCP

Supprimé (v0.154.0, 9 septembre 2026). La commande codex mcp-server et le binaire autonome codex-mcp-server ont disparu depuis la version stable 0.154.0 (#42993), achevant la dépréciation du 24 août 2026. Le changelog officiel (5 septembre 2026) : « La commande codex mcp-server et le binaire autonome codex-mcp-server ont été supprimés après leur dépréciation le 24 août 2026. Mettez à jour les intégrations qui lancent l’une ou l’autre commande avant de mettre Codex à niveau. » Les intégrations doivent viser le protocole app-server, l’interface qui sous-tend l’extension VS Code et l’application de bureau (authentification, historique de conversation, approbations, événements d’agent en flux) – que l’entrée de suppression qualifie elle-même d’expérimentale et de « non prise en charge pour les charges de production » – ou bien, depuis Claude Code, le plugin Codex pour Claude Code : « Utilisez Codex depuis Claude Code pour relire du code ou déléguer des tâches. » La connexion de Codex VERS des serveurs MCP externes (codex mcp ..., /mcp) n’est pas affectée.^125152153

Sur CLI 0.153.4 et versions antérieures, la commande existe toujours (dépréciée depuis le 24 août 2026 ; depuis la v0.149.0 elle affiche warning: `codex mcp-server` is deprecated and will be removed in a future release. sur stderr puis démarre quand même, PR #39657), donc épingler npm install -g @openai/codex@0.153.4 est la solution de dépannage si une intégration ne peut pas migrer immédiatement :^12125148152

codex mcp-server                        # REMOVED in 0.154.0; works only on 0.153.x and earlier (deprecated, warns)

Sur les versions 0.153.x et antérieures, 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 un threadId et un prompt

Utilisation avec l’Agents SDK (Python) – CLI 0.153.4 ou antérieure uniquement :

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

async with MCPServerStdio(
    name="Codex CLI",
    params={"command": "npx", "args": ["-y", "@openai/codex@0.153.4", "mcp-server"]},  # pin: removed in 0.154.0
    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

Motifs pratiques

Motif 1 : développement contextuel — associez Context7 à la documentation de votre framework pour que Codex dispose toujours de références API à jour :

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

Motif 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 de grosses charges utiles (requêtes de base de données, captures de logs), utilisez enabled_tools afin de restreindre l’accès à des outils précis et de garder des réponses ciblées.

Motif 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.⁶²

Motif 3 : gouvernance MCP en entreprise — verrouillez 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é déclarée 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) propose des workflows 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 du code, sans interactions plus larges avec le système.

Depuis la v0.139.0, le mode code peut appeler directement la recherche web autonome — y compris depuis des appels d’outils JavaScript imbriqués — et reçoit les résultats en texte brut. Un workflow en mode code peut ainsi récupérer des informations en temps réel sans quitter le contexte de programmation sandboxé.¹⁶⁵ La v0.146.0 étend la recherche web autonome aux fournisseurs de modèles personnalisés compatibles : cette fonctionnalité n’est donc plus réservée aux modèles hébergés par OpenAI.¹¹⁴

La v0.146.0 a permis à app-server de se connecter à des hôtes Code Mode distants : le runtime du mode code n’a donc plus besoin de s’exécuter sur la même machine que le client — initialement via WebSocket.¹¹⁴ La v0.151.0 supprime le transport WebSocket (#40692) : les connexions --code-mode-host de l’app server acceptent uniquement les endpoints gRPC http:// et https://, tandis que l’hôte autonome du mode code est limité aux écouteurs stdio et gRPC — dans le tag rust-v0.151.0, sa documentation indique textuellement « Transport endpoint: stdio, stdio://, or grpc://IP:PORT. » WebSocket ne subsiste que comme endpoint facultatif diffusant des lots bruts de traces OTLP pour le traçage, et non comme transport de session.¹³⁵

Cette fonctionnalité est expérimentale. Consultez les notes de version pour suivre son évolution.

Runtime REPL JavaScript [SUPPRIMÉ]

Codex v0.100.0 a ajouté un runtime REPL JavaScript expérimental (js_repl), puis la v0.106.0 l’a mis en avant dans l’interface /experimental.⁶⁰ Ces indications sont désormais historiques. Dans la v0.128.0, le journal des modifications 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, les outils MCP ou une skill Codex dotée d’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. Elles respectent le standard ouvert agent skills.¹³

Structure d’une 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ées par l’utilisateur dans $CODEX_HOME/skills (par défaut : ~/.codex/skills), y compris les skills système intégrées sous .system/. Codex prend en charge les dossiers de skills liés symboliquement.

Créer une 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

• Explicite : menu /skills ou mention de $skill-name dans le prompt
• Implicite : 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 une nouvelle skill de manière interactive
• Programme d’installation : utilisez $skill-installer install <name> pour installer des skills communautaires
• Fournies par l’exécuteur (v0.146.0) : Codex découvre les skills proposées par l’exécuteur et lit les ressources qui leur sont associées, y compris celles 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 : une skill que vous pensiez disponible dans le contexte pouvait donc ne pas être proposée. Si vous comptez sur l’invocation implicite pour de nombreuses skills, soyez attentif à cet avertissement.

Activer/désactiver

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

Skills et slash commands

Dépanner les skills

Si une skill ne s’active pas :

1. Vérifiez sa découverte : /skills doit la répertorier dans la TUI
2. Vérifiez le chemin : assurez-vous que le dossier de la skill se trouve dans un emplacement reconnu (~/.codex/skills/, racine du projet ou /etc/codex/skills/)
3. Vérifiez enabled : les skills avec enabled = false dans config.toml ne sont pas chargées
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 les termes de la description de la skill dans votre prompt pour améliorer la correspondance implicite

Exemple en production : skill de déploiement

Une skill multifichier complète illustrant le fonctionnement conjoint des références et des scripts :

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-la 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’apps dans un seul package installable (v0.110.0+).⁶⁵ Depuis la v0.117.0, les plugins sont des composants de premier ordre : ceux limités au produit se synchronisent automatiquement au démarrage, tandis que /plugins fournit un navigateur intégré à la TUI pour les découvrir et les gérer.⁷⁵ La v0.128.0 a étendu les workflows de plugins avec l’installation depuis des marketplaces, la mise en cache des packages distants, les APIs de désinstallation à distance, les hooks intégrés aux plugins, l’état d’activation des hooks et l’importation de la configuration d’agents externes.⁸⁶ La v0.129.0 (7 mai 2026) ajoute le partage de plugins dans un workspace (transmettre un ensemble de plugins à vos collègues sans le republier), des contrôles d’accès au partage (activation ou désactivation par destinataire, révocation), le filtrage des sources (limiter les marketplaces utilisées par un workspace) et des opérations sur les marketplaces directement accessibles depuis le navigateur /plugins plutôt que depuis la CLI.⁸⁹ La v0.133.0 (21 mai 2026) facilite l’audit de la découverte des plugins : la sortie des listes tient compte des marketplaces, les versions installées sont visibles, les racines des marketplaces sont répertoriées et les collections de plugins distantes peuvent être affichées sans avoir à deviner de quel registre provient un résultat.⁹⁸ La v0.130.0 (8 mai 2026) rend le packaging des plugins plus transparent et le workflow de partage plus contrôlable :⁹¹

• Hooks intégrés visibles dans les détails du plugin. La vue détaillée de /plugins répertorie désormais chaque hook de cycle de vie inclus dans un plugin (SessionStart, UserPromptSubmit, Stop, etc.). Avant d’installer un plugin, vous pouvez voir précisément les hooks qu’il enregistrera dans votre session — fini les effets secondaires inattendus de hooks provenant d’un plugin auquel vous ne faisiez confiance que pour ses outils.
• Métadonnées de partage du plugin dans shareContext. Lorsqu’un plugin est partagé depuis un workspace, la charge utile du lien de partage expose désormais ses métadonnées (créateur, portée, actualité), ce qui permet aux sessions destinataires d’en afficher la provenance et de décider si elles souhaitent l’accepter.
• Contrôles de visibilité dans les paramètres de partage. Les paramètres de partage proposent une option de visibilité afin que les équipes puissent publier des plugins dans des workspaces précis ou auprès de listes de destinataires sans les rendre accessibles dans les listes générales de toute l’organisation.

La v0.143.0 (8 juillet 2026) active les plugins distants par défaut. Les plugins distants sont désormais activés sans option préalable, le catalogue /plugins propose des lignes plus détaillées (avec les sources de marketplaces npm aux côtés de git et des sources locales) et chaque entrée affiche à la fois sa version distante et sa version installée localement, ce qui permet de repérer immédiatement tout écart.¹⁰⁶ Pour une équipe qui standardise son environnement autour d’un ensemble de plugins partagé, cette activation par défaut supprime l’étape d’activation sur chaque machine qui freinait auparavant le déploiement.

Sources de plugins

Depuis la v0.147.0, une même requête de recherche de plugins couvre les catalogues locaux, personnels, de workspace et distants — vous recherchez une fonctionnalité, pas le catalogue qui la contient. Associée aux packages Agent Plugins portables, cette fonctionnalité permet d’installer sans difficulté dans un environnement un plugin créé dans un autre, au lieu de le lier à la machine ou au workspace où il a été conçu.¹¹⁶

Découverte des plugins

Au démarrage de la session, Codex indique au modèle les plugins activés (v0.111.0), ce qui améliore la découverte des MCPs, apps et skills installés.⁶⁵ Le modèle peut suggérer des plugins pertinents au cours d’une session en fonction du contexte de la tâche. Depuis la v0.117.0, les plugins limités au produit sont synchronisés au démarrage, garantissant ainsi la disponibilité du catalogue de plugins le plus récent sans intervention manuelle.⁷⁵ Depuis la v0.142.0, le menu /plugins classe les plugins distants dans les sections Sélectionnés par OpenAI, Workspace et Partagés avec moi, tandis que les interactions admissibles peuvent recommander et installer directement les plugins pertinents.¹⁰⁴ Depuis la v0.151.0, plugin/list et plugin/installed chargent la configuration effective des plugins pour chaque cwd demandé – les marketplaces locales sont combinées dans l’ordre de la requête, les états d’installation et d’activation sont fusionnés entre les dépôts, et les configurations de projet non valides sont signalées dans marketplaceLoadErrors sans exclure les catalogues locaux valides ni les catalogues distants activés globalement.¹³⁴

Mentions @plugin (v0.112.0+)

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

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

Cette syntaxe fonctionne avec tous les plugins installés, y compris les skills personnalisés, les serveurs MCP et les connecteurs d’apps.

Marketplace de plugins (v0.113.0+)

La marketplace de plugins permet désormais une découverte plus approfondie grâce aux métadonnées, aux catégories et aux évaluations.⁶⁹ Lors de l’installation, des contrôles d’authentification vérifient que les plugins nécessitant des clés API ou OAuth disposent d’identifiants valides. Un endpoint 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 place la gestion des sources de marketplaces sous codex plugin marketplace. Cette commande 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 marketplaces 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 proposés par défaut. Les clients du serveur d’app (intégrations IDE/desktop) disposent d’un endpoint 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 dans une sandbox lors des premiers lancements.

Agent Plugins : la norme multifornisseur (v0.146.0–v0.147.0)

« Agent Plugins » n’est pas seulement le nom d’une fonctionnalité Codex — il s’agit d’une norme de packaging ouverte et indépendante des fournisseurs, publiée sous le nom Agent Plugins 1.0.0 le 6 août 2026, que son site officiel résume ainsi : « Un format de package portable destiné aux composants réutilisables qui étendent les agents IA. »¹⁶¹ Un plugin est un répertoire contenant obligatoirement un manifeste plugin.json (un schéma fermé comportant exactement dix champs de premier niveau autorisés — $schema, name, version, description, author, homepage, repository, license, keywords, extensions — selon lequel « les clients DOIVENT signaler et ignorer chaque champ inconnu »), un dossier skills/ facultatif (chaque répertoire enfant direct contenant un fichier SKILL.md constitue un skill), un fichier mcp.json facultatif déclarant des serveurs stdio, Streamable HTTP ou HTTP+SSE hérités, ainsi que des répertoires facultatifs d’espace de noms client en domaine inversé que les autres clients « DOIVENT ignorer ». Son périmètre normatif concerne le packaging : la spécification « définit la norme Agent Plugins v1.0.0 canonique pour regrouper dans des plugins distribuables des composants réutilisables qui étendent les agents IA » — Agent Skills et MCP conservent leurs propres spécifications sous-jacentes.¹⁶¹

La gouvernance constitue l’élément essentiel. Vercel a lancé la proposition et élaboré la spécification 1.0 avec Amazon, Anysphere (Cursor), GitHub, Microsoft et OpenAI ; la liste des responsables du dépôt de la spécification réunit des représentants d’Amazon, Cursor, Microsoft, OpenAI et Vercel, tandis que Google a annoncé le jour du lancement qu’il rejoignait les responsables principaux.¹⁶¹ Les clients de lancement cités comprennent ChatGPT, Codex, Cursor, GitHub Copilot, Kiro et VS Code. Une absence est particulièrement notable : Anthropic, à l’origine du format Agent Skills sous-jacent et de MCP, ne figure pas parmi les responsables — Claude Code conserve son propre format de plugin, et Codex comble l’écart de son côté grâce à la source de marketplace Claude Code (v0.146.0) et à /import.¹⁶¹

Dans le contexte de Codex : la v0.146.0 ajoute les manifestes Agent Plugins, la publication de plugins dans un workspace et deux marketplaces de plugins supplémentaires — Amazon Bedrock et Claude Code¹¹⁴ — tandis que la v0.147.0 boucle la boucle en permettant l’installation d’Agent Plugins portables et la recherche dans les catalogues locaux, personnels, de workspace et distants.¹¹⁶ Pour les équipes, la publication dans un workspace constitue la partie la plus utile sur le plan opérationnel : publiez les plugins dans votre propre workspace 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 interfaces Codex sans publier leurs clés de configuration ni la syntaxe de leur CLI. Cette entrée consigne la disponibilité de la fonctionnalité et les dispositions de la norme, mais pas la manière de l’utiliser depuis Codex — considérez le workflow de création du 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
codex plugin list                        # List plugins; includes remote catalog entries (v0.153.0)
codex plugin list --json                 # JSON adds source, version, install + auth policy (v0.153.0)

La v0.153.0 étend la CLI des plugins, de la gestion des marketplaces aux opérations portant sur des plugins individuels dans des marketplaces distantes : codex plugin list inclut les entrées des catalogues distants (avec leur source, leur version, leur politique d’installation et leur politique d’authentification dans la sortie JSON), et les plugins distants peuvent être ajoutés ou supprimés au moyen de la CLI existante des plugins. Les catalogues distants sont mis en cache par portée et par collection – les résultats récents en cache sont privilégiés, une requête d’ajout qui ne trouve pas un plugin dans le cache déclenche une nouvelle récupération unique, et le catalogue local sélectionné est préservé lorsqu’une liste distante non filtrée échoue (les erreurs restent affichées pour les marketplaces distantes explicitement sélectionnées).¹⁴⁰

Dans la TUI, utilisez /plugins (v0.117.0+) pour parcourir, installer et supprimer interactivement des plugins individuels sans quitter votre session.⁷⁵

Conseil d’expert : les plugins regroupent ce qui nécessitait auparavant une configuration MCP, l’installation de skills et la configuration de connecteurs d’apps distinctes. Un seul plugin peut intégrer ces trois éléments — 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 Cadres de décision pour l’arbre de décision « Mode Plan ou exécution directe ».

Mode Plan ou outil update_plan (v0.152.0) : il s’agit de deux choses différentes, dont une seule est activée par défaut. Le mode Plan — le mode de collaboration décrit dans cette section, où Codex formule une proposition avant de l’exécuter — est activé par défaut depuis la v0.94.0 et demeure inchangé. update_plan est un outil de planification que le modèle peut appeler pour tenir à jour un plan structuré au cours d’un tour ; livré avec la v0.152.0, il doit être activé explicitement : tools.update_plan.enabled vaut false par défaut. Tant qu’il est désactivé, Codex retire également les consignes update_plan intégrées de ses prompts de modèle, de mode de collaboration, de système multi-agent, de compactage, de préchauffage et de poursuite des objectifs (les instructions de base personnalisées, les instructions du catalogue de modèles, les politiques de collaboration et le texte des objectifs de l’utilisateur restent préservés, même lorsqu’ils mentionnent la planification). Activez-le explicitement avec tools.update_plan.enabled = true dans config.toml.¹³⁸

Passer en 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 avant votre approbation ; - affiche le plan au fil de sa génération 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.¹⁴

Deux méthodes d’injection sont disponibles :

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 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 en ligne. 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 l’autorisation d’accéder 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 précisément le matériel utilisé.⁶² 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 (sans incidence sur la transcription vocale déclenchée par la barre d’espace).¹⁰² La v0.145.0 réintroduit la voix sous une nouvelle forme : entrées audio et sorties audio des outils dans les formats audio locaux courants, ainsi que conversations V3 en temps réel et en streaming.¹¹² v0.155.0 et v0.156.0 : conversations vocales en direct. La v0.155.0 (17 septembre 2026) a ajouté /voice comme fonctionnalité expérimentale à activer explicitement : une conversation en direct avec transcription en streaming et commandes du microphone, activée via /experimental dans les versions compatibles (#43581, #43651, #44331), avec un raccourci configurable pour couper le son (#43690) et des ressources vocales signées dans les paquets macOS (#43983). La v0.156.0 (22 septembre 2026) l’a rendue stable et activée par défaut (#44921), et le journal des modifications de la documentation l’a annoncé le même jour : « Les conversations vocales sont activées par défaut, avec un raccourci F8, un sélecteur /voice settings et des environnements d’exécution audio intégrés pour Linux et Windows. » Pour la désactiver, définissez realtime_conversation = false sous [features] dans config.toml. La référence des slash commands CLI ne répertorie toujours pas /voice, tandis que la page de documentation consacrée à la fonctionnalité Voice porte sur ChatGPT Voice dans l’application de bureau, une interface distincte.¹⁵⁶¹⁶⁹

Autres améliorations : - Les liens longs restent désormais cliquables même lorsqu’ils sont répartis sur plusieurs lignes de la TUI (v0.105.0)⁶¹ - Les liens vers des fichiers locaux bénéficient d’une mise en forme améliorée (v0.106.0)⁶⁰ - Dans le Markdown de la TUI, les liens web restent cliquables grâce aux métadonnées OSC 8, tandis que les tableaux trop serrés sont remplacés par des enregistrements clé/valeur lisibles sans perdre les cibles des liens (v0.136.0)¹⁶⁸ - Les liens Markdown s’affichent sous forme de libellés cliquables dans les terminaux compatibles, tandis que les URL restent visibles ailleurs (v0.150.0)¹³² - 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 des faits, des préférences et le contexte des projets d’une session à l’autre.²⁴

Commandes de mémoire

Les souvenirs sont stockés dans des fichiers Markdown sous ~/.codex/memory/. Codex les charge au démarrage de la session et les utilise pour adapter son comportement lors de toutes les sessions ultérieures.

Informations à conserver

La mémoire convient particulièrement aux préférences durables et aux faits relatifs aux projets :

• Conventions du projet : « Ce projet utilise des tabulations, et non des espaces » ou « Les réponses de API comprennent toujours un champ meta »
• Préférences concernant les outils : « Utilisez pnpm plutôt que 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/, et non dans src/middleware/ »
• Préférences de workflow : « Exécutez toujours le linter avant de me montrer un diff »

Mémoire dans les pipelines

Lors de l’exécution de codex exec, les souvenirs sont chargés automatiquement. Les pipelines CI/CD et les scripts bénéficient ainsi du même contexte que les sessions interactives — inutile de répéter les instructions à chaque appel.

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

• Nettoyage des secrets : les souvenirs sont automatiquement analysés à la recherche de secrets avant leur écriture sur le disque
• Prise en compte du CWD : les fichiers de mémoire comprennent désormais le contexte du répertoire de travail afin de permettre un rappel propre au projet
• Exclusion des messages développeur : les messages développeur/système sont exclus des données d’entrée de la phase 1 de la mémoire, ce qui en améliore la qualité en privilégiant les interactions avec l’utilisateur
• Oubli fondé sur les diffs (v0.106.0) : la mémoire utilise désormais un mécanisme d’oubli fondé sur les diffs pour supprimer les faits obsolètes, ce qui permet de conserver un espace de mémoire léger et pertinent au fil du temps⁶⁰
• Sélection tenant compte de l’utilisation (v0.106.0) : la récupération en mémoire tient désormais compte de l’utilisation et donne la priorité aux souvenirs fréquemment consultés et récemment pertinents⁶⁰
• Mémoire configurable (v0.107.0) : la mémoire est désormais entièrement configurable. Utilisez codex debug clear-memories pour effacer tous les souvenirs stocké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 a dérivé⁶²
• Mise à niveau du modèle de phase 2 (v0.121.0) : le modèle de consolidation de la mémoire en phase 2 est désormais gpt-5.4 (au lieu du modèle précédent par défaut). Le pipeline de phase 2 s’exécute entre les sessions afin de condenser les transcriptions de la phase 1 en faits durables ; ce changement de modèle améliore la qualité du rappel à coût égal en tokens.⁸²
• Menu des souvenirs dans la TUI (v0.121.0) : une nouvelle interface accessible en cours de session permet de gérer le mode de mémoire, de supprimer des souvenirs individuellement et de tout réinitialiser. La réinitialisation de la mémoire préserve désormais les rollouts passés au lieu de les invalider : elle efface donc les éléments susceptibles d’être rappelés à l’avenir sans perturber la relecture des sessions.⁸²

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 le 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 bifurquer et d’utiliser des workflows multithreads sur les interfaces CLI et de bureau.

La 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 parallèles restent ouvertes au lieu de vous obliger à en fermer une pour accéder à une autre.¹¹⁴ Concrètement, un projet de longue durée n’est plus une liste d’horodatages que vous devez reconnaître par leur date. La v0.147.0 ajoute des sections de conversation : les conversations sont regroupées dans des sections persistantes, ordonnées manuellement, et les longues transcriptions se parcourent progressivement au lieu d’être chargées en entier.¹¹⁶ La v0.148.0 ajoute /export et la bifurcation en ligne de commande : /export écrit l’intégralité de la conversation au format Markdown (dans le presse-papiers ou dans un nouveau fichier), codex exec fork bifurque une session de manière non interactive, et le sélecteur de reprise permet d’archiver et de restaurer des sessions.¹¹⁸ La v0.149.0 ajoute codex queue — qui permet d’envoyer des messages à des sessions locales ou distantes existantes depuis la ligne de commande — et corrige les threads repris ou bifurqués afin qu’ils restaurent leur profil d’autorisation actif.¹²⁰ La v0.150.0 ajoute les titres automatiques : les tâches de terminal sans nom reçoivent automatiquement un titre descriptif, et /rename suggère un titre modifiable à partir de la conversation.¹³² La v0.151.0 ajoute /recap : demandez à tout moment un bref résumé des avancées récentes de la conversation et des prochaines étapes ; Codex génère également ce même récapitulatif automatiquement pour les conversations éligibles, inactives et non affichées, puis l’ajoute à la transcription, au moyen de requêtes limitées et isolées, avec de nouvelles tentatives uniquement en cas d’échec automatique.¹³⁵ La v0.153.0 rend la partie automatique facultative : tui.auto_recap = false annule les vérifications automatiques planifiées des récapitulatifs et ignore les résultats automatiques en attente, tandis que la commande manuelle /recap continue de fonctionner.¹⁴⁰

codex agents (v0.149.0) est le tableau de bord interactif de toutes les sessions d’agent actives sur la machine : recherchez, démarrez, ouvrez, renommez et arrêtez des tâches depuis un même écran, avec des raccourcis configurables. Dans une session, /agents permet de passer d’une session d’agent active à une autre, tandis que /subagents permet de basculer entre les sous-agents de la session actuelle.¹²⁰¹²⁹ La v0.150.0 rend les tâches adressables depuis la conversation : référencez d’autres tâches Codex avec des mentions @ et demandez aux agents de lire, créer ou contacter des tâches depuis le terminal.¹³²

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 slash command /resume dans la TUI ouvre le même sélecteur interactif doté d’une fonction de recherche.

Historique paginé des threads (v0.145.0, promu dans la v0.151.0) : l’historique paginé des threads apporte une reprise efficace, la recherche dans l’historique, la conservation des noms de threads, la prise en charge des sous-agents et les mémoires à la gestion des sessions — l’historique se charge page par page plutôt qu’en une seule fois, ce qui est important pour les répertoires de travail utilisés sur la durée et contenant des centaines de sessions. Introduit à titre expérimental dans la v0.145.0, il évolue dans la v0.151.0, qui sort les APIs du statut expérimental (thread/turns/list, thread/items/list et thread/revert ne nécessitent plus la fonctionnalité expérimentale API) et fait du mode paginé la valeur par défaut résolue UNIQUEMENT pour les threads durables dont le stockage prend en charge thread/turns/list et thread/items/list, et seulement lorsque thread/start omet historyMode. Les threads éphémères et ceux qui s’appuient sur des stockages ne prenant pas en charge ces APIs utilisent toujours le mode hérité par défaut, les sélections explicites conservent leur comportement, et l’énumération ThreadHistoryMode au niveau du protocole utilise toujours Legacy par défaut avec le tag rust-v0.151.0 (protocol.rs:755-758) — il s’agit d’une valeur par défaut résolue pour les threads durables compatibles, et non d’un basculement généralisé.¹¹²¹³⁵

Bifurquer

Créez une branche d’une conversation pour explorer d’autres possibilités sans perdre votre progression actuelle :

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

Les bifurcations créent des threads indépendants qui partagent le même historique jusqu’au point de bifurcation. Depuis la v0.146.0, l’historique des bifurcations est paginé, et les bifurcations peuvent être créées comme temporaires — une bifurcation temporaire n’apparaît pas dans les listes de threads, ce qui évite d’encombrer la liste que vous parcourez réellement avec des expérimentations jetables.¹¹⁴ Les modifications apportées dans une bifurcation n’affectent pas l’autre. Cette fonctionnalité est utile pour comparer différentes approches (par exemple, « bifurquer et essayer Redis au lieu de Memcached ») ou explorer sans risque des modifications potentiellement dangereuses.

Bifurcation de threads en sous-agents (v0.107.0) : les threads peuvent désormais être bifurqués en sous-agents indépendants, ce qui permet à une conversation de créer des flux de travail parallèles s’exécutant de manière autonome. Cette fonctionnalité étend le modèle de bifurcation existant — au lieu de simplement créer une branche de la conversation, le thread bifurqué devient un sous-agent disposant de son propre contexte d’exécution.⁶² Depuis la v0.117.0, les sous-agents utilisent des adresses basées sur des chemins (par exemple, /root/agent_a) et 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 la tâche qu’un agent parent envoie lorsqu’il crée un sous-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 : le API Responses chiffre la charge utile lorsque le modèle parent émet l’appel d’outil, l’instance locale de Codex ne transporte que le texte chiffré (InterAgentCommunication.encrypted_content, avec un contenu en clair vide), puis le API le déchiffre côté serveur avant de le transmettre au modèle destinataire.¹⁰⁸ Trois conséquences pratiques en découlent :

• Les journaux de votre session locale ne contiennent plus le texte en clair des délégations. Vous pouvez voir qu’un parent a créé un sous-agent et consulter le résultat renvoyé, mais pas l’instruction exacte qu’il lui a transmise. Si vous auditez ou déboguez des exécutions multi-agents à partir de l’historique des sessions, cet enregistrement n’est plus disponible ; le ticket de régression ouvert pour suivre ce problème ne comporte aucun correctif associé à la mi-juillet 2026.¹⁰⁹ Les événements du cycle de vie des extensions (démarrage et arrêt des sous-agents, exécution des outils, métadonnées des tours — v0.133.0+) et les fonctions d’observabilité de l’app-server restent les moyens disponibles pour reconstituer ce qui s’est passé.⁹⁸
• Les modèles de fournisseurs personnalisés peuvent ne plus fonctionner. Un endpoint de modèle qui n’est pas configuré pour l’utilisation chiffrée des outils rejette le schéma chiffré de spawn_agent 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é, la cause est la modification relative au chiffrement, et non votre configuration.¹⁰⁹
• Les notifications générées par Codex restent lisibles. Les notifications d’achèvement des agents enfants sont produites par Codex lui-même ; elles restent donc en clair et s’affichent désormais sous forme d’éléments agent_message typés plutôt que d’enveloppes JSON sérialisées.¹⁰⁸

OpenAI n’a pas publié le modèle de menace à l’origine de cette modification ; la PR décrit le flux du texte chiffré sans préciser ce contre quoi il offre une protection.

Multi-agent v2 stabilisé (v0.145.0, activation facultative) : l’expérience Multi-agent v2, lancée dans la v0.137.0 et enrichie de la délégation chiffrée dans la v0.138.0, est désormais stabilisée sous la forme d’une fonctionnalité facultative. La v0.145.0 ajoute des modèles de sous-agents configurables, des niveaux de raisonnement propres à chaque sous-agent, une concurrence configurable, le rétablissement des rôles multi-agents et une navigation améliorée entre les agents. Si vous aviez préféré attendre avant d’adopter la v2 pendant la période d’ajustement des v0.137/v0.138, cette version stabilise l’interface de configuration — le choix du modèle et du niveau de raisonnement des sous-agents réside désormais dans la configuration au lieu d’être imposé 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’intégralité de leur historique et des aperçus des différences.

Cycle de vie d’une session

Les sessions se synchronisent entre CLI et l’application de bureau — commencez dans l’une de ces interfaces, puis 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 -c approval_policy=on-request "fix the CI failure"   # exec has no -a flag; set the policy via -c or config
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 garder la liste de reprise et de fork ciblée sans supprimer l’historique. Archivez une session depuis la TUI avec /archive, ou depuis le shell :¹⁶⁸

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

Une session archivée ne peut faire l’objet d’une reprise ni d’un fork tant que vous ne l’avez pas désarchivée — une protection contre la poursuite accidentelle d’une session que vous souhaitiez clôturer. 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.¹⁶⁸

Sortie au format JSON Lines

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

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 de 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 sans interface, 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 à 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 fourni avec les interfaces Desktop et IDE.⁹¹ La v0.133.0 améliore le fonctionnement de la commande : elle peut s’exécuter au premier plan, attendre que le service soit prêt, communiquer l’état de la machine, tout en proposant des commandes explicites de type daemon start / stop pour les configurations de contrôleurs 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 la négociation de découverte automatique — utile lorsque le processus de contrôle se trouve sur un hôte ou un segment réseau différent de celui du 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 développez des interfaces utilisateur devant parcourir de vastes 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 threads volumineux page par page grâce à trois vues distinctes des éléments d’un tour :⁹¹

Associez la pagination à l’interface ThreadStore introduite dans la v0.121.0 afin de 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 élargit 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 depuis un point antérieur sans devoir rejouer la suite.¹⁰⁶ La v0.151.0 fait sortir les APIs d’historique paginé des threads du statut expérimental et utilise par défaut l’historique paginé pour les threads persistants dotés de stores compatibles lorsque thread/start omet historyMode (les threads éphémères et les stores non compatibles conservent l’ancien mode) ; le chargement de l’historique complet est déconseillé pour les threads paginés (#40676).¹³⁵

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 apportées à config.toml sans nécessiter de redémarrage — modifiez la configuration, enregistrez-la, et le thread en cours appliquera les nouvelles valeurs lors de son prochain tour. Ce correctif complète codex remote-control : un serveur sans interface fonctionnant sur une longue durée peut être reconfiguré sur place au lieu d’être arrêté.⁹¹

Paramètres en direct limités au tour (v0.151.0) : les paramètres d’un tour en cours peuvent désormais être modifiés pendant son exécution. La méthode expérimentale turn/settings/update de l’app-server met à jour model, effort, summary et serviceTier pour les étapes suivantes d’un tour actif précis sans modifier les tours futurs, et indique si la mise à jour a été appliquée, rejetée ou si sa cible a disparu ; les contraintes gérées sont de nouveau validées, tandis que les propriétés d’approbation admises et de sécurité Guardian du tour sont préservées avant la publication d’un instantané actualisé des paramètres. turn/start accepte également serviceTierForTurn, ce qui permet à un nouveau tour de remplacer le niveau de service sans modifier celui enregistré pour le thread (« default » correspond à la vitesse standard ; une valeur omise ou null hérite du niveau du thread).¹³⁵

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

Depuis la v0.141.0 (stable, 18 juin 2026), les exécuteurs distants se connectent au moyen de canaux Noise-relay 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 sépare, ce qui compte dès lors que 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 répertoire de travail et le shell natifs de l’exécuteur : lorsqu’un contrôleur exécuté sur un OS pilote un exécuteur sur un autre, les chemins et la sémantique du shell ne sont plus réécrits à son insu. TLS accepte désormais aussi les signatures de certificat P-521 pour assurer la compatibilité avec les proxys d’entreprise.¹⁰³

Codex Cloud et tâches en arrière-plan [EXPÉRIMENTAL]

Prise en charge de GitLab (bêta, 19 août 2026) : Codex Cloud peut désormais se connecter aux projets GitLab avec toutes les offres ChatGPT — associez un projet, créez des environnements, lancez des tâches à partir d’issues et de demandes de fusion, et sollicitez des revues ; Self-Managed GitLab nécessite la version 19.0 ou ultérieure.¹¹⁹

Statut : Codex Cloud est une fonctionnalité expérimentale. Les interfaces, les tarifs et la disponibilité sont susceptibles d’é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.⁴ Depuis la version v0.150.0 de CLI, les tâches sont également accessibles depuis une conversation dans le terminal : référencez d’autres tâches Codex avec des mentions @ et demandez aux agents de lire, créer ou envoyer des messages aux tâches.¹³² Consultez également Action GitHub et CI/CD pour intégrer Codex à votre pipeline CI.

Sécurisation renforcée des identifiants des tâches cloud (v0.152.0) : les requêtes de tâches cloud peuvent contenir des identifiants ChatGPT enregistrés. Leur destination est donc désormais restreinte avant même le chargement de l’authentification – CODEX_CLOUD_TASKS_BASE_URL est validée par rapport aux origines HTTPS ChatGPT approuvées sur le port 443 (les URL contenant des informations utilisateur, des requêtes ou des fragments sont rejetées), et les redirections sont désactivées pour le backend des tâches cloud et les clients de découverte d’environnements afin que les identifiants ne soient jamais transmis à une destination de redirection.¹³⁸

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 configuré 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 + restrictions sur les méthodes HTTP

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

Les scripts de configuration peuvent toujours accéder à Internet pour installer les 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 fil Slack pour lancer une tâche cloud.

Prérequis : 1. Offre ChatGPT éligible (Plus, Pro, Business, Enterprise ou Edu) 2. Compte GitHub connecté 3. Au moins un environnement cloud configuré 4. Application Slack installée dans votre espace de travail

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

L’application Codex Desktop (macOS et Windows) propose une interface graphique optimisée pour la gestion de plusieurs projets.¹⁶ La version Windows est sortie 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 Desktop 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 ainsi que le texte visible ou hors écran exposé par l’application, puis stocke la pièce jointe localement dans l’historique de la session.⁹⁹

Pour les travaux web et frontend, commencez par utiliser le navigateur intégré lorsque la page ne nécessite aucune authentification : il vous offre, ainsi qu’à Codex, un aperçu commun de la page affichée, prend en charge des actions dans le navigateur comme les clics, les captures d’écran, le téléchargement de ressources et l’inspection en lecture seule JavaScript, et vous permet d’annoter des zones de la page afin que Codex traite vos commentaires au tour suivant.⁹⁹ Pour les sites nécessitant une connexion, continuez à utiliser l’extension de navigateur (Chrome, Edge, Brave, Opera ou Vivaldi ; Opera ne propose pas de discussion latérale). Outils de site (WebMCP, 25 août 2026) : dans le navigateur intégré de l’application Desktop, ChatGPT Work et Codex peuvent utiliser les outils fournis par un site web pour interagir avec la page ; utilisez GPT-5.6 Sol ou GPT-5.6 Terra avec la dernière version de l’application Desktop, car les outils de site ne sont disponibles ni avec GPT-5.6 Luna, ni dans les espaces de travail Enterprise ou Edu.¹²⁷

N’utilisez Computer Use que lorsqu’une intégration structurée ou l’aperçu du 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 encadrée : Codex peut accéder temporairement aux applications autorisées pendant les tours Computer Use actifs et approuvés après le verrouillage du Mac, avec des protections de reverrouillage et la détection des saisies 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 Desktop : 1. Crée un nouveau git worktree (git worktree add) dans un dossier 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 l’opération 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 dossier de travail.

Paramètres des worktrees et propriété des threads (v0.151.0) : le comportement des worktrees gérés est déterminé à partir de la configuration [desktop] existante par un analyseur de paramètres dédié – la racine des worktrees est définie par défaut sur $CODEX_HOME/worktrees, le nettoyage automatique est activé par défaut et 15 worktrees sont conservés. Les racines configurées, les indicateurs de nettoyage et le nombre d’éléments à conserver sont validés avant utilisation. Chaque worktree lié et géré peut également contenir, dans ses métadonnées Git, un enregistrement de propriété codex-thread.json versionné qui l’associe à un thread : les écritures sont atomiques et sans écrasement (les associations répétées sont idempotentes, tandis que les propriétaires incompatibles sont refusés), et les checkouts principaux, imbriqués ou non gérés sont refusés avant toute modification des métadonnées de propriété.¹³⁵

Les worktrees gérés arrivent dans CLI avec la v0.154.0 (fonctionnalité expérimentale) : --worktree au lancement ou /worktree dans la TUI crée un checkout isolé pour une session nouvelle ou dérivée, codex exec prend en charge les worktrees gérés pour l’automatisation, tandis que les commandes de session de la TUI et un navigateur de worktrees permettent de répertorier, parcourir et reprendre les sessions de worktree (#42196, #42366, #42652, #43069, #43120, #43286). La v0.155.0 ajoute les fonctions de gestion associées, tandis que les worktrees restent désactivés par défaut : la vue d’ensemble des agents permet de masquer, d’archiver et de supprimer les sessions de worktree, affiche les détails de propriété et demande une confirmation avant la suppression d’un worktree géré sans modifications (#43942, #44424, #44433). L’activation par défaut (#44870), fusionnée le 11 septembre, n’était PAS incluse dans la version stable 0.155.0, comme le confirme la vérification de son ascendance par rapport au tag rust-v0.155.0.¹⁵²¹⁵⁶

Les worktrees gérés deviennent la configuration par défaut avec la v0.156.0 : #44870 fait de worktrees une fonctionnalité stable, l’active par défaut et la retire de /experimental. Cette version permet également aux sessions de worktree de se connecter à un daemon local existant au lieu de lancer le leur (#46498), ainsi que de créer des sessions de worktree directement depuis la vue d’ensemble des agents (#45276), qui bénéficie aussi d’onglets de filtrage par état (#46839). Si vos scripts ou configurations partent du principe que les worktrees restent désactivés tant qu’ils ne sont pas demandés, la version 0.156.0 modifie ce comportement. Pour les désactiver : définissez worktrees = false sous [features] dans config.toml (pour une seule exécution : --disable worktrees). Anciens daemons locaux : si la création d’un worktree ou /cd est bloquée avec le message « The local Codex service cannot check background terminals », exécutez codex app-server daemon update, puis redémarrez Codex.¹⁶⁹¹⁷¹

Automatisations

Les automatisations s’exécutent localement dans l’application. Celle-ci doit donc être ouverte et le projet doit être 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 dossier de travail
• Dans les projets sans Git, les exécutions ont lieu directement dans le dossier du projet
• Les automatisations utilisent vos paramètres de sandbox par défaut

Configurer une automatisation : 1. Ouvrez un projet dans l’application Desktop 2. Cliquez sur l’onglet Automatisations dans la barre latérale 3. Définissez un déclencheur (planification, webhook ou lancement 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 le calendrier prévu et placent leurs résultats dans une file d’attente pour examen

Exemples de cas d’utilisation : - Triage des problèmes : classez et hiérarchisez automatiquement les nouveaux problèmes - 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 produisant une analyse diagnostique - Mise à jour des dépendances : recherchez et appliquez les correctifs de sécurité

Les résultats apparaissent dans une file d’attente afin d’être examinés et approuvés par une personne.

Prise en charge de Windows

L’application Codex Desktop est sortie sur Windows le 4 mars 2026 (App v26.304) avec une prise en charge native de PowerShell, une sandbox Windows native et l’ensemble des 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 tâches suivantes.

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.

SDK Codex

Le SDK TypeScript 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 du SDK

• runStreamed(...) : flux d’événements asynchrone pour les mises à jour intermédiaires
• Authentification du SDK Python (v0.132.0+) : la connexion par clé API, les flux de navigateur/code d’appareil ChatGPT, la consultation du compte et la déconnexion sont des parcours SDK de premier ordre.⁹⁷
• Simplification des tours en texte seul (v0.132.0+) : les APIs de tour Python acceptent des chaînes de texte brut et renvoient des métadonnées TurnResult plus riches comprenant les éléments collectés, la durée et l’utilisation.⁹⁷
• outputSchema : impose une sortie finale conforme à la structure JSON
• Entrée multimodale : transmet du texte et des images locales ({ type: "local_image", path: "..." })
• Workflows d’images (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-environnement (v0.130.0) : pour les sessions couvrant plusieurs environnements (introduites dans la v0.124.0 avec la sélection de l’environnement et du dossier de travail à chaque tour, puis affinées dans la v0.125.0 avec des environnements persistants), view_image résout désormais les chemins de fichiers dans l’environnement sélectionné plutôt que dans le système de fichiers local de l’orchestrateur. Une image jointe depuis un environnement distant est récupérée relativement au dossier de travail de cet environnement, et non depuis l’hôte qui exécute le SDK.⁹¹

Configuration du thread 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.

Environnement d’exécution : Node.js 18+.

Optimisation des performances

Gestion du contexte

La taille de la fenêtre de contexte varie selon le modèle. La famille GPT-5.6 actuelle (Sol, Terra, Luna) utilise une fenêtre de 272K ; GPT-5.5, le modèle phare de la génération précédente, offre 400K dans Codex (1M dans l’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 disposait de 272K en entrée + 128K en sortie (budget total de 400K). Toutes se remplissent plus vite que vous ne l’imaginez : gérez-les de manière proactive :

1. Utilisez régulièrement /compact : résume l’historique de la conversation afin de libérer des tokens
2. Fournissez de la documentation locale : un fichier AGENTS.md de qualité et une bonne documentation locale réduisent le travail 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. Rédigez des prompts ciblés : les prompts bien délimités qui indiquent précisément les fichiers consomment moins de contexte qu’une exploration ouverte

Gestion expérimentale du contexte (v0.153.0, désactivée par défaut) : features.context_management.experimental_mode active une pile de contexte coordonnée — contexte limité par un budget de tokens, notes d’historique et outil new_context — pour les sessions ChatGPT Plus, Pro et Pro Lite éligibles qui utilisent le backend Codex. Les sessions avec clé API, les fournisseurs personnalisés, les points de terminaison autres que Codex et les threads structurés temporaires sont exclus. Cette option étant explicitement en cours de développement, considérez-la comme un aperçu de l’évolution de la gestion du contexte, et non comme une base sur laquelle construire des workflows.¹⁴⁰ La v0.154.0 ajoute un contrôle de capacité : l’éligibilité est déterminée au démarrage de la session d’après les capacités du modèle actif (#43147) — la même surface que la documentation des modèles Codex associe nommément à Astra pour les connexions Plus et Pro (consultez la remarque sur les contextes croisés sous « Quel modèle choisir ? »).¹⁴⁶¹⁵² Depuis la v0.157.0, aucun modèle du catalogue intégré n’est signalé comme compatible (#47397) ; avec ce catalogue, ce paramètre n’a donc aucun effet.¹⁷⁴

Efficacité des tokens

Optimisation de la vitesse

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

Comment déboguer les problèmes ?

Problèmes courants et solutions

Référence des messages d’erreur

À quoi sert codex doctor ?

codex doctor est la commande unique à exécuter avant de signaler un bug ou de déboguer une installation défectueuse. Elle rassemble dans un même rapport l’environnement d’exécution local, la configuration, l’authentification, le terminal, le réseau et l’état du système, et le modèle de ticket du projet vous demande de 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, ce qui vous permet d’accéder rapidement à celle dont vous avez besoin :¹⁶³

Chaque vérification comporte un indicateur d’état — ✓ ok, ✗ échec, ⚠ avertissement, ○ inactif — accompagné d’une ligne récapitulative. Avec --json, chaque vérification est indexée par un identifiant stable, ce qui permet de l’utiliser dans un pipeline CI ou un script d’assistance, plutôt que de se limiter à une lecture manuelle.¹⁶³

La commande s’est enrichie au fil des versions : apparue dans la v0.131.0, elle a reçu des rapports sur l’environnement, Git, le terminal, l’app-server et l’inventaire des threads dans la v0.135.0, puis des informations sur l’éditeur et le pager (avec masquage des valeurs sensibles dans JSON) dans la v0.139.0.^96176165

Utilisez-la en premier, pas en dernier. La plupart des signalements indiquant que « Codex est en panne » trouvent leur cause dans un élément que doctor identifie déjà : un mode d’authentification obsolète, un fichier config.toml dont l’analyse a échoué 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 au sein de la session :

/status                                # Token/session overview
/debug-config                          # Show config layers and requirement sources
/compact                               # Summarize history to reclaim context

Remarque : codex --verbose n’est pas un flag général 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 précise, revenir à une version antérieure après une mise à jour défectueuse ou effacer entièrement l’état, consultez Mettre à jour, revenir à une version antérieure ou désinstaller.

Mode de 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 les problèmes sur github.com/openai/codex/issues.¹

Codex Security [APERÇU]

Codex Security est entré en aperçu de recherche le 6 mars 2026, intégrant au stack Codex une analyse de sécurité applicative tenant compte du contexte.⁷⁷ Il est accessible aux clients ChatGPT Pro, Enterprise, Business et Edu via Codex web.

Fonctionnement : Codex Security analyse les dépôts pour construire un modèle de menace propre au projet, repère les vulnérabilités classées selon leur impact réel et soumet les résultats à des tests poussés dans un environnement en sandbox afin de les valider. L’agent présente les résultats les plus fiables avec leurs correctifs, ce qui réduit le bruit provoqué par les bugs insignifiants.

Performances : pendant l’aperçu de recherche, Codex Security a analysé 1,2 million de commits et identifié 10 561 vulnérabilités de sévérité élevée. Sa précision s’est améliorée au fil du temps — avec une réduction du bruit de 84 %, une baisse de plus de 90 % des niveaux de sévérité surestimés et une division par deux du taux de faux positifs. Le système a découvert de véritables vulnérabilités dans OpenSSH, GnuTLS et Chromium, dont 14 ont reçu un identifiant CVE.⁷⁷

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

Déploiement en entreprise

Contrôles administrateur (requirements.toml)

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

La v0.146.0 ajoute la reconnaissance des offres Enterprise et permet aux administrateurs de contrôler les mises à jour intégrées à l’application.¹¹⁴ Sur un parc géré, cela fait toute la différence entre laisser les développeurs mettre à jour eux-mêmes le CLI dès qu’ils remarquent une nouvelle version et permettre à l’administrateur de décider 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’aura pas documenté.

# /etc/codex/requirements.toml

# Restrict which approval policies users can select
allowed_approval_policies = ["on-request", "never"]   # `untrusted` retired in v0.149.0

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