Codex CLI 0.152.0 : ce qui change vraiment avec les limites de sortie MCP

Codex CLI 0.152.0 est sorti le 1er septembre 2026 avec six nouvelles fonctionnalités. Mais cette version vise surtout à mieux encadrer les longues exécutions qui sollicitent beaucoup d’outils. La principale nouveauté permet de plafonner, outil par outil, la sortie MCP transmise au modèle, au lieu d’appliquer partout la même règle par défaut.

L’essentiel

Cette version améliore le contrôle et la fiabilité : elle n’introduit ni nouveau modèle ni changement de prix. Si vous utilisez Codex comme simple agent de code dans le terminal, les évolutions les plus visibles sont des messages de limite d’usage plus utiles, une récupération des identifiants plus lisible et la recherche Vim dans les longs brouillons.

Si vous reliez Codex à des systèmes externes via MCP, ou si vous développez sur le serveur d’application Codex, la mise à jour va plus loin. MCP, pour Model Context Protocol, est la couche de connexion qui permet à Codex d’appeler des outils comme une recherche documentaire, Figma, GitHub ou un service interne. Avec la version 0.152.0, chacun de ces outils dispose de son propre budget de sortie.

Voici les six nouveautés de cette version, présentées selon les personnes concernées :

La première ligne mérite toute l’attention : elle modifie la quantité de contenu produit par les outils que Codex conserve pour la suite de son travail.

Comment fonctionne la limite de sortie MCP dans Codex CLI ?

Un outil MCP peut renvoyer énormément de contenu. Une requête documentaire peut rapporter plusieurs pages très longues ; une recherche dans les logs, des lignes par centaines. Codex doit intégrer ce résultat à son contexte de travail, autrement dit à la mémoire à court terme dont dispose le modèle pour la tâche en cours.

Sans réglage propre à l’outil, la sortie MCP continue de suivre la politique de troncature habituelle du modèle actif. Depuis la version 0.152.0, il est possible d’ajouter le nouveau paramètre output_token_limit à un outil précis, sous un serveur MCP donné. Codex réduit alors le résultat destiné au modèle pour respecter le budget de tokens configuré.

Le point essentiel est bien « destiné au modèle ». Le serveur MCP n’effectue pas moins de travail, et Code Mode reçoit toujours le résultat brut. La limite intervient lorsque le résultat entre dans le contexte du modèle et dans l’historique de la conversation. Codex conserve le même budget effectif dans les sessions reprises et les réponses des hooks post-outil : rouvrir un thread ne rétablit donc pas discrètement un résultat plus volumineux.

Pourquoi cette limite compte-t-elle ?

Le compromis n’est plus « quelle quantité de sortie le modèle peut-il tolérer ? », mais « de quelle quantité cet outil précis a-t-il besoin pour remplir sa mission ? ». Une consultation de bibliothèque et un export de logs de production n’ont plus à partager la même réponse.

Deux garde-fous s’appliquent. La valeur doit être positive : 0 et les valeurs négatives sont refusés. Si une politique de plugin et votre propre configuration fixent toutes deux une limite, la plus petite l’emporte. L’approbation des outils reste indépendante : réduire un budget de sortie n’approuve pas un outil et ne change pas le moment où Codex demande l’autorisation de l’appeler.

À qui s’adresse cette version et comment l’utiliser ?

Un développeur indépendant avec un outil documentaire trop bavard

Un créateur de SaaS travaillant seul peut empêcher une recherche documentaire très large d’accaparer le reste d’un tour de développement. Fixez un budget explicite sur l’outil qui renvoie les longues pages, laissez tranquilles les outils de consultation précis, et vous préserverez davantage de contexte de travail pour le dépôt, le plan et le diff.

C’est le cas d’usage le plus évident de la version 0.152.0, car la limite est placée à la source du bruit. Il n’est plus nécessaire de réduire tous les outils simplement parce que l’un d’eux produit trop de contenu.

Un ingénieur plateforme qui exécute de longues tâches sur le serveur d’application

Le nouveau champ timeoutMs appartient à la méthode thread/shellCommand du serveur d’application. Il ne s’agit pas du paramètre MCP tool_timeout_sec.

La distinction est importante. Les outils MCP ont actuellement un timeout d’exécution par défaut de 60 secondes. Une commande shell du serveur d’application conserve, elle, sa valeur par défaut d’une heure lorsque timeoutMs est omis ou vaut null. Un client du serveur d’application peut désormais demander un délai plus long lorsqu’il sait qu’un build, une migration ou une suite de tests en a besoin. Définir timeoutMs sur 0 déclenche un timeout immédiat, tandis que les valeurs négatives non valides sont refusées.

Le timeout de cette commande auxiliaire n’arrête pas le tour actif de l’agent. C’est au client de décider si le tour doit poursuivre son travail, recevoir de nouvelles instructions ou être interrompu séparément.

Un développeur adepte de Vim qui rédige un long brief

Le mode Vim permet désormais de rechercher dans le brouillon lui-même. / cherche vers l’avant, ? vers l’arrière, et n ou N répète la recherche en revenant au début ou à la fin si nécessaire. La recherche fonctionne aussi avec les opérations de suppression, de modification et de copie, sans ajouter la requête au texte du prompt.

Cela paraît anodin jusqu’au jour où l’on rédige des consignes de plusieurs paragraphes dans le terminal. Plus besoin, alors, de copier le texte dans un éditeur uniquement pour retrouver et remplacer un nom répété.

