Codex CLI : la référence technique complète

En bref : Codex est un agent de programmation accessible depuis plusieurs interfaces : il lit votre base de code, exécute des commandes dans un bac à sable 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 bac à sable et d’approbation, AGENTS.md, MCP et les skills – et vous démultipliez votre efficacité. Quel modèle choisir : la documentation des modèles d’OpenAI recommande désormais GPT-6.1 Sol pour les tâches complexes de programmation et le travail agentique (gpt-6.1-sol, le modèle fourni par défaut avec CLI depuis la v0.159.1), GPT-6-Astra pour les travaux de bout en bout les plus difficiles, et GPT-6 Luna pour les tâches ciblées et répétables. La disponibilité dépend de l’abonnement, du client et des paramètres de l’espace de travail ; GPT-6 Sol et les modèles GPT-5.6 restent dans le sélecteur, et GPT-5.5 est retiré de Codex pour les connexions via ChatGPT le 14 octobre 2026.^146171178 Vous débutez ? Passez directement à Installation et Démarrage rapide. Vous suivez les nouvelles versions ? La dernière version stable est la v0.164.0 (23 octobre 2026) : dix emplacements /presets pour des prompts réutilisables, des arguments directement dans /model et /permissions, des aperçus d’images dans la transcription en plein écran, la connexion à MCP gérée par l’entreprise et l’assistant de configuration Bedrock activé par défaut ; la section Points forts des versions commence par un état des lieux (ce qui est activé par défaut, ce qui reste expérimental), puis détaille chaque version, et le Journal des modifications répertorie toutes les mises à jour du guide.^116178182183

Codex fonctionne comme un agent de programmation accessible depuis plusieurs interfaces, et non comme un chatbot qui écrit du code. CLI lit votre base de code, exécute des commandes dans un bac à sable, modifie des fichiers, se connecte à des services externes via MCP et délègue les tâches de longue durée au cloud. Il s’exécute localement, mais raisonne à l’échelle globale ; la même intelligence alimente cinq interfaces distinctes selon votre façon de travailler, dont 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 tient à 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 bac à sable et d’approbation : encadre ce que Codex peut faire
3. AGENTS.md : définit les règles de fonctionnement à l’échelle du projet
4. Protocole MCP : étend les capacités aux services externes
5. Système de skills : regroupe une expertise métier réutilisable

J’ai passé des mois à utiliser Codex aux côtés de Claude Code sur des bases de code en production, dans des pipelines CI/CD et au sein des processus de travail d’équipe. Ce guide condense 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 concrets de configuration et des cas limites qui piègent 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 d’accès au système de fichiers et au réseau au niveau du noyau (Seatbelt sur macOS, bubblewrap + seccomp sur 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.1 Sol, 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.1 Sol, GPT-6 Sol et Luna) ; GPT-5.5 fournit 400K dans Codex jusqu’à son retrait de la plateforme le 14 octobre 2026. Utilisez /compact, des prompts ciblés et des références @file pour gérer de manière proactive vos budgets de tokens.^83112178

Comment utiliser ce guide

Cette référence compte plus de 3 300 lignes — commencez par la section qui correspond à 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 versions : les changements récents

L’historique version par version, de la plus récente à la plus ancienne, pour suivre les sorties de Codex. Vous découvrez Codex ? Passez au démarrage rapide ; rien de ce qui suit n’est nécessaire pour commencer à travailler efficacement. Les détails de vérification (comparaisons, listes de commits, vérifications de la documentation) figurent dans les notes de bas de page.

État actuel

Codex CLI au 23 octobre 2026

• Version stable : v0.164.0 (23 octobre, npm latest), issue de 0.164.0-alpha.11 avec un commit de publication supplémentaire (alpha.12 contenait neuf commits absents de la version stable) et 330 commits depuis v0.163.0 : dix emplacements numérotés dans /presets pour des prompts et des slash commands réutilisables, /model [model] --reasoning <level> --speed <tier> et /permissions <profile-id> utilisables directement, aperçus d’images dans la transcription en plein écran sur les terminaux Kitty ou Sixel, autorisation gérée par l’entreprise pour les connexions MCP, masquage des identifiants pour les commandes Bash distantes compatibles (via le paramètre credential_masking) et assistant de configuration Amazon Bedrock activé par défaut. La version précédente, v0.163.0 (15 octobre), avait ajouté le panneau /config avec recherche, la touche de préfixe et Daybreak activé par défaut.
• Version alpha : npm alpha correspond à 0.165.0-alpha.1 (23 octobre, quelques heures après la version stable). À ce tag, reasoning_effort_override est stable et activé, tandis que guardianv3, guardian_recorded_items et tui_multi_backend sont nouveaux et désactivés. La branche 0.164 est passée d’alpha.1 (16 octobre) à alpha.12 (22 octobre), accompagnée des builds hors cycle 0.163.0-alpha.11.1 et 11.2 (21 et 22 octobre), ainsi que 0.164.0-alpha.11.1 (23 octobre).
• Modèle par défaut depuis v0.159.1 : GPT-6.1 Sol remplace GPT-6-Astra, y compris sur Amazon Bedrock. Définissez model dans config.toml pour en conserver un autre. Le catalogue intégré à v0.164.0 est identique octet pour octet à ceux de v0.162.1 et v0.163.0, et répertorie les mêmes modèles que celui de v0.159.1.
• Activés par défaut depuis v0.164.0 : l’assistant de configuration Amazon Bedrock (bedrock_setup_wizard, stable ; bedrock_setup_wizard = false sous [features] le désactive), les mises à jour incrémentales des outils (incremental_tools, stable) et la coordination du renouvellement OAuth pour MCP (mcp_oauth_refresh_coordination, stable). Les worktrees gérés et les conversations en temps réel sont désormais permanents : leurs paramètres sont marqués comme supprimés, mais les fonctionnalités restent activées.
• Activés par défaut depuis v0.163.0 : Daybreak (cli_daybreak, désormais stable ; cli_daybreak = false sous [features] masque les commandes) et l’interruption de Code Mode (code_mode_interrupt, stable), de sorte qu’un message de suivi arrête aussi une cellule Code Mode en cours d’exécution ; les sessions utilisant une clé API bénéficient par défaut des programmes d’accès Cyber (api_key_cyber_access_programs). Paramètres supprimés : shell_zsh_fork et unified_exec_zsh_fork, ignorés avec un avis de migration.
• Activé par défaut depuis v0.162.0 : instant_interrupt, pour qu’une nouvelle saisie interrompe une réponse du modèle (instant_interrupt = false sous [features] le désactive) ; le paramètre reste marqué comme en cours de développement.
• Activée par défaut depuis v0.161.0 : la découverte des modèles avec une clé API (api_key_model_discovery = false sous [features] la désactive).
• Activés par défaut depuis v0.158.0 : l’approbation des saisies dans les terminaux disposant de privilèges élevés (write_stdin_approval = false sous [features] la désactive), ainsi que la copie à la sélection et le collage par clic droit dans la TUI en plein écran (copy_on_select = "never", right_click_paste = "off" sous [tui]). Le contexte du fil Guardian est toujours activé ; thread_context est ignoré.
• Activés par défaut depuis v0.157.0 : la transcription en plein écran (fullscreen_transcript = false sous [tui]) et le démarrage automatique du serveur en arrière-plan (daemon_auto_start = false sous [features], ou --no-daemon).
• Activés par défaut depuis v0.156.0 : /voice, les worktrees gérés et la réutilisation par Guardian de la compaction du fil parent.
• À activer explicitement ou expérimentaux : Codex Cloud, Code Mode et sa recherche d’outils classée par pertinence (code_mode_tool_search, v0.162.0), la récupération de l’historique par Guardian (guardian_conversation_history_tools, v0.160.0) et les paramètres en cours de développement livrés désactivés dans v0.164.0 (depuis v0.163.0 : async_compaction, credential_masking, output_token_replay, retain_client_tool_outputs, subagent_default_context_limits, code_mode_host_grpc, code_mode_tool_description_first, guardian_trust_orchestrator_connectors ; nouveaux dans v0.164.0 : app_server_websocket_compression, executor_capability_discovery_v2, mcp_tool_list_changed, multi_env_copy_file, runtime_agent_instances, subagent_thread_environments, wake_on_agent_messages). La gestion expérimentale du contexte n’est pas disponible actuellement.
• Modèles : GPT-6.1 Sol pour le développement complexe, GPT-6-Astra pour les travaux les plus difficiles, GPT-6 Luna pour les tâches répétables. GPT-6 Sol et Luna démarrent en mode Fast (2,5 fois plus de crédits) ; ce n’est pas le cas de GPT-6.1 Sol. GPT-5.5 quitte Codex le 14 octobre 2026.
• Installation d’une version précise : npm install -g @openai/codex@0.164.0, puis codex --version.^{176178186187188189192193194195}

v0.164.0 (23 octobre 2026)

La branche 0.164 passe en version stable à partir de sa propre alpha. v0.164.0 a été publiée le 23 octobre (04:48 UTC ; npm latest à 04:52 UTC), à partir de 0.164.0-alpha.11 avec un commit de publication supplémentaire ; alpha.12 (22 octobre) comptait neuf commits de plus que cette base, et la version hors cycle 0.164.0-alpha.11.1 (23 octobre, 01:58 UTC) ajoutait quatre commits à la base alpha.11. La comparaison avec v0.163.0 compte 330 commits. Trois paramètres passent à l’état activé et sont marqués comme stables : bedrock_setup_wizard (l’assistant de configuration Amazon Bedrock, où la saisie d’une clé API est regroupée avec les autres méthodes de connexion AWS lorsque des identifiants sont détectés), incremental_tools et mcp_oauth_refresh_coordination. Les paramètres worktrees et realtime_conversation sont marqués comme supprimés, mais leurs fonctionnalités restent activées : les worktrees gérés et les conversations en temps réel ne peuvent donc plus être désactivés ; stable_environment_tools et transcript_v2 sont également supprimés. Sept nouveaux paramètres en cours de développement sont désactivés. Le catalogue de modèles intégré est le même blob que celui livré avec v0.162.1.¹⁹⁴¹⁹⁵