Une équipe d’entreprise qui utilise Bedrock

L’expiration des identifiants d’un fournisseur ressemblait trop souvent à une exécution bloquée. Codex émet désormais des notifications stables au début et à la fin de la récupération de l’authentification du fournisseur, et affiche cette progression dans le TUI interactif comme dans codex exec.

Pour une équipe d’ingénierie qui passe par Amazon Bedrock, le bénéfice est opérationnel : un log de CI peut distinguer « l’agent travaille » de « la session du fournisseur se réauthentifie », sans avoir à interpréter un long silence.

Un auteur de plugin qui conserve de vrais noms de packages

Les noms de serveurs MCP peuvent désormais contenir :, @, / et .. Un nom tel que npm:@modelcontextprotocol/server-sequential.thinking peut traverser les commandes mcp add, get, list et remove, puis conserver la même identité dans les namespaces d’outils à l’exécution et les identifiants OAuth.

Une source fastidieuse d’alias disparaît ainsi. La référence du package, le nom de configuration et l’identité d’authentification peuvent rester alignés.

Une équipe qui atteint régulièrement ses limites d’usage

Le terminal peut désormais transformer une alerte de limite d’usage en action concrète. Les bandeaux compatibles peuvent renvoyer vers l’usage, les crédits, la réinitialisation, la notification au propriétaire ou la gestion de l’abonnement. Pendant la récupération, Codex actualise l’usage, écarte les réponses obsolètes et suspend les saisies en attente jusqu’à ce que l’état soit à jour. Un bandeau envoyé par le backend peut aussi l’orienter vers le premier modèle de secours disponible, sans réécrire les autres réglages du thread.

Votre quota n’augmente pas pour autant. La limite devient simplement compréhensible, et le terminal peut vous conduire vers une solution utile.

Une configuration complète avec un véritable serveur MCP

Le moyen le plus rapide de comprendre cette nouvelle configuration consiste à l’appliquer à Context7, le serveur MCP documentaire utilisé dans le guide de configuration de Codex. Son outil query-docs récupère la documentation correspondant à l’identifiant connu d’une bibliothèque, ce qui en fait un bon candidat pour un budget de sortie explicite.

1. 1

   Installer la version

   Épinglez cette version pour disposer de la nouvelle clé de configuration :

   npm install -g @openai/codex@0.152.0

2. 2

   Ajouter Context7

   Utilisez la commande exacte indiquée dans le guide MCP actuel de Codex :

   codex mcp add context7 -- npx -y @upstash/context7-mcp

3. 3

   Définir le budget de l’outil

   Ouvrez ~/.codex/config.toml et ajoutez cette table sous l’entrée du serveur Context7 :

   [mcp_servers.context7.tools.query-docs]
   output_token_limit = 30000

   La valeur 30,000 provient du propre test de sérialisation de Codex. Elle illustre une forme acceptée, pas une recommandation universelle. Commencez par le plus petit résultat qui préserve les éléments dont vos prompts ont besoin, puis augmentez la limite si des sorties réelles arrivent tronquées.

4. 4

   Vérifier la connexion

   Exécutez codex mcp list pour confirmer que le serveur est configuré. Dans l’interface du terminal, /mcp affiche les serveurs actifs disponibles pour la session.

Ce qu’il faut dire sans détour

La troncature par outil est un garde-fou, pas une compression gratuite. Si la limite est trop basse, Codex peut perdre la ligne de log déterminante ou la réserve dans la documentation qui explique le problème. Comme la valeur la plus faible l’emporte lorsque les politiques du plugin et de l’utilisateur se chevauchent, une politique de plugin peut aussi ramener le budget effectif sous le nombre inscrit dans votre propre fichier.

Le budget configuré intervient également avant une marge de sérialisation standard de 20%, qui couvre la structure supplémentaire nécessaire pour insérer le résultat dans la requête adressée au modèle. Considérez-le comme un budget pratique, pas comme la garantie que chaque charge utile sérialisée contiendra exactement ce nombre de tokens.

Le reste de la version 0.152.0 relève d’une maintenance utile. Les threads repris retrouvent leur répertoire de travail enregistré lorsque l’appelant n’en fournit pas. La vérification automatique des approbations préserve davantage d’instructions et d’autorisations valides lors de la compaction de l’historique. Les outils MCP résistent mieux aux actualisations du cache et aux changements de plugins distants. Rien de tout cela ne modifie les capacités de développement du modèle, le prix de l’abonnement ou le quota d’usage.

Que faire maintenant ?

Mettez à niveau cette semaine si vous utilisez plusieurs outils MCP, intégrez le serveur d’application, rédigez de longs prompts en mode Vim, passez par Bedrock ou atteignez régulièrement vos limites d’usage. Ce sont des améliorations directes du workflow, avec une migration limitée.

Attendez si votre organisation centralise les versions de Codex CLI. Les pages publiques de configuration n’intègrent pas encore la limite de sortie par outil ; laissez à l’équipe responsable de vos politiques le temps de valider le nouveau champ et de choisir les limites à partir de sorties réelles.

Si vous utilisez uniquement ChatGPT sur le Web ou sur mobile, cette version ne change rien à votre workflow. Si vous cherchez encore à savoir si Codex correspond à votre manière de livrer des produits, commencez plutôt par le comparatif entre Codex, Claude Code et Cursor.

Pour recevoir d’autres analyses claires des versions qui changent votre façon de développer, inscrivez-vous à la newsletter.