Nouveautés de la TUI. /presets enregistre des prompts et des slash commands réutilisables dans dix emplacements numérotés, avec un menu utilisable au clavier ; un préréglage peut être créé à partir du texte de la zone de saisie ou du modèle, de l’effort de raisonnement et de la vitesse actuels. Les préréglages sont conservés sous tui.presets dans la configuration utilisateur active (#54380, #54381). /model [model] --reasoning <level> --speed <tier> applique le modèle, le raisonnement et la vitesse à la session en cours sans modifier les valeurs par défaut enregistrées ; les valeurs des options peuvent être séparées par un espace ou par =. Si vous omettez le modèle, les paramètres s’appliquent au modèle actuel, et /model seul ouvre toujours le sélecteur (#54378). /permissions <profile-id> sélectionne directement un profil d’autorisations intégré ou personnalisé, comme /permissions :read-only, avec :ask-for-approval et :approve-for-me comme alias (#54383). Sur les terminaux compatibles avec les graphismes Kitty ou Sixel, la transcription en plein écran affiche les images consultées et générées sous forme de vignettes de dimensions limitées ; pour les espaces de travail distants, les terminaux non compatibles et les images trop volumineuses, l’entrée reste purement textuelle (#54216).¹⁹⁴

Connexions et identifiants. Les serveurs MCP configurés directement peuvent s’authentifier au moyen d’autorisations d’entreprise propres au compte, stockées dans le trousseau de clés, ou d’une connexion dédiée, y compris pour les clients OAuth qui nécessitent des secrets ; l’extension d’autorisation gérée par l’entreprise est négociée avec le protocole 2026-07-28, et l’autorisation est révoquée lorsque le propriétaire du compte change ou qu’une connexion d’entreprise remplace l’autorisation accordée (#55334, #55859, #56001). Le masquage des identifiants s’étend aux commandes Bash distantes compatibles et aux sessions utilisant un instantané zsh, y compris pour les identifiants de fournisseurs personnalisés : la commande voit des valeurs de substitution, puis le proxy local à l’exécuteur injecte les véritables identifiants pour les destinations correspondantes. Lorsque le masquage n’est pas disponible, l’exécution se poursuit sans masquage, avec un avertissement ; le paramètre credential_masking reste désactivé à ce tag (#54309, #54432, #56049).¹⁹⁴¹⁹⁵

Correctifs et maintenance. Une compaction échouée ne laisse plus de résumés partiels dans l’historique de conversation, et l’échec d’une compaction en arrière-plan déclenche une solution de repli sans erreur fatale (#53932, #55581). La reprise d’une session retrouve les historiques compressés et restaure les paramètres enregistrés du fil au lieu de les remplacer par les valeurs globales par défaut (#54008, #55923). Sous Windows, les connexions HTTPS et WebSocket répondent aux demandes d’authentification du proxy avec les identifiants Negotiate ou NTLM de l’utilisateur connecté (#55994, #56000). Lorsque -c ou --config est fourni à plusieurs niveaux de sous-commandes, toutes les valeurs de remplacement sont conservées (#56022) ; les prompts en attente attendent qu’une sélection d’autorisations en cours soit terminée (#55682) ; et le bac à sable vérifie les chemins de métadonnées dont la casse varie sous macOS, ainsi que les liens symboliques remplaçables utilisés pour localiser les exécutables (#54273, #55384). L’espace disque occupé diminue : les installations inutilisées sont supprimées (les versions du démon actuellement et précédemment sélectionnées sont conservées), les copies de travail abandonnées de la place de marché sont nettoyées et la taille des journaux du démon est limitée (#53827, #55149, #55689, #55690, #55856) ; l’environnement d’exécution JavaScript intégré bénéficie de contrôles de sécurité pour la version optimisée d’Array.sort (#54519).¹⁹⁴ À faire : passez à la nouvelle version. Aucun paramètre par défaut ne change de façon perceptible, sauf si vous configurez Bedrock pour la première fois : l’assistant se lance désormais automatiquement (bedrock_setup_wizard = false sous [features] le désactive). Si vous aviez défini worktrees ou realtime_conversation sous [features], ces clés sont désormais ignorées.¹⁹⁴¹⁹⁵

v0.163.0 (15 octobre 2026)

La branche 0.163 passe en version stable, depuis une branche hors du cycle principal. La v0.163.0 a été publiée le 15 octobre (21 h 30 UTC ; balise npm latest à 21 h 37 UTC), à partir de 0.163.0-alpha.10.2, une compilation hors du cycle principal fondée sur alpha.10, avec un commit de publication supplémentaire ; l’alpha.11 du cycle principal (14 octobre) comptait 23 commits absents de la version stable, reproduisant le schéma de la 0.158. La comparaison avec la v0.162.1 fait apparaître 232 commits. Deux indicateurs de fonctionnalité sont activés et tous deux passent au statut stable : cli_daybreak (commandes Daybreak, bascule /daybreak et orientation automatique vers le programme d’accès Cyber pour les comptes OpenAI éligibles ; codex exec peut le sélectionner avec une clé API OpenAI lorsque le serveur propose cet accès) et code_mode_interrupt (interrompre un tour arrête également les cellules Code Mode actives et leurs appels d’outils imbriqués). api_key_cyber_access_programs, déjà stable, est activé. instant_interrupt reste activé et toujours en cours de développement.¹⁹²¹⁹³

Nouveautés dans la TUI. /config ouvre un panneau de préférences doté d’une recherche, organisé en onglets Apparence, Notifications, Saisie, Sessions et Sélection de texte ; les modifications prises en charge s’appliquent immédiatement, le panneau indique celles qui nécessitent un redémarrage et les modifications sont enregistrées dans le fichier de configuration local sélectionné (#52990, #53429). /keymap configure une touche préfixe : tui.keymap.global.leader vaut ctrl-x par défaut, des raccourcis tels que leader c l’utilisent comme préfixe, les indications de raccourcis restent affichées jusqu’à votre choix ou votre annulation, et le raccourci de coupure du micro passe de Ctrl+X à F9 (#52273). /daemon peut redémarrer un serveur géré en arrière-plan, en avertissant des tâches que le redémarrage pourrait interrompre, puis en rétablissant la connexion (#53173). Codex exécute en parallèle les outils indépendants en lecture seule : recherches dans les skills, la mémoire et l’historique des conversations, listes des plugins et des agents, heure actuelle, contexte restant et get_goal (#52245). Un message de suivi envoyé pendant que Codex répond le réoriente immédiatement (#51812, #51835).¹⁹²

Correctifs et plateformes. La reprise d’un fil enregistré restaure ses autorisations et ses approbations réseau, sous réserve des paramètres de remplacement explicites et de la politique administrée (#53150, #53419, #53424). Le proxy réseau vérifie l’autorisation avant toute résolution DNS, rejette les en-têtes Host en double et empêche les alias d’identifiants de contourner les hooks d’inspection (#51650, #52661, #53506). /side revient à une conversation latérale existante après un changement de fil, et les réponses aux questions en attente sont renvoyées au fil qui les a posées (#52184, #53436). Sous Windows, Ctrl+V et Shift+Insert collent aussi bien du texte que des images ; sous WSL, les collages répétés réutilisent le lecteur du presse-papiers et les tentatives de copie expirent au lieu de rester bloquées (#53224, #52967, #53453). Les commandes locales se terminent rapidement lorsqu’un processus enfant garde un tube de sortie ouvert, les commandes distantes conservent les sorties tardives pour la dernière interrogation, et codex exec ne répète plus le diff d’un fichier après une commande sans rapport (#52652, #53331, #53622, #53444).¹⁹²

La version modifiée de zsh a été supprimée. Codex utilise son exécuteur de shell standard et n’intègre plus de version modifiée de zsh ; codex-execve-wrapper et la crate shell-escalation ont également été supprimés, shell_zsh_fork et unified_exec_zsh_fork sont ignorés avec un avis de migration, et les exigences administrées qui les mentionnent encore déclenchent un avertissement (#52160, #52213). Les paquets Linux et macOS sont plus petits, les symboles ayant été retirés des binaires distribués (#52178). Les noms et le README de la crate du bac à sable Linux décrivent désormais ce que celui-ci faisait déjà : bubblewrap pour l’isolation du système de fichiers et des espaces de noms, seccomp pour le filtrage des appels système, l’implémentation Landlock étant conservée à titre historique ; l’application des restrictions n’a pas changé (#52610). Les instructions OpenAI Docs intégrées couvrent les migrations vers la famille GPT-6 (#51768).¹⁹²¹⁹³

À faire : passez à la nouvelle version. Si un fichier config.toml ou requirements.toml mentionne shell_zsh_fork ou unified_exec_zsh_fork, supprimez cette entrée ; si vous aviez activé Daybreak manuellement, l’indicateur n’est plus nécessaire ; et si vous utilisiez Ctrl+X pour couper le micro dans /voice, le raccourci est désormais F9.¹⁹²

v0.162.1 (9 octobre 2026)

Deux correctifs, trois commits supplémentaires par rapport à la v0.162.0. Un plantage de la TUI sur les questions asynchrones comportant plusieurs lignes est corrigé, avec conservation des sauts de ligne et des destinations complètes des hyperliens. Les échecs au démarrage rencontrés par certains utilisateurs de la v0.162.0, causés par des différences entre les paramètres de fonctionnalité d’un serveur en arrière-plan en cours d’exécution et les valeurs par défaut de CLI, sont également résolus : la vérification de compatibilité ne s’applique désormais qu’aux paramètres de fonctionnalité explicitement remplacés en ligne de commande. Aucun changement des valeurs par défaut, des clés de configuration ou des modèles.

À faire : passez à la nouvelle version, surtout si la v0.162.0 refusait de démarrer alors qu’un serveur en arrière-plan d’une version antérieure était en cours d’exécution.¹⁸⁸

v0.162.0 (8 octobre 2026)

instant_interrupt est activé par défaut. Cet indicateur, proposé sur activation explicite dans la v0.159.0, permet à une nouvelle saisie d’interrompre une réponse du modèle ou de faire céder la main à un appel de longue durée en mode code. Il est activé pour tout le monde à partir de cette version (PR #51812, fusionnée le 7 octobre) ; il reste marqué comme étant en cours de développement. Définissez instant_interrupt = false sous [features] pour rétablir l’ancien comportement, où le texte saisi attend la fin de la réponse.

Nouveautés dans la TUI : des outils permettant de créer et de lister des worktrees Git gérés à partir de projets locaux de confiance, lorsque la fonctionnalité worktrees est activée, afin que le modèle puisse ouvrir lui-même un worktree (#50148) ; l’épinglage dans le Command Center des agents avec p, qui conserve les tâches épinglées dans un groupe partagé « Épinglées » lorsque le serveur le prend en charge (#51500) ; /copy permet de parcourir les blocs de la transcription, Ctrl+Insert copie une sélection et tui.mouse_scroll_speed (un nombre positif fini, 1,0 par défaut) règle le défilement à la molette (#50434, #50215, #50209) ; les URL sont cliquables dans les en-têtes d’approbation, les questions, les invites MCP, les avertissements et les bannières, y compris les liens qui s’étendent sur plusieurs lignes. Les nouveaux fils de la TUI respectent les valeurs par défaut du serveur pour le modèle et le résumé du raisonnement, tout en conservant les paramètres explicitement définis au lancement. codex doctor indique le mode TUI configuré, et /status affiche à nouveau l’adresse e-mail du compte après une mise à jour de celui-ci.

Fournisseurs et modèles : un fournisseur personnalisé compatible avec Responses peut déclarer external_web_access et remote_compaction sous [model_providers.<name>.capabilities] (#50459). La fonctionnalité ultrafast_mode est activée, de sorte qu’un catalogue de modèles annonçant un niveau Ultra Fast (les modèles Astra d’Amazon Bedrock, #50472) peut le proposer indépendamment du mode Fast ; le catalogue intégré à cette version ne répertorie aucun niveau de ce type. Le mode code gagne des fonctions utilitaires JavaScript pour diffuser progressivement les résultats des promesses et une recherche d’outils avec classement, à activer explicitement (code_mode_tool_search). apply_patch conserve toujours les fins de ligne CRLF existantes, et l’indicateur apply_patch_preserve_line_endings est supprimé. Les échecs de Responses et de WebSocket pouvant faire l’objet d’une nouvelle tentative respectent l’indication Retry-After du serveur.

Bac à sable et plateformes : le démarrage du bac à sable Linux lorsque plusieurs fichiers sont interdits est corrigé, les exécutables servant à construire le bac à sable sont rejetés s’ils sont modifiables, et la configuration de ripgrep ne peut plus affaiblir les motifs glob d’exclusion ; Windows 10 retrouve l’accès habituel aux fichiers par lettre de lecteur, les autorisations temporaires du bac à sable correspondent à celles du processus enfant, la vérification des sommes de contrôle des archives fonctionne avec les chemins de modules PowerShell 7, et les versions Windows incluent un programme d’installation PowerShell signé.

À faire : passez à la nouvelle version ; si vous comptiez sur la possibilité de saisir du texte à l’avance sans interrompre le modèle, définissez instant_interrupt = false.¹⁸⁷¹⁸⁹

v0.161.0 (7 octobre 2026)

Issue de 0.161.0-alpha.13.1 avec un commit de publication supplémentaire, cette version compte 155 commits de plus que la v0.160.1. Ses notes de version présentent GPT-6.1 Sol comme le nouveau modèle par défaut (#49318, #49339), mais il s’agit des modifications du catalogue déjà livrées dans la v0.159.1 : le fichier models.json intégré à cette version est identique octet pour octet à celui de la v0.160.1. Rien ne change donc pour les utilisateurs de la 0.159.1 ou d’une version ultérieure.

Nouveautés : /mcp login <name> permet de vous connecter à un serveur MCP depuis une session de terminal en cours (#49290). Sélection des périphériques audio : choisissez votre microphone, votre haut-parleur et les canaux d’entrée du microphone pour les conversations /voice, avec enregistrement local des préférences (#49437, #49836). La découverte des modèles par clé API est activée par défaut (api_key_model_discovery, promu au statut stable, #49807) : lorsque vous vous connectez avec une clé API OpenAI à un point de terminaison compatible, Codex actualise le catalogue de modèles depuis API au lieu de s’appuyer uniquement sur la liste intégrée ; api_key_model_discovery = false sous [features] désactive cette fonctionnalité, et le changement prend effet dans une nouvelle session. Amazon Bedrock prend en charge le multi-agent V2 et le raisonnement Ultra sur les modèles compatibles, et Bedrock Mantle accepte les régions AWS GovCloud (#49345, #49813). Daybreak (activation facultative). Un nouveau flag cli_daybreak, désactivé par défaut et en cours de développement, ajoute des commandes Daybreak à CLI : une commande /daybreak pour l’activer ou le désactiver, des indicateurs et un routage automatique vers le programme d’accès Cyber, pour les connexions ChatGPT utilisant le fournisseur OpenAI dont le compte et le catalogue de modèles indiquent qu’ils le prennent en charge. Activez-le avec --enable cli_daybreak ou cli_daybreak = true sous [features] ; une préférence daybreak = true enregistrée ne suffit pas à elle seule. Indépendamment de ce flag, codex exec --cyber-access-program <standard|daybreak_blue|daybreak_red> (ainsi que cyberAccessProgram de SDK TypeScript) demande un programme d’accès Cyber pour un seul tour, que le flag soit activé ou non, sans modifier le choix enregistré (#49856 à #49861, #49939, #51207). Le catalogue intégré contient déjà les entrées masquées gpt-daybreak-blue-latest et gpt-daybreak-red-latest. Activé par défaut et déclaré stable depuis la v0.163.0.¹⁹³

Correctifs : une élévation approuvée des permissions du système de fichiers peut accorder un accès en écriture plus large tout en maintenant les interdictions de lecture et les restrictions réseau, et les tâches en arrière-plan conservent les permissions du tour qui les a lancées ; les permissions de lancement explicites sont conservées après une reconnexion au terminal ; les sessions de terminal Windows avec élévation de privilèges peuvent démarrer avec un serveur intégré ; la touche Entrée envoie la saisie mise en tampon une fois le délai de détection du collage expiré, y compris en mode insertion Vim ; la reprise d’un fil inclut le dernier historique enregistré, et le démarrage détecte plus tôt les corruptions SQLite récupérables, en conservant les bases de données endommagées comme sauvegardes ; les nouvelles tentatives de Responses et le repli de WebSocket vers HTTP respectent les consignes de nouvelle tentative du serveur. La documentation sur l’authentification précise désormais que les identifiants peuvent être stockés dans le trousseau de clés, plutôt que systématiquement dans auth.json.

Que faire : mettez à jour. Rien ici ne modifie un comportement par défaut que vous pourriez remarquer, sauf si vous vous connectez avec une clé API ; dans ce cas, consultez /model pour voir le catalogue découvert.¹⁸⁶¹⁸⁹

v0.160.1 (5 octobre 2026)

Un correctif pour les serveurs MCP distants sous Windows. Lorsque Codex, sur un hôte macOS ou Linux, lance un serveur MCP stdio sur un exécuteur Windows distant et que la configuration de ce serveur définit explicitement des variables d’environnement distantes, Codex transmet désormais aussi SYSTEMROOT, TEMP et TMP, afin que le processus Windows conserve l’environnement nécessaire à son démarrage. Les variables que vous n’avez pas demandées, y compris les secrets, restent exclues. Cette version consiste en un seul rétroportage appliqué à la v0.160.0 et ne modifie aucun comportement par défaut, aucune clé de configuration ni aucun modèle.

Que faire : mettez à jour si vous utilisez des serveurs MCP stdio distants sur un exécuteur Windows depuis un hôte Unix.¹⁸³

v0.160.0 (1 octobre 2026)

La version stable de la branche 0.160, issue de la 0.160.0-alpha.6.1 avec un rétroportage supplémentaire. Aucun changement des comportements par défaut. Le catalogue de modèles intégré au tag est identique octet pour octet à ceux des v0.159.1 et v0.159.2 : GPT-6.1 Sol reste donc le modèle par défaut, et les deux nouveaux flags de fonctionnalité sont livrés désactivés. Le rétroportage (#49763) a aligné la version candidate 0.160 figée, dont la branche avait été créée avant la v0.159.1, sur la branche de maintenance 0.159 : ajout de GPT-6.1 Sol aux catalogues intégré et Amazon Bedrock, ainsi que des rappels de sécurité du compte de la v0.159.3. Sans lui, la 0.160 aurait été publiée sans GPT-6.1 Sol.

Ajouts facultatifs à Guardian (tous deux en cours de développement et désactivés par défaut) :

• Guardian peut lire les messages précédents de l’utilisateur. Définissez guardian_conversation_history_tools = true sous [features]. Lorsque Apps est activé, l’agent de vérification accède à user_message.search_messages et à user_message.read_messages via la connexion Apps propre à la session parente. Il peut ainsi vérifier les instructions antérieures, les restrictions et les permissions révoquées avant d’approuver une action ayant des effets de bord. Chaque appel vérifie à nouveau la politique actuelle de la session parente concernant les applications et les outils. Les réponses sont limitées par défaut à une estimation de 4 000 tokens (auto_review.conversation_history_max_output_tokens), et auto_review.experimental_conversation_history_prompt remplace les instructions de récupération intégrées.
• Contexte de la session racine tenant compte des transferts (guardian_root_handoff_context) : lorsque Guardian examine l’action d’un agent exécutant, il sélectionne les trois messages de la session racine précédant chaque transfert à cet agent ou à ses ancêtres, ainsi que les trois messages les plus récents de la session racine, afin qu’une annulation récente reste visible.

Toujours actif : les messages chiffrés des agents apparaissent désormais dans les transcriptions de Guardian, dans l’ordre, au lieu d’être omis.

Changements de la TUI : dans un dossier sans configuration de projet ni décision de confiance enregistrée, une nouvelle session peut démarrer avec les permissions workspace-write et des approbations granulaires, mais uniquement si l’exécution locale, votre configuration et la politique administrée l’autorisent toutes. Les sessions reprises restaurent leurs permissions enregistrées, sauf si vous les remplacez, et /cd peut demander si vous faites confiance au dossier, avec une option « Conserver le répertoire actuel ». Le centre de commande des agents dispose d’une ligne « Afficher plus » qui charge les tâches plus anciennes par lots de dix. Dans les terminaux locaux Linux X11 (hors Wayland, SSH, tmux, WSL et VS Code), les sélections effectuées dans la transcription en plein écran sont placées dans la sélection primaire, et le clic du milieu les colle dans la zone de saisie. La ligne d’état en plein écran affiche Plan mode (shift+tab to cycle) lorsque l’espace le permet. Les offres Pro portent désormais les noms « Pro 100 », « Pro 200 » et « Pro 500 » dans /status et les données analytiques. Les conseils au démarrage renvoient vers l’application de bureau de votre plateforme plutôt que vers des promotions pour les abonnements ou le mode Fast, et les messages en attente qui n’avaient jamais été envoyés sont repris après une reconnexion, sans doublons.

Fournisseurs et connexions : la TUI conserve les paramètres de fournisseur, de résumé du raisonnement et de verbosité d’un serveur d’application, affiche les bonnes sessions dans l’historique de reprise et de bifurcation, et masque les paramètres de résumé du raisonnement dans /status pour les connexions au serveur. Un fournisseur doté d’un catalogue de modèles explicite (model_catalog_url) utilise désormais uniquement ce catalogue : aucun modèle intégré n’y est ajouté, les métadonnées correspondent exactement à l’identifiant du modèle, un échec d’actualisation supprime les entrées en cache au lieu de les réutiliser, et un démarrage sans modèle disponible signale une erreur de configuration, sauf si model est défini. Lorsqu’un filtre de contenu interrompt une réponse, la nouvelle tentative demande au modèle d’expliquer la limitation, de proposer une solution autorisée et de poursuivre les autres travaux.

Correctifs : solutions de repli PowerShell dans le bac à sable Windows, réparation des ACL pour les longs chemins d’exécution et suppression des fenêtres de console ouvertes par les processus auxiliaires en arrière-plan ; les sous-agents conservent les environnements encore en cours de démarrage ; SQLite ne se bloque plus lors de l’établissement de la connexion et signale les erreurs d’initialisation au lieu de dépassements de délai. La base de données des journaux récupère l’espace inutilisé en arrière-plan, et le chargement des plugins met en cache les manifestes analysés et réutilise les connexions HTTP. La documentation des fournisseurs précise désormais que les identifiants requires_openai_auth utilisent le backend choisi par cli_auth_credentials_store, et que env_key désigne la variable d’environnement contenant la clé API.

Que faire : mettez à jour. Si un fournisseur personnalisé définit model_catalog_url, assurez-vous que son catalogue répertorie tous les modèles que vous sélectionnez.¹⁸²

v0.159.3 (30 septembre 2026)

Rappels facultatifs de sécurité du compte. Les sessions TUI locales connectées avec ChatGPT via le fournisseur OpenAI peuvent afficher une bannière que vous pouvez fermer, vous invitant à terminer la configuration de la sécurité de votre compte, avec un bouton qui ouvre chatgpt.com. Le serveur décide à qui l’afficher ; CLI récupère l’avis en arrière-plan sans bloquer de tour, n’affiche rien lorsque l’état est inconnu, exclut les espaces de travail distants et les comptes FedRAMP, et mémorise la fermeture de la bannière d’un fil à l’autre et après les reconnexions. Les bannières d’utilisation ont la priorité. C’est le seul changement de cette version, et la v0.160.0 contient le même code.

Que faire : rien. Le rappel est facultatif.¹⁸⁴

v0.159.2 (29 septembre 2026)

Un correctif Windows pour les fenêtres de console qui apparaissent brièvement. Sous Windows, Codex n’ouvre plus de fenêtre de console à chaque lancement d’un processus en arrière-plan. Cela concerne les commandes de l’outil shell, les hooks, les appels à Git et npm, les actualisations des identifiants Amazon Bedrock exécutées sans terminal, les vérifications de diagnostic, les actualisations de la configuration du bac à sable et les commandes dans l’ancien bac à sable Windows. Les commandes qui ont besoin de votre terminal continuent d’hériter de sa console. Cette version consiste en un seul rétroportage de deux correctifs de la branche main, publié environ trois heures et demie après la v0.159.1. Elle ne modifie aucun comportement par défaut, aucune clé de configuration ni aucun modèle, et le nouvel utilitaire de lancement se comporte comme auparavant sous macOS et Linux.

Que faire : sous Windows, mettez à jour si des fenêtres de console apparaissent brièvement pendant que Codex travaille, en particulier si le serveur en arrière-plan est installé.¹⁸⁰

v0.159.1 (29 septembre 2026)

GPT-6.1 Sol devient le modèle par défaut. Lorsque config.toml ne définit aucun modèle, CLI démarre désormais avec GPT-6.1 Sol (gpt-6.1-sol) au lieu de GPT-6-Astra, et GPT-6.1 Sol remplace GPT-6 Sol comme modèle par défaut dans les catalogues Amazon Bedrock Mantle et Runtime. Le sélecteur /model le présente en premier, avec la description « Dernier modèle polyvalent pour le développement et le travail quotidien », suivi de GPT-6-Astra, de GPT-6 Sol (désormais décrit comme « Modèle polyvalent de génération précédente »), de GPT-6 Luna et des modèles plus anciens. Les choix enregistrés ne sont pas migrés : une configuration qui indique gpt-6-sol ou gpt-6-astra conserve ce modèle, et les invites de migration pour les anciennes sélections GPT-5 renvoient toujours vers GPT-6 Sol ou GPT-6 Luna. La documentation d’OpenAI a ajouté le modèle le jour même et le recommande désormais pour les tâches de programmation complexes et les workflows agentiques : « des performances proches d’Astra pour les tâches complexes, à un coût inférieur à celui d’Astra ». Son tarif est de 50 crédits par million de tokens en entrée (2,5 pour les tokens en cache, 250 en sortie), et la plage d’utilisation de Plus est de 15 à 160 messages. Deux détails du catalogue diffèrent de GPT-6 Sol : aucun niveau de service n’est défini par défaut, si bien qu’une session démarre à la vitesse Standard plutôt que Fast, et son effort de raisonnement par défaut est low plutôt que medium. Le déploiement initial concerne Plus, Pro, Business, Enterprise et Edu ; pour Enterprise et Edu, le modèle reste désactivé tant qu’un administrateur ne l’active pas, et Free et Go ne sont pas inclus au lancement.

À faire : mettez à jour, puis vérifiez le modèle dans /status. Si votre compte n’a pas encore accès à GPT-6.1 Sol, fixez un modèle disponible avec model dans config.toml ou avec -m.¹⁷⁸

v0.159.0 (29 septembre 2026)

Issue de 0.159.0-alpha.13, environ 27 heures après v0.158.0. Plusieurs éléments de ses notes de version avaient déjà été livrés dans v0.158.0 sous forme de rétroportages : les correctifs de la fenêtre de console et du lanceur sous Windows, la copie préservant le Markdown, l’écran d’accueil et les conseils pendant les tours, ainsi que les correctifs de connexion. Le paramètre tui.prompt_suggestions, indiqué comme supprimé dans les notes, n’a jamais figuré dans une version stable.

Nouveautés de cette version :

• instant_interrupt (sur activation, en cours de développement) : une nouvelle saisie interrompt une réponse du modèle ou fait rendre la main à un appel code-mode de longue durée. Définissez instant_interrupt = true sous [features] pour l’essayer. Activé par défaut depuis v0.162.0.
• Le panneau des avertissements efface ceux que vous avez consultés à sa fermeture ; appuyez sur k pour en conserver un pour plus tard.
• Vous pouvez faire défiler l’historique de la conversation pendant que vous décidez de mettre en œuvre ou non un plan.
• Le rendu Mermaid prend en charge davantage de liaisons, de libellés et de groupes de nœuds dans les organigrammes.
• Les sessions vides conservent leurs brouillons lorsque vous changez de tâche, et les fils peuvent être archivés avant leur premier tour.
• /status s’affiche sans bordures et renvoie les valeurs longues à la ligne.
• Les clients app-server peuvent paginer l’historique d’un fil à partir d’un élément précis.

Modifications du bac à sable : les commandes approuvées restent soumises aux interdictions explicites d’accès au système de fichiers, les dossiers .aws situés sous les racines accessibles en écriture sont protégés par défaut (les règles explicites restent prioritaires), les bacs à sable macOS avec accès réseau autorisent la vérification de la confiance TLS, et les environnements d’exécution nécessitant un proxy en reçoivent désormais un. Le skill plugin-creator fourni est supprimé.

À faire : si une tâche exécutée dans le bac à sable écrit sous .aws, attendez-vous à ce qu’elle soit bloquée, sauf si vous ajoutez une règle explicite.¹⁷⁷

v0.158.0 (28 septembre 2026)

La version stable de la branche 0.158, issue de 0.158.0-alpha.15.4 : alpha.15 plus seize rétroportages, dont les quatre correctifs Windows de v0.157.1. Elle compte 207 commits de plus que v0.157.0.

Valeurs par défaut qui changent :

• L’approbation des saisies dans le terminal est activée. Lorsque Codex envoie une saisie à une commande en cours d’exécution disposant de permissions élevées (autorisations supplémentaires, contournement du bac à sable ou politique modifiée depuis le démarrage de la commande), cette saisie doit d’abord être approuvée. Les autorisations limitées à l’exécution, telles que celles utilisées par les plugins pour les métriques, ne déclenchent plus de vérification. Pour désactiver cette fonctionnalité, définissez write_stdin_approval = false sous [features].
• Copie à la sélection dans l’historique en plein écran : les sélections à la souris sont copiées lorsque vous relâchez le bouton. La valeur par défaut, auto, exclut les terminaux directs qui transmettent leur propre raccourci de copie (Ghostty 1.2+, Kitty sur macOS, Windows Terminal et VS Code sur Windows). Les copies conservent la mise en forme Markdown. Définissez copy_on_select = "never" (ou "always") sous [tui].
• Collage par clic droit dans la TUI en plein écran sous Windows, WSL et Linux. Définissez right_click_paste = "off" sous [tui], ou "on" pour ajouter macOS.
• Le contexte du fil pour Guardian est toujours activé. L’option de désactivation de v0.157.0 disparaît : thread_context sous [features.guardianv2] est ignoré, y compris dans les profils, et Codex affiche un avis vous demandant de le supprimer.

Modèles et offres : GPT-5.4 quitte les catalogues intégré et Bedrock, et les sélections enregistrées de GPT-5.4 continuent de déclencher l’invite de migration vers GPT-6 Sol. Codex reconnaît l’offre Pro Max et nomme les niveaux Pro « Pro », « Pro (More) » et « Pro (Max) ». Les raccourcis de raisonnement permettent d’atteindre Max.

Autres nouveautés : les serveurs MCP nécessitant un secret client OAuth préenregistré (codex mcp add --oauth-client-secret), les jetons bearer pour les connexions WebSocket d’exec-server, les arrière-plans transparents pour les images générées et les aperçus de commandes sur plusieurs lignes dans /ps. Les correctifs concernent les échecs du bac à sable Windows (chemins ordinaires sous Windows 10, identifiants enregistrés rejetés, politiques de permissions volumineuses), le démarrage du bac à sable Linux avec des racines accessibles en écriture imbriquées, la protection des métadonnées Git entre les racines accessibles en écriture, les alias de chemins macOS dans les approbations de correctifs, ainsi que les vérifications Guardian, qui réessaient désormais au lieu de s’interrompre lorsque vous envoyez un message en cours de vérification.

À faire : si une automatisation envoie des frappes à des commandes disposant de permissions élevées, attendez-vous à des demandes d’approbation ou désactivez la fonctionnalité, et supprimez thread_context de votre configuration.¹⁷⁶

v0.157.1 (26 septembre 2026)

Une version corrective pour Windows regroupant quatre correctifs rétroportés depuis la branche principale. Codex n’ouvre plus de fenêtre de console lorsqu’il démarre l’hôte code-mode ou un serveur MCP stdio local. Le serveur en arrière-plan peut démarrer lorsque Windows maintient le processus dans un objet job englobant, et un serveur détaché en arrière-plan ne garde plus ouverts les tubes de sortie du lanceur, ce qui pouvait laisser la commande appelante en attente après la fermeture du lanceur. Les notes de version GitHub et l’entrée du journal des modifications indiquent seulement que les points marquants « n’ont pas pu être déterminés » ; la liste ci-dessus provient des commits de cette version.

À faire : mettez à jour si vous utilisez Codex sous Windows. Les quatre correctifs concernent uniquement Windows.¹⁷⁴

v0.157.0 (25 septembre 2026)

La version qui change trois autres valeurs par défaut.

• L’historique en plein écran est activé par défaut. L’interface en plein écran proposée par v0.156.0 via /tui est désormais celle qui s’ouvre au démarrage d’une session, même lorsque la configuration ne comporte pas de section [tui]. Pour conserver l’historique de défilement du terminal, choisissez Scrollback dans /tui ou définissez fullscreen_transcript = false sous [tui] ; --no-alt-screen et tui.alternate_screen = "never" restent prioritaires. Maj-clic étend désormais une sélection dans l’historique.
• Le serveur en arrière-plan démarre automatiquement pour les lancements interactifs éligibles, et l’option quitte /experimental. Les lancements avec --no-daemon, --oss, --profile ou la plupart des surcharges -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 fonctionner 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 du fil pour Guardian est activé par défaut pour les vérifications synchrones et asynchrones, indépendamment du commutateur enabled de Guardian v2. Pour le désactiver, définissez thread_context = false sous [features.guardianv2].

Modèles : GPT-6 Sol et Luna, livrés pour la première fois dans v0.156.1, figurent aussi dans cette version, et les catalogues Amazon Bedrock les proposent désormais, GPT-6 Sol remplaçant GPT-5.6 Sol comme modèle par défaut de Bedrock. GPT-5.6 Sol perd son niveau de service ultrafast, ce qui laisse Fast. 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 crée une branche d’une conversation ouverte dans une autre application, en conservant les brouillons et les prompts en attente ; /import fonctionne dans les sessions distantes et celles utilisant le serveur en arrière-plan ; et le terminal affiche les puces Unicode, les cases à cocher et les équations alignées. Les correctifs maintiennent les conversations vocales lorsque vous changez de fil, 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 via les proxies configurés, relancent les téléversements de fichiers après une erreur passagère avec un délai d’expiration 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 bac à sable est limité à la session de connexion du processus d’exécution.¹⁷⁴

v0.156.1 (23 septembre 2026)

Une version corrective ne comportant qu’un changement, qui apporte GPT-6 Sol et GPT-6 Luna à la version stable de CLI. Tous 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 n’en définit aucun. Le sélecteur présente désormais la famille GPT-5.6 comme des modèles plus anciens (GPT-5.6 Sol porte la mention « 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 d’utilisation, l’invite de changement suggère désormais 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 renvoient vers GPT-6 Sol, tandis que gpt-5.6-luna et gpt-5.4-mini renvoient 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 par défaut de Bedrock.

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, qui, avec une connexion ChatGPT, consomme 2,5 fois les crédits du mode Standard. Vérifiez avec /fast status ; /fast off permet de passer à Standard. Que faire : effectuez la mise à jour, puis essayez codex -m gpt-6-sol sur une tâche que vous connaissez bien. La disponibilité dépend de votre abonnement, 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 modifie trois paramètres par défaut à la fois ; le journal des modifications de la documentation a annoncé les deux premiers le même jour.

• La voix est activée par défaut. /voice démarre une conversation en direct sur les versions compatibles, sans passer par /experimental. Autres nouveautés associées : une touche F8 configurable pour activer ou désactiver la voix, un sélecteur /voice settings pour choisir la voix des prochaines conversations, des environnements d’exécution vocale 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 d’indicateur de fonctionnalité. Les sessions de worktrees peuvent se rattacher à un daemon local existant et être créées depuis la vue d’ensemble des agents.
• La réutilisation de la compaction du fil parent par Guardian est activée par défaut : lorsque Guardian redémarre une session de révision, il peut réutiliser la compaction chiffrée du fil parent.

Les instructions de désactivation figurent dans les lignes /voice et /worktree du tableau des slash commands, ainsi que dans la section Guardian.

Autres nouveautés : une TUI plein écran facultative, sélectionnable avec /tui, avec recherche dans la transcription, sélection et copie à la souris, copie par clic droit, liens cliquables et 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 formules mathématiques TeX dans le terminal, chacun disposant de sa propre option d’activation ; un menu /daemon et une option --no-daemon ; enfin, les résumés de raisonnement sont désactivés par défaut pour les nouveaux fils de la TUI. Des correctifs de sécurité comblent des failles du bac à sable sous Windows liées au trafic entrant, aux sockets privilégiés et aux descripteurs de fichiers en lecture seule, et codex doctor n’affiche plus les valeurs de configuration dans ses erreurs. Des corrections de bogues préservent les réponses diffusées en continu après des tours échoués ou interrompus, rétablissent la transmission du presse-papiers dans tmux et SSH, restaurent le mode Plan à la reprise et permettent à la connexion de se rétablir via les proxys système.¹⁶⁹

v0.155.1 (18 septembre 2026)

Un correctif d’urgence limité à une seule correction. Dans la version 0.155.0, un nouveau fil local de la TUI sans model_reasoning_summary dans la configuration demandait des résumés detailed, et les fournisseurs ne prenant pas en charge les résumés de raisonnement rejetaient purement et simplement la requête. La version 0.155.1 rétablit none comme valeur de repli : 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, puis publiée dans la version 0.156.0.

Que faire : si les nouvelles sessions de la TUI en version 0.155.0 échouaient avec un fournisseur autre qu’OpenAI ou un fournisseur auto-hébergé, effectuez la mise à jour. Si vous souhaitez 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 à activer manuellement : /voice ouvrait une conversation en direct avec une transcription en continu et des commandes de microphone, activée via /experimental sur les versions compatibles, avec un raccourci configurable pour couper le microphone et des ressources vocales signées dans les paquets macOS. La version 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 pour MCP : vérification par Touch ID des requêtes MCP, signée par la Secure Enclave, dans les sessions locales de la TUI sur les Mac compatibles, avec restriction d’identité à l’échelle de l’espace de travail et vérification native lors de la poursuite des appels d’outils MCP.
• La slash command Windows /sandbox-add-read-dir est supprimée.
• Gestion des worktrees : masquez, archivez et supprimez les sessions de worktrees dans la vue d’ensemble des agents, consultez les informations de propriété et confirmez la suppression d’un worktree géré sans modifications.
• Les résumés de raisonnement en direct s’affichent en continu dans la ligne d’état de la TUI, avec un horodatage de fin pour les travaux terminés.
• Daemon : calendriers de mise à jour configurables, commande codex app-server daemon update et récupération des fils après le redémarrage du daemon.
• Commandes d’identifiants AWS pour Amazon Bedrock, et publication de Python SDK alignée sur les versions stables de CLI.

Des correctifs de sécurité empêchent les sorties du bac à sable via l’interopérabilité WSL et l’exposition d’identifiants par les instantanés du shell. Memory v2 apporte uniquement les bases du stockage et de la consolidation, sans constituer encore une fonctionnalité utilisable.¹⁵⁶

v0.154.0 (9 septembre 2026)

Cette version a été finalisée à peu près au stade de la version 0.154.0-alpha.6 ; tout ce qui est apparu pour la première fois dans alpha.7 (voix en direct dans la TUI, vérification de l’utilisateur pour MCP, Memory v2, configuration de la mise à jour automatique du daemon, fixation du niveau d’effort de raisonnement) a donc attendu la version 0.155.

Suppressions : 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 mécanismes de révision des approbations par Guardian ont également été supprimés, 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 dans le fil pendant que Codex continue de travailler, sans perdre votre brouillon.
• Prise en charge des services Windows : provisionnement du bac à sable, daemon app-server sous Windows et mises à jour gérées du daemon.
• Profils d’autorisations distants, récupérés auprès du serveur d’application et sélectionnables par nom dans la TUI.
• Mode de remplacement Vim R, état de la compaction du contexte en direct et gestion expérimentale du contexte conditionnée aux capacités du modèle au démarrage de la session.

Sécurité : les utilitaires PATH ne s’exécutent plus avant que l’espace de travail soit déclaré fiable, et le bac à sable macOS est renforcé contre l’injection d’entrées dans le terminal. Les connexions MCP coordonnent le renouvellement des jetons OAuth, la reprise et la duplication à distance 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é livrée que sous forme d’infrastructure d’exécution, et les premières références à Daybreak sont apparues dans le code sans documentation publique.¹⁵²¹⁵³

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

Ces correctifs publiés le même jour ont accompagné le lancement de GPT-6-Astra dans CLI. La version v0.153.3 a ajouté Astra aux catalogues Amazon Bedrock (GPT-5.6 Sol est resté le modèle par défaut de Bedrock) et corrigé les consignes d’Astra concernant les demandes de clarification asynchrones. La version 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 conditionné les consignes relatives aux questions asynchrones à la disponibilité des outils.

Que faire : Astra fonctionne avec -m gpt-6-astra à partir de la version v0.153.1 et apparaît dans le sélecteur à partir de la version v0.153.4 ; aucune version minimale de CLI n’est documentée, considérez donc ces versions comme les seuils minimaux. Si votre compte n’a pas accès au modèle sélectionné par défaut, définissez explicitement model dans config.toml plutôt que de vous en remettre au choix par défaut.^145146147148

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

La version v0.153.1 fait respecter les exigences du modèle lors de l’évaluation de l’utilisation de l’ordinateur par Guardian : l’évaluation limitée à 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. Un changement de modèle qui désactive l’évaluation invalide les scores précédents ou en cours, afin qu’un retour au modèle précédent ne puisse pas réactiver une approbation périmée. La description de la version ne mentionne qu’une entrée GPT-6-Astra rétroportée dans le catalogue, configurable via API ; le sélecteur et le modèle par défaut n’ont changé qu’à partir de la version v0.153.4. La version v0.153.2 corrige la description du niveau Fast d’Astra, qui passe de « 1,5× » à « vitesse 2×, consommation accrue » (texte affiché uniquement).¹⁴²¹⁴³

v0.153.0 (3 septembre 2026)

• Annulation et rétablissement Vim : u et Ctrl+R restaurent l’intégralité des brouillons dans la zone de saisie, y compris le contenu collé et les images jointes ; vim_normal.redo est une action configurable dans les raccourcis clavier.
• Catalogues de plugins distants : CLI pour les plugins peut répertorier, installer et supprimer des plugins distants, et 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 reste disponible.
• Avertissements de limite d’utilisation plus précoces pour Plus et Team lorsqu’il reste moins de la moitié du quota sur une fenêtre d’environ cinq heures ; les autres abonnements 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, et le mode d’approbation User ignore l’évaluation en arrière-plan et le préchauffage.
• 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 éligibles sur le backend Codex.
• tui.disable_paste_burst remplace la clé de premier niveau, qui reste utilisable comme solution de repli.

Corrections : les sessions de la TUI se reconnectent après une coupure de l’app-server en conservant les brouillons intacts, l’historique des révisions Guardian survit à la compaction, aux redémarrages et aux duplications de fils, 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 nécessite désormais une activation explicite : tools.update_plan.enabled vaut false par défaut et, tant que cette option est désactivée, les consignes intégrées pour update_plan sont retirées des prompts du modèle, du mode collaboration, du fonctionnement multi-agent, de la compaction, du préchauffage et de la poursuite des objectifs (voir Mode plan et collaboration). Autres nouveautés : la recherche Vim avec / et ?, ainsi que n/N, combinable avec les opérateurs, les nouveaux brouillons démarrant en mode insertion ; des bannières de limite de débit proposant des actions ; le suivi de l’actualisation des identifiants, y compris la réauthentification Amazon Bedrock ; des noms de serveurs MCP au format des noms de paquets (:, @, / et . sont autorisés) ; les requêtes de formulaire MCP openai/elicitation ; un output_token_limit MCP par outil ; des identifiants de tâches cloud limités aux origines de confiance ; des délais d’expiration thread/shellCommand configurables ; et une gestion du budget de tokens activée par défaut via les métadonnées du modèle. La v0.152.1 permet à l’examen des approbations par Guardian de récupérer sa politique Node REPL dans les 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 éligibles 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 fils persistants utilisent par défaut un historique paginé lorsque le système de stockage le permet.
• Le niveau d’effort de raisonnement persistent arrive avec des outils d’horloge et des consignes de proactivité intégrées.
• Guardian v2 examine par défaut les actions d’utilisation de l’ordinateur avec des images.
• Vim prend en charge les déplacements de recherche et d’approche f/F/t/T, ainsi que gg/G.
• La saisie dans les terminaux disposant de permissions élevées peut nécessiter 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 la possibilité pour les extensions d’inspecter ou de remplacer les résultats des outils MCP.

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

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

Les hooks prennent en charge 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 permettant de choisir la réponse complète, des blocs de code individuels ou des blocs de citation. Les tâches peuvent être ciblées par des mentions @, les agents peuvent lire et créer des tâches et leur envoyer des messages, et /rename propose un titre modifiable. Les liens Markdown s’affichent sous forme de libellés cliquables, des raccourcis permettent de parcourir les modes de permission, Vim prend en charge la répétition avec ., et les projets non approuvés 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 deviennent des options configurables, désactivées par défaut. La v0.150.1 comptabilise les images conservées dans le budget de tokens de la compaction distante.¹³²¹³³

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

La politique d’approbation untrusted est supprimée ; remplacez-la par on-request dans les configurations qui l’utilisent. Nouveautés : un tableau de bord interactif codex agents, /cd, /pwd et /cwd, codex queue pour envoyer des messages aux sessions locales ou distantes existantes, davantage de déplacements Vim pour les modifications, un codex doctor plus complet (protection des terminaux, défaillances réseau et proxy, état de l’application de bureau, connectivité pour les mises à jour), et les niveaux d’effort de raisonnement max/ultra dans les SDK. Les fils repris et ceux créés par bifurcation retrouvent leur profil de permissions. La v0.149.1 ajoute codex exec --thread-source <SOURCE> (user, subagent, memory_consolidation ou un nom de fonctionnalité ; threadSource dans TypeScript SDK).

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

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

La v0.147.0 supprime codex exec --full-auto (déprécié depuis la v0.128) ; utilisez --sandbox workspace-write avec un indicateur ou un profil d’approbation. Elle ajoute également --approve-for-me, des Agent Plugins portables avec recherche dans plusieurs catalogues, le protocole MCP 2026-07-28 à activation explicite et des sections de conversation. La v0.148.0 ajoute /export au format 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 et capables d’appeler MCP, ainsi que des restrictions de sandbox qui bloquent l’opération lorsqu’un chemin est interdit ou illisible.¹¹⁶¹¹⁸

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 ; manifestes Agent Plugins et places de marché Amazon Bedrock et Claude Code ; nommage des sessions avec épinglage des fils ; skills fournis par l’exécuteur ; paramètres par défaut renforcés pour l’examen automatique des modèles dotés de capacités en cybersécurité.¹¹⁴¹¹⁵
• v0.145.0 (21 juillet) : /import depuis Cursor ainsi que Claude Code ; retour de la voix sous forme de conversations V3 en streaming et en temps réel ; stabilisation de l’expérience multi-agent v2 à activation explicite ; historique paginé des fils et connexion à Amazon Bedrock à titre expérimental ; migration des sélections GPT-5.4 intégrées vers GPT-5.6 Terra et Luna. La v0.144.6 a fixé les fenêtres de contexte de GPT-5.6 à 272 000 tokens.¹¹¹¹¹²
• 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 CLI et MCP OAuth ; 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 détails sur l’éditeur et le pager, et les sources des places de marché apparaissent dans la sortie de JSON.¹⁶⁵
• v0.138.0 (8 juin) : /app transfère une session CLI à l’application de bureau, et le texte des tâches transmis par l’agent parent aux sous-agents est chiffré en multi-agent v2.¹⁶⁶¹⁰⁸
• v0.137.0 (4 juin) : multi-agent v2, raccourcis clavier F13–F24 dans la TUI, et extension de skills v1.¹⁶⁷
• v0.132.0 à 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 de permissions et requirements.toml administré, démarrage et arrêt de codex remote-control, enrichissement de codex doctor et de /status, objets textuels Vim, profils de permissions nommés dans /permissions, authentification Python SDK et préréglages Sandbox, et 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é à activation explicite.^{96979899100101196}

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

Note sur la stabilité : Interfaces et fonctionnalités stables et documentées : le cœur de CLI et la TUI, l’isolation en sandbox et les politiques d’approbation, config.toml, AGENTS.md, les skills, les hooks, les plugins, les outils multi-agents, les objectifs, les profils d’autorisation, /voice et les worktrees gérés (activés par défaut depuis la v0.156.0), la transcription en plein écran et le démarrage automatique du serveur en arrière-plan (activés par défaut depuis la v0.157.0), l’approbation des saisies dans le terminal, la copie à la sélection et le collage par clic droit (activés par défaut depuis la v0.158.0), l’interruption instantanée (activée par défaut depuis la v0.162.0, toujours indiquée comme en développement), Daybreak et l’interruption en mode code (cli_daybreak, code_mode_interrupt ; stables et activés depuis la v0.163.0), ainsi que l’assistant de configuration Bedrock, les mises à jour incrémentales des outils et la coordination du rafraîchissement de MCP OAuth (stables et activés depuis la v0.164.0). Les worktrees gérés et la conversation en temps réel sont permanents depuis la v0.164.0 : leurs indicateurs sont marqués comme supprimés, mais les fonctionnalités restent activées. Browser, Computer Use et Appshots sont des fonctionnalités documentées destinées aux utilisateurs, dont la disponibilité dépend de la plateforme et de l’offre. Fonctionnalités expérimentales ou en développement : Codex Cloud, le mode code et la recherche d’outils en mode code, Memory v2, le tableau de messages local des agents, les indicateurs de l’historique Guardian et du contexte de transfert (v0.160.0), ainsi que tout élément marqué [EXPERIMENTAL] dans ce guide ou répertorié sous /experimental ; ces éléments peuvent changer d’une version à l’autre. Selon la référence de configuration, la gestion expérimentale du contexte n’est « pas disponible actuellement ». Éléments supprimés : --full-auto (v0.147.0), la politique d’approbation untrusted (v0.149.0), codex mcp-server (v0.154.0), l’option de désactivation de thread_context pour Guardian (v0.158.0), les indicateurs shell_zsh_fork et unified_exec_zsh_fork ainsi que la version modifiée de zsh elle-même (v0.163.0), et js_repl.

Canal alpha : des builds alpha sont publiés plusieurs fois par jour, les notes de version des branches alpha sont sommaires et des builds hors cycle issus de bases plus anciennes paraissent régulièrement. À au moins deux reprises, le tag npm alpha a pointé vers l’un d’eux : @alpha installait donc un build plus ancien que latest. La branche 0.158 est passée de 0.158.0-alpha.2 (23 septembre) à alpha.15 (25 septembre) ; sa version stable, v0.158.0 (28 septembre), a été créée à partir du build hors cycle 0.158.0-alpha.15.4, soit alpha.15 avec seize rétroportages, et a porté le tag npm latest jusqu’à la publication de la v0.159.0, 27 heures plus tard. La branche 0.159 est passée d’alpha.1 (25 septembre) à alpha.13 (28 septembre), puis a été publiée en v0.159.0 à partir d’alpha.13. La branche 0.160 a atteint 0.160.0-alpha.6 (29 septembre), puis est restée figée à ce stade ; 0.161.0-alpha.1 correspond à alpha.6 avec pour seule modification le numéro de version. Le 30 septembre, 0.160.0-alpha.6.1 a ajouté à alpha.6 le seul correctif de la console Windows de la v0.159.2 qui lui manquait. Le même jour, la branche 0.159 a reçu une nouvelle version corrective, v0.159.3. La branche 0.160 a ensuite été publiée en version stable sous le numéro v0.160.0 (1er octobre), à partir d’alpha.6.1 et d’un rétroportage, puis en v0.160.1 (5 octobre). La branche 0.161 a produit des versions alpha et des rétroportages hors cycle, le plus récent étant 0.161.0-alpha.13.1 (6 octobre), mais aucune version stable ; elle n’est pas considérée comme sautée, car aucune version supérieure n’a été publiée en version stable. alpha pointe désormais vers 0.162.0-alpha.16. Si vous suivez les versions alpha, vérifiez npm view @openai/codex dist-tags et installez une version précise plutôt que @alpha.^176179181185 Un historique daté du passage des branches alpha récentes aux versions stables figure dans ¹⁷³. La branche 0.161 a été publiée en v0.161.0 le 7 octobre à partir de 0.161.0-alpha.13.1 (avec un seul commit de publication supplémentaire) ; la v0.162.0 a suivi le 8 octobre à partir de 0.162.0-alpha.18.1, tandis que 0.162.0-alpha.20 comptait 52 commits d’avance sur cette base stable ; la v0.162.1 a ajouté trois commits le 9 octobre ; alpha correspondait à 0.163.0-alpha.5 le 10 octobre, est passé par alpha.8, alpha.9 et alpha.10 le 13 octobre, puis correspondait à 0.163.0-alpha.11 le 14 octobre. La branche 0.163 a abouti à une version stable le 15 octobre : la v0.163.0 a été créée à partir du build hors cycle 0.163.0-alpha.10.2 (avec un seul commit de publication supplémentaire), tandis qu’alpha.11 comptait 23 commits d’avance sur cette base. La branche 0.164 a débuté le 16 octobre avec alpha.1 et alpha.2, a atteint 0.164.0-alpha.3 le 17 octobre, puis alpha.12 le 22 octobre, avec, en parallèle, les builds hors cycle 0.163.0-alpha.11.1 et 11.2 (21–22 octobre) et 0.164.0-alpha.11.1 (23 octobre). La branche 0.164 a été publiée en version stable le 23 octobre sous le numéro v0.164.0, à partir d’alpha.11 et d’un commit de publication supplémentaire (alpha.12 comptait neuf commits d’avance sur cette base), et alpha est passé à 0.165.0-alpha.1 le même jour.^{189190191193195}

Fonctionnement de Codex : le modèle mental

Avant d’explorer les fonctionnalités, découvrez comment l’architecture de Codex façonne toutes vos interactions avec l’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 / bubblewrap / 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 29 septembre 2026, la génération actuelle est GPT-6 : gpt-6.1-sol pour les tâches complexes de programmation et le travail agentique (modèle par défaut intégré à CLI lorsqu’aucun modèle n’est configuré, depuis la v0.159.1), gpt-6-astra pour les tâches de bout en bout les plus difficiles, gpt-6-luna pour les tâches ciblées et à fort volume, ainsi que gpt-6-sol, de la génération précédente. Les modèles GPT-5.6 (Sol, Terra, Luna) restent disponibles pendant le déploiement ; gpt-5.5 (contexte de 400K dans Codex et de 1M dans API) sera retiré de Codex pour les connexions via ChatGPT le 14 octobre 2026, tandis que gpt-5.4 a été retiré de Codex le 31 août 2026.^{83117146148149171178} Cette couche lit les fichiers, écrit des correctifs, exécute des commandes shell et raisonne sur votre base de code. Lorsque le contexte est saturé, 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, Bubblewrap isole le système de fichiers et les espaces de noms, tandis que seccomp filtre les appels système ; l’ancienne implémentation Landlock est conservée en tant que système hérité. 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 apps se connectent aux connecteurs ChatGPT. La recherche web apporte un contexte en temps réel provenant d’Internet.

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

L’idée essentielle : la plupart des utilisateurs n’emploient qu’une seule interface. Les utilisateurs avancés utilisent les cinq : le 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 des boucles de programmation rapides, l’application de bureau pour la planification et la coordination, et l’extension de navigateur pour les workflows dans un navigateur avec connexion.

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. SDK Codex
24. Optimisation des performances
25. Comment résoudre 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. Aide-mémoire
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 Codex CLI ?

Codex propose une commande de mise à jour intégrée depuis la v0.128.0 ; 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 par une infrastructure de distribution hébergée par OpenAI, avec GitHub en solution de repli.¹¹⁴ Si votre réseau autorise explicitement GitHub pour les installations et les mises à jour de Codex, ajoutez aussi l’hôte de distribution d’OpenAI : le mécanisme de repli masque l’absence d’autorisation au lieu de provoquer une erreur visible.

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

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

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

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

Figer la version est la bonne solution lorsqu’une mise à jour pose problème. Les versions stables de Codex se succèdent rapidement ; installer une version précise est donc le moyen le plus rapide de revenir en arrière : signalez le problème, figez la version et poursuivez votre travail. Vérifiez que le retour en arrière a bien pris effet avec codex --version, car une seconde installation prioritaire dans votre PATH peut continuer à exécuter l’ancien binaire sans vous avertir (codex doctor signale précisément ce cas dans la rubrique Environnement).

La désinstallation du paquet ne supprime pas vos données. L’authentification, la configuration et l’historique des sessions sont stockés dans ~/.codex/. Conservez ce dossier pour retrouver vos connexions et votre historique après une réinstallation ; ne le supprimez que pour repartir de zéro : rm -rf ~/.codex supprime aussi 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 parmi les fichiers de version sur 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 adapté et le place dans votre PATH.

Téléchargement des binaires

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

Configuration requise

• macOS : Apple Silicon ou Intel (prise en charge complète du bac à sable via Seatbelt)
• Linux : x86_64 ou arm64 (bac à sable via bubblewrap + seccomp)
• Windows : bac à sable natif avec jetons restreints (sorti du stade 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 méthodes 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 : configurez-la via la variable d’environnement CODEX_API_KEY ou codex login --with-api-key. Certaines fonctionnalités (fils de discussion cloud) peuvent être indisponibles.

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

Connexion à Amazon Bedrock (v0.145.0, expérimentale) : les équipes qui accèdent aux modèles via Amazon Bedrock disposent d’une méthode de connexion expérimentale prenant en charge des points de terminaison et une authentification personnalisés, en complément de l’authentification gérée par clé API (v0.140.0+) et de la chaîne d’identifiants AWS déjà disponibles (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 compaction des conversations et la compatibilité multi-agent pour les modèles Amazon Bedrock.¹³² La v0.151.0 ajoute une option Amazon Bedrock, conditionnée par un indicateur de fonctionnalité, aux parcours de connexion TUI éligibles : la configuration initiale détecte les profils AWS et les identifiants d’environnement existants, propose une configuration manuelle des profils, des clés d’accès, des variables d’environnement et des clés API Bedrock, demande la région AWS, masque les secrets pendant la saisie et redémarre le serveur intégré lorsque le fournisseur change.¹³⁵ La v0.152.0 affiche la progression du renouvellement des identifiants : la TUI et codex exec indiquent la progression lorsqu’un fournisseur de modèles renouvelle des identifiants expirés, y compris lors de la réauthentification d’une session Amazon Bedrock, grâce aux notifications stables de l’app-server modelProvider/authRecoveryStarted et modelProvider/authRecoveryCompleted, qui transmettent le fil de discussion, le tour, le fournisseur et un message destiné à l’utilisateur.¹³⁸

Autocomplé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.164.0

Démarrage rapide : votre première session

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

1. Installez et authentifiez-vous :

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

2. Accédez à un projet :

cd ~/my-project                  # Any git repo works

3. Lancez Codex :

codex

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

4. Posez une question :

> What does this project do? Summarize the architecture.

Codex lit les fichiers clés et explique le code du projet. Une question de ce type n’entraîne aucune modification : Codex ne modifie les fichiers que lorsque vous le demandez, et le bac à sable ainsi que la politique d’approbation déterminent quand il doit d’abord vous demander 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 le plan, puis approuvez-le pour lancer l’exécution.

7. Vérifiez votre travail :

> /diff

Consultez toutes les modifications effectuées par Codex au cours de la session actuelle.

Pour aller plus loin : - Configurez AGENTS.md avec les instructions du projet (voir Comment fonctionne AGENTS.md ?) - Configurez un profil adapté à votre façon de travailler (voir Profils) - Essayez codex exec pour automatiser des tâches sans interaction (voir Mode non interactif)

Principales interfaces d’interaction

Codex propose cinq interfaces distinctes reposant sur la même intelligence. Chacune est optimisée pour une manière de travailler différente.

1. CLI interactive (interface 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 de terminal est une application plein écran comprenant :

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

Principaux raccourcis de la 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 de contexte montrant le taux de remplissage de votre fenêtre de contexte. Si vous avez des scripts ou des hooks qui analysent la ligne d’état, vérifiez leur compatibilité avec ce changement de format.⁸² Codex affiche également une annonce de mise à jour de la CLI lorsqu’une nouvelle version est disponible.

Slash commands disponibles dans la TUI :

Refonte du sélecteur de flux de travail (v0.129.0) : les actions de reprise et de dérivation sont désormais plus accessibles grâce à un sélecteur remanié, et un nouveau mode d’historique brut vous permet de parcourir la transcription sans mise en forme lorsque vous devez copier exactement des commandes ou la sortie du modèle. Utile pour examiner 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 regroupant fichiers, plugins et skills, à la place de l’ancien mécanisme limité aux fichiers — une seule touche pour faire référence à n’importe quelle ressource du projet.¹⁰²

2. Codex Desktop App (macOS + Windows)

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

L’application de bureau ajoute des capacités dont la CLI ne dispose pas :

• Multitâche : exécutez plusieurs agents en parallèle sur différents projets
• Isolation par worktrees Git : chaque fil travaille sur une copie isolée de votre dépôt
• Revue des différences intégrée : indexez, annulez et validez des modifications sans quitter l’application
• Terminal intégré : un terminal par fil pour exécuter des commandes
• Dérivation de conversations : créez des branches de conversation pour explorer d’autres possibilités
• Fenêtres flottantes détachables : détachez les conversations dans des fenêtres que vous pouvez déplacer
• Automatisations : planifiez des tâches récurrentes (tri des tickets, surveillance de la CI, réponse aux alertes)
• Appshots : joignez à un fil la fenêtre de l’application Mac au premier plan, avec une capture d’écran et le texte disponible
• Commentaires dans le navigateur intégré : prévisualisez des pages locales ou publiques, laissez des commentaires sur des éléments ou des zones et laissez Codex traiter vos retours visuels précis
• Computer Use : laissez Codex piloter les applications Mac autorisées pour des tâches délimitées dans l’interface graphique ; l’utilisation en mode verrouillé est proposée sur activation pour les tours Mac Computer Use à distance admissibles

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

Instantanés de fils partagés (20 août 2026) : avec tous les forfaits Codex, l’application de bureau macOS peut partager un instantané en lecture seule d’un fil Codex local. L’instantané n’est pas mis à jour 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 secrets correspondant à des motifs 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 de ChatGPT, sous Liens partagés.¹²⁸

Quand utiliser l’application ou la CLI : utilisez l’application de bureau lorsque vous coordonnez plusieurs chantiers ou avez besoin d’une revue visuelle des différences. Utilisez la CLI pour combiner des outils dans le terminal, écrire des scripts ou intégrer Codex à votre 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 adaptées au contexte dans vos fichiers actifs
• Sessions partagées : les sessions se synchronisent entre la CLI et l’extension IDE
• Même authentification : connectez-vous avec votre compte ChatGPT ou une clé API

Installez-la depuis 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 :

• Lancement sans suivi nécessaire : mettez en 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 disponible sous forme d’extension de navigateur pour Google Chrome, Microsoft Edge, Brave, Opera et Vivaldi, ajoutant une cinquième interface aux côtés de la 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 journal des modifications du 25 août 2026 a ajouté les quatre autres navigateurs, à configurer depuis Paramètres > Computer Use dans l’application de bureau ChatGPT. Les cinq prennent en charge les mentions d’onglets et le contrôle du navigateur ; Opera ne prend pas en charge la conversation latérale, 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 les commandes : Codex travaille en parallèle sur plusieurs onglets en arrière-plan, et vous gardez le contrôle des sites auxquels il accède.⁹⁰¹²⁷

• Exécution parallèle dans les onglets : Codex agit sur plusieurs onglets à la fois sans bloquer celui qui est au premier plan.
• Contrôle par site : vous définissez 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 surtout aux tâches dans les applications et les sites web où la page fait référence — consoles d’administration, tableaux de bord internes, interfaces de gestion de contenu, systèmes de tickets — et ne remplace pas la 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 ; un fichier AGENTS.md ou une configuration de skills qui fonctionne dans la CLI applique donc les mêmes conventions aux tâches effectuées dans le navigateur.

Installez-la depuis la documentation de l’extension de navigateur, sur la page anciennement intitulée Codex for Chrome.¹²⁷

Présentation détaillée du système de configuration

Codex utilise TOML pour la 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 à partir du 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. Utile 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 couvrir 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 accessibles pour la recherche, la lecture et la modification de fichiers, mais ils ne fournissent aucune configuration. Un fichier .codex/config.toml situé dans un dossier secondaire peut être lu par Codex, mais n’est pas chargé en tant que configuration. Il s’agit de la délimitation des projets propre à l’application de bureau, et non d’une modification des règles de priorité ci-dessus : le CLI recherche 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.1-sol"                  # Docs' example; unset = bundled default (gpt-6.1-sol since v0.159.1)
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"]
mouse_scroll_speed = 1.0                # Mouse-wheel scroll multiplier, a finite positive number (v0.162.0)

# ─── 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)
instant_interrupt = true                # New input preempts the model's response; on by default since v0.162.0 (under development)
api_key_model_discovery = true          # Fetch the model catalog when signed in with an OpenAI API key; on by default since v0.161.0 (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)
guardian_conversation_history_tools = false  # Guardian reads earlier user messages (under development, v0.160.0)

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

# ─── Guardian Auto-Review (v0.160.0 history keys) ─────
[auto_review]
conversation_history_max_output_tokens = 4000   # Per history-tool response, estimated tokens (default 4,000)
experimental_conversation_history_prompt = ""   # Blank = built-in retrieval instructions

# ─── 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 tabulaire définit la stratégie. Le proxy applique les règles de domaine du profil d’autorisation 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 les commandes accèdent directement au réseau. Il ne filtre ni la recherche web, ni les apps, 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 pour 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.1-sol"
# GPT-6.1 Sol starts at Standard speed; /fast toggles Fast (2.5x credits)
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 du 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 premier niveau 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"

env_key désigne la variable d’environnement qui contient la clé API du fournisseur ; la clé elle-même ne doit jamais figurer dans config.toml. Un fournisseur configuré avec requires_openai_auth = true affiche l’écran de connexion lors de la première exécution et stocke ses identifiants dans le backend sélectionné par cli_auth_credentials_store (file, keyring ou auto), pas nécessairement dans auth.json. Depuis la v0.160.0, un fournisseur qui définit model_catalog_url ne reçoit que les modèles de ce catalogue, sans fusion avec les modèles intégrés, et tout échec d’actualisation du catalogue entraîne la suppression des entrées mises en cache au lieu de réutiliser des données obsolètes.¹⁸² Depuis la v0.162.0, un fournisseur personnalisé compatible avec Responses peut également déclarer ses capacités sous [model_providers.<name>.capabilities] : external_web_access = false empêche la recherche web hébergée d’accéder au web en direct pour ce fournisseur, tandis que remote_compaction = "v2" active le protocole compaction_trigger de Responses, dont seuls les fournisseurs OpenAI et Azure Responses bénéficient autrement ("unsupported" maintient la compaction en local).¹⁸⁷

Avertissement : le API filaire chat/completions (wire_api = "chat") a été déprécié 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 endpoints 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 : programmation complexe, utilisation d’ordinateurs, travail intellectuel et workflows de recherche. Disponible dans Codex CLI / web / desktop le 23 avril pour ChatGPT Plus / Pro / Business / Enterprise / Edu / Go ; dans l’API OpenAI le 24 avril. Fenêtre de contexte : 400 K dans Codex, 1 M dans l’API — Codex limite la fenêtre à 400 K afin d’équilibrer le débit et le coût entre les différentes formules d’abonnement ; l’API donne accès à l’intégralité du million. Tarifs (API) : 5 $ en entrée / 30 $ en sortie par MTok (deux fois le tarif de GPT-5.4 ; OpenAI annonce une hausse effective d’environ 20 % après les améliorations d’efficacité en tokens). Évaluations : 82,7 % à Terminal-Bench 2.0 (meilleur résultat actuel parmi les modèles accessibles au public), 84,9 % à GDPval (44 métiers), 78,7 % à OSWorld-Verified, 98,0 % à Tau2-bench Telecom (sans optimisation des prompts). 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 précise que ce retrait concerne ChatGPT, ChatGPT Work et Codex pour tous les abonnements (y compris les offres grand public, Business, Enterprise et Edu), mais pas l’API 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 géré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 (avec Enterprise et Edu, un administrateur doit d’abord activer Luna) ; l’utilisation d’une clé API n’est pas affectée.⁶⁴¹⁷¹ La liste exacte des modèles varie selon le compte et l’état du déploiement. Consultez votre cache local : ~/.codex/models_cache.json.

Note sur la dépréciation (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 par l’intermédiaire de API et de CLI jusqu’à son arrêt le 23 juillet 2026.⁷¹⁸⁸

Note 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. Le public de la famille GPT-5.5 s’étend ainsi au-delà des offres payantes, même si l’accès à Codex CLI nécessite toujours un abonnement Plus / Pro / Business / Enterprise / Edu / Go admissible ou une clé API.⁹²

GPT-5.4 mini (17 mars 2026) : variante plus petite et plus rapide de GPT-5.4, avec un contexte de 400 K au tarif de 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 le 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, y compris le niveau d’effort de raisonnement max. Les équipes dont l’accès aux modèles passe par un fournisseur Bedrock peuvent les sélectionner de la même manière que les autres modèles de fournisseurs personnalisés (voir Fournisseurs de modèles personnalisés) ; le niveau d’effort max vise les charges de travail agentiques et de raisonnement les plus difficiles.¹⁰⁶ La v0.144.6 (18 juillet 2026) a actualisé les instructions fournies pour Sol, Terra et Luna, et corrigé leurs fenêtres de contexte à 272 000 tokens.¹¹¹ La v0.145.0 (21 juillet 2026) ajoute une connexion Bedrock expérimentale prenant en charge un point de terminaison et une authentification personnalisés, fait de GPT-5.6 Sol le modèle Bedrock par défaut et migre les sélections fournies de modèles GPT-5.4 vers les variantes Terra et Luna correspondantes.¹¹²

GPT-6-Astra (lancé le 3 septembre 2026 ; dans Codex par l’intermédiaire des v0.153.1 à v0.153.4) : voici la chronologie, avec les dates exactes : la v0.153.1 a préparé le 3 septembre 2026 une entrée de catalogue réservée à API ; OpenAI a annoncé GPT-6-Astra le même jour ; puis la v0.153.4 a ajouté l’entrée au sélecteur et fait basculer la valeur par défaut fournie avec CLI le 4 septembre. L’annonce décrit un déploiement progressif commençant auprès d’un nombre limité d’organisations (d’abord les partenaires du programme de cybersécurité), puis étendu à ChatGPT Plus, Pro, Business et Enterprise « dans les jours à venir », ainsi qu’à l’API OpenAI et à AWS — ces informations sur le déploiement proviennent de la presse (CNBC, Axios, Forbes, Al Jazeera, 9to5Mac).¹⁴⁵ Informations remplacées le 4 septembre : OpenAI a annoncé sur X que GPT-6 Astra « is now available to all Pro, Enterprise, and Business Premium users in ChatGPT Work and Codex » et « live in the API », l’arrivée pour Plus et Business étant attendue dans les jours suivants ; Tibo Sottiaux, responsable de Codex, a ajouté le soir même : « Astra is now rolled out to all Plus and Business users too. » En pratique, les droits d’accès restent inégaux — des témoignages de la communauté datant du 5 septembre indiquent que certains comptes Plus ne voient toujours que les modèles GPT-5.6 dans Codex — et la mention de disponibilité de la documentation des modèles citée ci-dessous n’ayant pas changé, elle demeure la déclaration officielle de référence.¹⁴⁹ La documentation officielle est en ligne : la page du modèle API présente gpt-6-astra comme le modèle phare, « Our most capable model, built for the hardest end-to-end work » — 10 $/MTok en entrée, 50 $/MTok en sortie aux tarifs standard pour contexte court, une fenêtre de contexte de 1,05 M de tokens avec un maximum de 922 000 tokens en entrée, une sortie maximale de 128 K et une date limite des connaissances au 30 avril 2026 — avec un niveau documenté pour les contextes longs : les prompts dépassant 272 K tokens d’entrée sont facturés deux fois plus cher en entrée et 1,5 fois plus cher en sortie pour l’ensemble de la requête, soit 20 $/MTok en entrée et 75 $/MTok en sortie sur la page des tarifs. Il se place ainsi au-dessus de GPT-5.6 Terra (équilibré) et Luna (économique), tandis que la documentation de Codex présente Astra comme le modèle Codex recommandé, avec une disponibilité qui « depends on the rollout, your sign-in method, and your client » et une admissibilité indiquée pour les comptes Pro, Business (100 $) et Enterprise. Échelle de raisonnement Codex documentée pour Astra : 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 fourni avec la v0.153.4 définit default_reasoning_level sur low ; considérez donc que la valeur effective dépend de l’interface et vérifiez /status dans une session. L’échelle reste inchangée lors de la nouvelle consultation du 15 septembre, désormais accompagnée d’une description pour chaque niveau dans le sélecteur (Ultra, citation exacte : « Maximum reasoning with automatic task delegation »), tandis que les niveaux Max et Ultra sont confirmés par SDK — la version 0.154.0 de l’SDK Python (10 septembre 2026) ajoute les valeurs d’effort de raisonnement max et ultra (#39662).^146148153 Dans CLI, Astra est configurable par 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’à ce que la v0.157.0 le remplace par GPT-6 Sol¹⁷⁴) et apparaît dans le sélecteur de modèles ainsi que comme valeur par défaut fournie 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 valeur par défaut relève du catalogue fourni avec CLI, et non de toutes les interfaces — même si l’écart avec le cloud s’est depuis résorbé : les consultations des 4 et 7 septembre indiquaient qu’Astra n’était pas disponible pour Codex cloud (GPT-5.6 Sol y était disponible), tandis que celle du 15 septembre montre Astra comme disponible pour Codex cloud dans la matrice de disponibilité ; la page précise toujours : « Currently, you can’t change the default model for Codex cloud chats. » Réserve concernant le déploiement : les droits d’accès varient selon le compte et, avec CLI 0.153.4 ou version ultérieure, un compte exclu du déploiement peut avoir un modèle fourni par défaut qu’il ne peut pas encore 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 de Codex sur la vitesse le facture 2,5 fois le nombre de crédits Standard avec une connexion ChatGPT (« where available »), tandis que la page des tarifs de l’API affiche des tarifs du mode Fast correspondant exactement au double des tarifs Standard applicables (20 $/100 $ par MTok pour un contexte court, 40 $/150 $ pour un contexte long). La mention « 2x speed » de la chaîne du catalogue de la v0.153.2 reste uniquement un texte d’affichage du catalogue — la page sur la vitesse ne précise aucun multiplicateur de vitesse pour Astra.^145146147148 Partiellement remplacé 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 « the hardest end-to-end work », indique qu’Astra n’est pas disponible pour Codex cloud et donne Light (low) comme effort initial pour Astra, ce qui correspond au catalogue fourni. Astra reste le modèle CLI fourni par défaut lorsqu’aucun modèle n’est configuré.¹⁷¹ Remplacé le 29 septembre 2026 : la v0.159.1 fait de GPT-6.1 Sol le modèle fourni par défaut et relègue Astra à la deuxième place du sélecteur ; la documentation des modèles recommande désormais GPT-6.1 Sol pour la programmation complexe, tout en réservant Astra aux tâches de bout en bout les plus difficiles ; les exemples de configuration de la documentation utilisent désormais gpt-6.1-sol.¹⁷⁸

Préréglages Power avec Astra (ajout à la documentation effectué au plus tard le 6 septembre 2026) : le passage consacré au sélecteur de modèles dans la documentation Codex établit désormais une correspondance entre les options Power du sélecteur et les 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 consultation du 5 septembre citée dans ¹⁴⁶ et dont la présence a été confirmée le 7 septembre. Citation exacte : « 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 en parallèle du tableau des modèles ci-dessus : « Power » désignait GPT-5.6 Sol avec un raisonnement moyen ; sur un compte disposant des droits nécessaires, cette 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’abonnement et de la phase de déploiement. Le paragraphe était toujours strictement identique lors de la nouvelle consultation du 15 septembre 2026.¹⁴⁶ Mise à jour du 23 septembre 2026 : après le lancement de GPT-6 Sol et Luna, la documentation répertorie les six préréglages Power comme suit : « Luna High, Sol Light (the starting preset), Sol Medium, Astra Light, Astra Medium, and Astra Extra High » ; elle précise que certaines offres payantes n’incluent pas Astra Extra High et recommande de commencer par Medium pour Sol, High pour Luna et Light (low) pour Astra.¹⁷¹

Notes expérimentales entre fenêtres de contexte (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 », dont voici le texte exact : « 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. » Mécanisme d’activation, citation exacte : « 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 par la v0.153.0 (voir Gestion du contexte) — la page de documentation l’associe désormais nommément à Astra et aux connexions Plus et Pro, alors que les notes de version de la v0.153.0 mentionnaient les sessions Plus, Pro et Pro Lite admissibles. La v0.154.0 renforce cette restriction dans le code : l’admissibilité à 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 était toujours strictement identique lors de la nouvelle consultation du 15 septembre 2026. Cette fonctionnalité est expérimentale et désactivée par défaut ; son comportement et ses conditions d’accès sont susceptibles d’évoluer.^140146152 v0.157.0 : le catalogue de modèles fourni n’indique plus que GPT-6-Astra, ni aucun autre modèle fourni, prend en charge la gestion expérimentale du contexte (#47397), et CLI n’active l’expérience que pour un modèle explicitement marqué comme compatible. Avec le catalogue fourni, l’activation n’a donc aucun effet ; la documentation ne précise pas si le catalogue transmis aux comptes connectés diffère. La documentation des modèles décrivait encore cette option le 26 septembre 2026.¹⁷⁴ 29 septembre 2026 : la page des modèles ne comporte plus cette section, la référence de configuration décrit features.context_management.experimental_mode comme « Experimental context-management setting. The feature is not currently available », et GPT-6.1 Sol n’est pas non plus indiqué comme compatible.¹⁷⁸

Organigramme de sélection du 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; most expensive)
   │     │  └─ No → gpt-6.1-sol (near-Astra at lower cost; default since v0.159.1)
   └─ GPT-6.1 Sol not yet available on your account? → gpt-6-sol, then gpt-5.6-sol

Effort de raisonnement

Contrôlez le degré de « réflexion » du modèle avant sa réponse :

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

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 gérées sont conservés), et fournissent des instructions intégrées de proactivité et de suivi que les métadonnées du modèle peuvent remplacer ou désactiver au moyen de persistent_instructions.¹³⁵

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

Conseil d’expert : le raisonnement xhigh peut consommer 3 à 5 fois plus de tokens que medium pour un même prompt. Réservez-le aux problèmes véritablement difficiles pour lesquels ce surcroît de réflexion est utile.

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 — utile lorsqu’un problème difficile survenant en cours de session justifie une montée temporaire de 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-le pour une exécution donnée au moyen de --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 des tarifs d’avril 2026 : le tarif annuel de Business est passé de 25 $ à 20 $ par poste et par mois. Des postes Codex uniquement avec paiement à l’utilisation sont désormais proposés aux espaces de travail Business et Enterprise : aucun frais fixe par poste, la facturation étant fondée sur la consommation de tokens.⁷⁹ La page des tarifs présente maintenant les limites sous forme de plages propres à chaque modèle (voir le tableau ci-dessus), et non plus sous forme des multiplicateurs promotionnels 2x annoncés lors du lancement de la Desktop App en février 2026.¹⁶¹⁶²

Augmentation des limites d’utilisation en mai 2026 (expirée 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 était doublé pendant la même période.⁸⁹

Expérience des limites d’utilisation dans la TUI (v0.152.0-v0.153.0) : atteindre une limite ne constitue plus une impasse. La v0.152.0 affiche au-dessus de la zone de saisie des bannières de limite d’utilisation permettant d’agir : 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. Elles sont filtrées selon le compte authentifié et l’utilisateur ; 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 : un avertissement se déclenche lorsqu’il reste moins de la moitié de l’allocation dans une fenêtre d’utilisation d’environ cinq 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 inclus dans votre offre :

Ces tarifs correspondent à la vitesse Standard, et la page des tarifs 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 coûte 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.1 Sol ainsi que pour GPT-6 Astra, Sol et Luna « lorsqu’il est disponible ». Par ailleurs, dans le catalogue inclus, Fast est le niveau par défaut de GPT-6 Sol et Luna (mais pas de GPT-6.1 Sol) 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 échanges comparables uniquement textuels.^162171178

Pour les offres Enterprise et Edu, les crédits évoluent selon l’allocation prévue au contrat. 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 la tarification API standard d’OpenAI applicable au modèle sélectionné, avec les éventuelles réductions liées à la mise en cache des prompts. Tarifs API actuels pour 1 M de tokens : GPT-6.1 Sol, 2 $ en entrée / 10 $ en sortie (0,10 $ pour les entrées en cache) ; GPT-6 Sol, 2 $ / 10 $ ; GPT-6 Luna, 0,10 $ / 0,50 $ ; GPT-6 Astra, 10 $ / 50 $. Pour les quatre modèles, les prompts dépassant 272 K tokens d’entrée coûtent 2 fois le tarif d’entrée et 1,5 fois le tarif de sortie pour l’ensemble de la requête, tandis que le mode Fast coûte 2 fois plus cher.^146171178 Les multiplicateurs de crédits ChatGPT ne s’appliquent pas à la connexion par clé API. Consultez la page officielle des tarifs 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 intensif : n’utilisez xhigh que pour les problèmes réellement difficiles, car il consomme 3 à 5 fois plus de tokens
3. Utilisez --ephemeral : évitez la persistance des sessions dans les pipelines 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 dans les workflows d’automatisation
6. Surveillez l’utilisation : consultez /status dans la TUI et les tableaux de bord de facturation de votre organisation — depuis la v0.148.0, /status, les lignes d’état et les titres du terminal affichent une estimation des crédits ou du coût du fil pour les espaces de travail admissibles¹¹⁸

Exemples de coûts réels

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

Les coûts varient selon l’intensité du 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 considérablement le coût. Les tokens d’entrée en cache bénéficient d’un tarif réduit.

Surcharge cachée liée aux tokens

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

Conseil d’expert : surveillez votre utilisation réelle via /status dans la TUI. Le nombre de tokens inclut toute la surcharge, pas seulement vos messages visibles. Si les coûts vous surprennent, vérifiez combien de serveurs MCP sont connectés : chacun ajoute 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 afin d’imposer à toute l’organisation des limites de modèle et d’intensité de raisonnement - Utilisez gpt-5.6-luna pour les pipelines CI/CD — les pipelines automatisés nécessitent rarement le niveau de raisonnement maximal - Établissez les budgets par profil — définissez des profils ci, review et dev avec des plafonds de coût adaptés - Surveillez l’utilisation via OpenTelemetry — les déploiements Enterprise peuvent exporter la télémétrie 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 = « quand vous aurez terminé, faites également ceci ».

Application Desktop 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 système de sandbox et les approbations ?

Codex utilise un modèle de sécurité à deux niveaux qui distingue ce qui est techniquement possible des situations où 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 dans la v0.148.0 : les restrictions de la sandbox suivent désormais le principe de fermeture en cas d’échec : un chemin refusé ou illisible est considéré comme bloqué, et non plus autorisé silencieusement, sous Linux comme sous Windows.¹¹⁸

Niveau 1 : sandbox (ce qui est possible)

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

Application selon la plateforme :

• macOS : framework Seatbelt d’Apple via sandbox-exec, avec des profils propres à chaque mode, compilés à l’exécution et appliqués par le noyau⁶. Depuis la v0.121.0, les profils de sandbox macOS peuvent placer sur liste d’autorisation 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 : bubblewrap (bwrap) pour isoler le système de fichiers et les espaces de noms, associé à seccomp pour filtrer les appels système, le tout exécuté par un processus auxiliaire autonome (codex-linux-sandbox) ; l’implémentation Landlock est conservée comme solution héritée, et la v0.163.0 a renommé le type de commande et le module d’appels système du crate qui portaient le nom Landlock, sans modifier l’application des restrictions.⁵¹⁹³ Codex privilégie le premier bwrap trouvé dans le PATH en dehors du répertoire de travail, puis se rabat sur le fichier intégré codex-resources/bwrap (fourni depuis la v0.100.0)⁷, avec un avertissement au démarrage si bwrap est absent ou ne parvient pas à créer les espaces de noms utilisateur. La v0.117.0 a amélioré la fiabilité de la sandbox sur les distributions plus anciennes dotées de configurations de noyau héritées.⁷⁵ La v0.129.0 a renforcé le démarrage de la sandbox sous Linux et mis à niveau la version intégrée de Bubblewrap vers la 0.11.2, qui comprend des correctifs de sécurité issus du projet en amont ; la v0.130.0 a encore renforcé le démarrage.⁸⁹⁹¹
• Windows : sandbox native utilisant des jetons restreints (sortie du statut expérimental dans la v0.100.0). WSL est également pris en charge (avec bubblewrap et seccomp de Linux). La v0.117.0 améliore la sandbox à jetons restreints afin de mieux isoler les processus.⁷⁵ La v0.130.0 accorde aux utilisateurs de la sandbox l’accès au cache des binaires d’exécution de l’application de bureau, afin que la sandbox Windows puisse résoudre ces binaires de manière fiable pour les utilisateurs d’une sandbox limitée à l’espace de travail.⁹¹

Pourquoi est-ce important ? Contrairement à l’isolation fondée sur des conteneurs (Docker), l’isolation 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 de la sandbox par zsh-fork (v0.106.0) : correction d’une vulnérabilité qui permettait à l’exécution d’un shell par création d’un processus zsh de contourner les restrictions de la sandbox.⁶⁰ Si vous utilisez une version antérieure, effectuez immédiatement la mise à niveau. - Limite de taille des entrées (v0.106.0) : Codex impose désormais une limite d’environ 1 million de caractères aux entrées afin d’éviter les blocages provoqués par des charges utiles trop 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 d’adaptation du noyau de WSL1).⁸² - Examen Guardian et hooks (v0.121.0) : les hooks sont désactivés pendant les sessions d’examen Guardian, afin que les hooks exécutés avant ou après les outils ne puissent pas perturber les décisions du sous-agent Guardian.⁸² Si vous comptez sur les hooks pour la journalisation ou la validation, sachez qu’un examen Guardian les ignore : utilisez 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 la 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 et versions ultérieures) : une structure de politique configurable permettant un contrôle précis des accès en lecture. Utilisez-la pour limiter les répertoires 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 suspend son exécution pour demander une confirmation humaine :

on-failure apparaît encore dans certains anciens exemples et chemins de compatibilité, mais la documentation actuelle d’OpenAI relative à la configuration l’indique comme obsolète. Privilégiez on-request pour les exécutions interactives et never pour les exécutions non interactives qui disposent déjà d’une limite de sécurité externe.⁸⁷

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

Identifiants d’approbation distincts (v0.104.0 et versions ultérieures)

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

Contrôles d’approbation flexibles (v0.105.0 et versions ultérieures)

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

• Autorisations de sandbox supplémentaires : lorsqu’une commande nécessite un accès qui dépasse le mode de sandbox actuel, Codex peut demander des autorisations supplémentaires précises au lieu d’exiger un changement complet de mode
• Refus granulaire : refusez des appels d’outils individuels en fournissant des commentaires, afin que Codex puisse adapter son approche au lieu de simplement retenter la même commande

Demandes d’autorisation à l’exécution (v0.113.0 et versions ultérieures)

Codex intègre désormais un outil request_permissions 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.) via le processus d’approbation de la TUI, au lieu d’échouer silencieusement ou d’obliger l’utilisateur à redémarrer avec d’autres options.

Mode d’approbation des apps writes (v0.144.0 et versions ultérieures)

Les apps et connecteurs disposent d’un niveau d’approbation intermédiaire : le mode d’approbation des apps writes permet l’exécution sans confirmation des actions déclarées en lecture seule par une app, tout en suspendant l’exécution de toute action d’écriture.¹⁰⁷ Auparavant, les approbations d’apps relevaient davantage du 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 examinées automatiquement : --approve-for-me (v0.147.0 et versions ultérieures)

La nouvelle option CLI --approve-for-me transforme les demandes d’approbation en approbations examinées automatiquement : au lieu de vous interrompre, chaque demande est évaluée lors d’un examen, puis approuvée ou refusée en votre nom.¹¹⁶ Cette option se situe entre « tout approuver » (la posture qu’encourageait --full-auto, désormais supprimée) et « interrompre pour tout » : les demandes existent toujours en tant que points de décision, mais un réviseur y répond. Associez-la aux réglages par défaut plus sûrs de la v0.146.1 pour l’examen automatique des modèles dotés de capacités cyber, dont cette option hérite. Traitez-la comme toute délégation d’autorité : elle convient aux longues exécutions sans surveillance qu’une interruption bloquerait, mais pas aux sessions qui touchent des identifiants ou l’état d’un environnement de production et pour lesquelles vous souhaitez rester le réviseur.

Approbation des entrées de terminal élevées (v0.151.0 ; activée par défaut depuis la v0.158.0)

Le feature flag write_stdin_approval — désactivé par défaut lors de son introduction dans la v0.151.0, puis activé par défaut depuis la v0.158.0 — exige une nouvelle approbation avant l’envoi d’une entrée non vide à un terminal unified-exec élevé. Ces examens transitent par les hooks, Guardian, l’app server et la TUI sous forme d’approbations writeStdin ; l’environnement du terminal, son répertoire 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 d’approbation doivent tenir dans 8 000 octets : les actions trop volumineuses ou tronquées sont refusées avant toute demande d’approbation ou transmission au terminal.¹³⁵ La v0.158.0 active ce flag (#47799) et empêche les autorisations accordées uniquement à l’exécution, comme celles utilisées par les plugins pour les métriques, de déclencher un examen ; en revanche, les autorisations supplémentaires des agents, les contournements de la sandbox et les modifications de politique intervenues depuis le lancement continuent de le faire (#48073). Pour le désactiver : définissez write_stdin_approval = false sous [features] dans config.toml.¹⁷⁶

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

Les profils d’autorisation répartissent les politiques de sandbox du système de fichiers et du réseau dans des sections nommées et réutilisables. Définissez default_permissions sur un profil intégré tel que :read-only ou :workspace, ou faites-le pointer vers une table [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, le fichier requirements.toml administré peut déclarer des exigences d’autorisation, les profils actifs sont actualisés à l’exécution et la configuration de la 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, privilégiez les règles plutôt qu’un élargissement général du profil.⁸⁷

v0.151.0 : les threads restaurés de l’app server conservent leurs profils d’autorisation au lieu d’être ramenés à des remplacements hérités du mode de sandbox pour chaque tour : les profils persistent lors du routage des tours et des changements de répertoire compatibles effectués avec /cd. Une commande /cd qui ne permet pas de représenter de façon sûre le profil restauré sous la forme d’un mode de sandbox hérité est refusée, plutôt que d’affaiblir silencieusement les restrictions.¹³⁴

Recommandations héritées pour --full-auto

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

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

Dans la v0.128.0, les notes de version indiquent que --full-auto est obsolète, et l’aide actuelle de CLI ne le mentionne plus pour les exécutions interactives. Utilisez plutôt les options 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 cette option provoque désormais une erreur au lieu de s’exécuter. La migration est mécanique : remplacez-la par --sandbox workspace-write (ainsi que par une option d’approbation ou un profil si votre ancienne invocation dépendait du comportement d’approbation de --full-auto). Auditez toute automatisation qui lance 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é de la sandbox (v0.129.0) : le renforcement du démarrage de la sandbox sous Linux réduit les conditions de concurrence sur les systèmes de fichiers lents ou les extractions utilisant des liens symboliques ; les améliorations de fiabilité de la sandbox Windows corrigent plusieurs plantages dans des cas limites pendant les longues exécutions ; enfin, la version intégrée de Bubblewrap passe à la 0.11.2 et comprend des correctifs de sécurité issus du projet 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 (option sûre par défaut) :

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

Utilisateur avancé (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 association comme un « compromis idéal »⁸ ; comprenez toutefois ce qu’elle fait réellement avant de reprendre ce conseil : les demandes d’approbation apparaissent lorsqu’une commande doit sortir de la sandbox ou accéder au réseau, tandis que danger-full-access supprime ces deux limites. Il ne reste donc presque plus rien à transmettre pour approbation avec on-request. Vous obtenez des capacités maximales avec un minimum de demandes, et non des capacités maximales assorties d’une vérification humaine pour chaque commande ; si vous recherchez cette seconde option, conservez workspace-write et laissez les limites de la 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 et versions ultérieures)

Les approbations intelligentes peuvent acheminer les demandes d’examen 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 examen bénéficie d’un historique vierge (les décisions précédentes ne se répercutent pas sur les examens ultérieurs).⁷³

Configurez le réviseur dans config.toml :

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

Cette fonctionnalité est particulièrement utile pour les workflows CI/CD dans lesquels vous souhaitez un examen automatisé et raisonné plutôt qu’un simple approval_policy = "never" appliqué sans distinction.

Inversion des réglages par défaut de Guardian v2 (v0.151.0) : Guardian v2 utilise désormais par défaut des examens 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 d’examen plus large des outils — et features.guardianv2.transcript.include_images vaut également true par défaut — définissez-le sur false pour exclure les images des transcriptions Guardian. Ces deux surfaces configurables ont été livrées désactivées par défaut dans la v0.150.0 ; 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 tâches 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 de confirmation uniquement émises par Guardian et MCP sont approuvées sans examen synchrone, préchauffage du sampler ni notation 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 dans le mode Full Access ou le quitter en toute sécurité. En mode d’approbation par l’utilisateur (approvals_reviewer = "user"), le préchauffage de Guardian et la notation 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 actuel.¹⁴⁰ Cette modification restreint les situations dans lesquelles Guardian s’exécute, mais pas la couche d’approbation humaine : le comportement de demande décrit dans ce guide pour danger-full-access avec on-request relève de la politique d’approbation, qui constitue un mécanisme distinct. La v0.152.1 permet en outre à l’examen des approbations de Guardian de tirer sa politique Node REPL des métadonnées du modèle (auto_review.node_repl_policy) et de se rabattre sur la politique intégrée lorsque ce champ est absent.¹³⁹

La notation computer-use de Guardian respecte les exigences du modèle (v0.153.1) : la notation de Guardian limitée au computer-use et les décisions d’approbation rapides ne s’exécutent désormais que lorsque les métadonnées du modèle actif définissent node_repl_auto_review_required. Les scores antérieurs ou en cours sont invalidés lorsqu’un changement de modèle désactive la notation ; revenir ensuite à un modèle soumis à examen ne peut donc pas réactiver une décision d’approbation obsolète. Il s’agit de la modification principale du correctif v0.153.1, mais elle ne figure pas dans le corps des notes de version : le changement #42422 (un cherry-pick de 38ba8cdc) ne peut être établi qu’au moyen de la comparaison 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) : #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 lors du redémarrage d’une session d’examen. D’après les tests de la PR, les sessions d’examen mises en cache restent 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) : #47275 fait de guardianv2.thread_context une fonctionnalité stable et l’active pour les examens Guardian synchrones et asynchrones, qui utilisent ainsi le contexte appartenant au thread. Cette fonctionnalité est indépendante du réglage enabled de Guardian v2. Dans la v0.157.0, vous pouviez la désactiver avec thread_context = false sous [features.guardianv2] ; la v0.158.0 a supprimé cette option.¹⁷⁴

Le contexte du thread Guardian est toujours activé (v0.158.0) : #47686 et #47689 rendent inconditionnelle l’utilisation du contexte appartenant au thread pour la capture des sessions Guardian et les forks d’historique des sous-agents. Codex ignore thread_context sous [features.guardianv2], y compris dans les remplacements de profils et les exigences administrées, et affiche un avis d’obsolescence vous demandant de le supprimer de config.toml. Aucun autre réglage ne permet de le désactiver.¹⁷⁶

Guardian peut lire les messages antérieurs de l’utilisateur (v0.160.0, option facultative) : la transcription examinée par Guardian peut omettre une instruction, une restriction ou une autorisation révoquée antérieure. Lorsque guardian_conversation_history_tools = true est défini sous [features] et que les Apps sont activées, le réviseur dispose de deux outils, user_message.search_messages et user_message.read_messages, accessibles via la connexion et l’identité Apps propres à la session parente. Chaque appel vérifie à nouveau la politique actuelle du parent relative aux apps et aux outils, puis échoue de manière fermée si un outil est désactivé ou nécessite une approbation. Deux clés [auto_review] permettent d’ajuster ce comportement : conversation_history_max_output_tokens limite chaque réponse (environ 4 000 tokens par défaut selon l’estimation ; les limites plus strictes du parent restent applicables), tandis que experimental_conversation_history_prompt remplace les instructions de récupération intégrées (une valeur vide conserve les instructions par défaut). Un second flag facultatif, guardian_root_handoff_context, limite les éléments issus de la conversation racine utilisés pour examiner un agent worker aux messages entourant chaque transfert vers cet agent, auxquels s’ajoutent les trois derniers messages. Ces deux flags sont en cours de développement et désactivés par défaut ; la documentation de référence de la configuration ne les mentionne pas encore.¹⁸²

[features]
guardian_conversation_history_tools = true

[auto_review]
conversation_history_max_output_tokens = 4000

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

Extension de la détection des commandes dangereuses (v0.144.5) : la détection reconnaît désormais davantage de formes forcées de rm, et les commandes refusées sont accompagnées de motifs de refus plus clairs plutôt que d’un refus 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 réseau en mode workspace-write. Activez-le lorsque cela est 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 et versions ultérieures)

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

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

Elles complètent la prise en charge existante de HTTPS_PROXY et des proxys SOCKS5 (v0.93.0 et versions ultérieures).

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

Proxy système sous macOS (v0.142.2 et versions ultérieures) : lorsque respect_system_proxy est activé, les clients d’authentification macOS respectent les paramètres du proxy système, de PAC et de WPAD. Ainsi, les Mac d’entreprise dont la configuration du 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, cette prise en charge s’étend à Windows ainsi qu’au trafic Responses API : Codex achemine les appels d’authentification et les appels Responses API par le proxy système de macOS ou de Windows, y compris avec l’autoconfiguration PAC et WPAD, ce qui comble la dernière lacune sur les réseaux d’entreprise verrouillés de ces deux systèmes d’exploitation.¹⁰⁶

Test de la sandbox

Vérifiez le comportement de la 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 la sandbox fonctionne correctement, les deux commandes doivent échouer avec une erreur d’autorisation refusée sous un profil limité à l’espace de travail. Si l’une des commandes réussit, vous devez examiner la configuration de votre sandbox.

Comment fonctionne AGENTS.md ?

AGENTS.md est le système d’instructions de projet de Codex — 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 les modifications. Il est activé par défaut (depuis la v0.94.0).¹⁴ Consultez Cadres de décision pour voir 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, dans lequel Codex fait une proposition avant de l’exécuter — est activé par défaut depuis la v0.94.0 et reste inchangé. update_plan est un outil de planification que le modèle peut appeler afin de maintenir un plan structuré au cours d’un tour. Lancé en 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 instructions update_plan intégrées de ses prompts liés au modèle, au mode de collaboration, aux systèmes multi-agents, à la compaction, au préchauffage et à la 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 sont conservés, même s’ils mentionnent la planification). Activez-le explicitement avec tools.update_plan.enabled = true dans config.toml.¹³⁸

Accéder au 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 progressivement le plan dans une vue TUI dédiée.

Mode Steer

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

Deux méthodes permettent d’ajouter des instructions :

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 particulier 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 dans le texte. Utilisez /theme pour choisir un jeu 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 le matériel audio à utiliser.⁶² Supprimée en v0.140.0, réintroduite en v0.145.0 : les commandes vocales expérimentales /realtime et leurs dépendances audio ont été retirées de la TUI dans la v0.140.0 (la transcription vocale avec la barre d’espace n’a pas été affectée).¹⁰² La v0.145.0 réintroduit la voix sous une nouvelle forme : des entrées audio et sorties d’outils audio dans les formats audio locaux courants, ainsi que des 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 en tant que 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 de mise en sourdine configurable (#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 une touche F8 pour les activer ou les désactiver, 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 consacrée à la fonctionnalité Voice dans la documentation 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 renvoyés à la ligne dans la TUI (v0.105.0)⁶¹ - Les liens vers des fichiers locaux bénéficient d’un meilleur formatage (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 étroits sont remplacés par des enregistrements clé/valeur lisibles sans perdre les cibles des liens (v0.136.0)¹⁶⁸ - Les liens Markdown apparaissent 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 sub-agents a été corrigée afin d’arrêter correctement les processus enfants (v0.106.0)⁶⁰

Système de mémoire

Codex dispose d’un système de mémoire persistante (v0.100.0+) qui conserve les faits, les préférences et le contexte 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ébut de chaque session et s’en sert pour adapter son comportement au cours de toutes les sessions ultérieures.

Éléments à mémoriser

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

• Conventions du projet : « Ce projet utilise des tabulations, pas des espaces » ou « Les réponses API comprennent toujours un champ meta »
• Préférences relatives aux 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/, pas dans src/middleware/ »
• Préférences de workflow : « Exécutez toujours le linter avant de me montrer un diff »

Mémoire dans les pipelines

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

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

• Nettoyage des secrets : les souvenirs sont automatiquement analysés afin de détecter d’éventuels secrets avant leur écriture sur le disque
• Prise en compte du CWD : les fichiers de mémoire incluent désormais le contexte du répertoire de travail afin de faciliter le rappel d’informations propres au projet
• Exclusion des messages du développeur : les messages du développeur et du système sont exclus des données d’entrée de la mémoire de phase 1, ce qui améliore la qualité de la mémoire en la concentrant sur les interactions avec l’utilisateur
• Oubli fondé sur les diffs (v0.106.0) : la mémoire utilise désormais les diffs pour oublier les informations obsolètes, ce qui permet de conserver un ensemble de souvenirs léger et pertinent au fil du temps⁶⁰
• Sélection fondée sur l’utilisation (v0.106.0) : la récupération des souvenirs prend désormais en compte leur 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 réinitialiser tous les souvenirs enregistrés et repartir de zéro — une option 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 de 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 pour convertir les transcriptions de phase 1 en informations durables ; le changement de modèle améliore la qualité du rappel pour un coût en tokens identique.⁸²
• Menu des souvenirs dans la TUI (v0.121.0) : une nouvelle interface accessible pendant la 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 informations susceptibles d’être rappelées à l’avenir sans compromettre la relecture des sessions.⁸²

Mémoire ou AGENTS.md

Conseil : utilisez /m_update pour les informations qui doivent être conservées 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 de bureau Codex

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

Installation

codex app                      # Auto-downloads and installs on first run

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

Fonctionnalités principales

Appshots, commentaires dans le navigateur et Computer Use

Les mises à jour de l’application du 21 mai font de l’application de bureau une interface contextuelle plus performante, 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 rendu accessible par l’application, puis stocke la pièce jointe localement dans l’historique de la session.⁹⁹

Pour le travail sur le Web et le frontend, utilisez d’abord le navigateur intégré lorsque la page ne nécessite aucune authentification : Codex et vous disposez ainsi d’une prévisualisation rendue commune, avec la prise en charge d’actions dans le navigateur telles que les clics, les captures d’écran, le téléchargement de ressources et l’inspection en lecture seule JavaScript. Vous pouvez également 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 chat latéral). Outils de site (WebMCP, 25 août 2026) : dans le navigateur intégré à l’application de bureau, 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 dans la dernière version de l’application de bureau, car les outils de site ne sont pas disponibles 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 la prévisualisation dans le navigateur ne permet pas de vérifier la tâche. Cette fonctionnalité peut inspecter et piloter les applications Mac autorisées, mais les approbations et les règles de sandbox de Codex continuent de s’appliquer aux modifications de fichiers et aux commandes shell. L’utilisation verrouillée reste strictement limitée : Codex peut accéder temporairement aux applications autorisées pendant des tours Computer Use actifs et approuvés après le verrouillage du Mac, avec des mécanismes de reverrouillage et de 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 de bureau : 1. Crée un nouveau git worktree (git worktree add) dans un répertoire temporaire 2. Extrait une nouvelle branche à partir de votre HEAD actuel 3. Exécute l’agent dans le worktree — toutes les modifications de fichiers sont isolées 4. Présente une revue du diff à la fin — vous choisissez les modifications à réintégrer

Plusieurs threads Worktree peuvent ainsi s’exécuter simultanément dans le même dépôt sans conflit. Chacun dispose de sa propre branche et de son propre répertoire 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é : par défaut, la racine des worktrees est $CODEX_HOME/worktrees, le nettoyage automatique est activé 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 n’écrasent aucune donnée existante (les associations répétées sont idempotentes et les propriétaires en conflit sont rejetés), tandis que les extractions principales, imbriquées et non gérées sont rejetées 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 une extraction isolée pour une session nouvelle ou issue d’un fork, codex exec prend en charge les worktrees gérés pour l’automatisation, et les commandes de session de la TUI ainsi qu’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, les informations de propriété sont affichées et la suppression d’un worktree géré sans modification demande confirmation (#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 l’a confirmé 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 dans la v0.156.0 : #44870 fait de worktrees une fonctionnalité stable, l’active par défaut et la retire de /experimental. Cette version apporte également les changements suivants : les sessions de worktree peuvent se connecter à un daemon local existant au lieu de lancer leur propre daemon (#46498), et des sessions de worktree peuvent être créées directement depuis la vue d’ensemble des agents (#45276), qui bénéficie aussi d’onglets de filtrage par statut (#46839). Si vos scripts ou vos configurations supposent que les worktrees restent désactivés sauf demande explicite, 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é avec le message « The local Codex service cannot check background terminals, » exécutez codex app-server daemon update, puis redémarrez Codex.¹⁶⁹¹⁷¹

Outils de worktree destinés au modèle (v0.162.0) : dans un projet local approuvé où la fonctionnalité est activée, le modèle peut lui-même créer et répertorier des worktrees gérés à l’aide de nouveaux outils (#50148), tandis que les prompts de création de conversation et de fork expliquent les différentes options de worktree (#50416).¹⁸⁷

Automatisations

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

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

Configurer une automatisation : 1. Ouvrez un projet dans l’application de bureau 2. Cliquez sur l’onglet Automations dans la barre latérale 3. Définissez un déclencheur (planification, webhook ou 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 la planification et placent les résultats dans une file d’attente pour vérification

Exemples de cas d’usage : - Triage des issues : catégorisez et hiérarchisez automatiquement les nouvelles issues - Surveillance de la CI : surveillez les échecs de build et proposez des correctifs - Réponse aux alertes : réagissez aux alertes de surveillance avec une analyse diagnostique - Mises à jour des dépendances : recherchez et appliquez les correctifs de sécurité

Les résultats apparaissent dans une file de vérification en vue d’une approbation humaine.

Prise en charge de Windows

L’application de bureau Codex a été lancée 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/tâches en aval.

Stratégies de sécurité

Contrôles d’accès

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

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

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");