Codex CLI ajoute la voix. La reprise compte davantage

Codex CLI 0.155.0 a ajouté des conversations vocales expérimentales le 17 septembre 2026. Je donnerais toutefois la priorité aux changements qui préservent le travail : conserver un prompt si la compression du contexte échoue et restaurer les tâches après le redémarrage du service géré. Le correctif 0.155.1 du lendemain compte aussi si votre fournisseur refuse les résumés de raisonnement. Ce sont des modifications documentées du client, pas un nouveau modèle. [1]

Que permet le mode vocal de Codex CLI ?

Le nouveau mode permet de discuter en direct dans l’interface du terminal, avec une transcription et des commandes audio. L’implémentation comprend /voice, /voice mute et /voice stop. Elle peut lire les réponses finales du travail délégué pendant la conversation, sans lire ses commentaires intermédiaires. Les réponses aux messages saisis au clavier ne sont pas lues automatiquement. [2]

Une présentation des nouveautés publiée dans r/CodexAutomation le 18 septembre commençait par la voix. Le choix se comprend : c’est l’ajout le plus visible. Ce billet permet de repérer la version, mais ne constitue pas un test indépendant du fonctionnement de la voix. [7]

Je l’essaierais pour expliquer un problème ou discuter d’une modification en regardant le code. Pour les chemins exacts et les critères d’acceptation, je garderais une instruction écrite que je peux vérifier. Les notes de version présentent la voix comme expérimentale et limitée aux versions compatibles ; elles ne promettent pas sa présence dans toutes les installations. [1]

Cela change la manière de parler à l’agent. La question est distincte des capacités et du coût étudiés dans ma comparaison de GPT-6 Astra.

Que se passe-t-il lorsqu’une longue tâche est interrompue ?

Deux correctifs traitent des causes différentes de rupture dans une session. Le premier concerne la compression du contexte de conversation avant la poursuite du travail. Jusqu’ici, un échec avant le tour suivant pouvait laisser un prompt déjà accepté hors de l’historique enregistré. La correction enregistre l’entrée avant de signaler cet échec. [4]

Cette distinction aide à examiner une session en échec. Une erreur peut toujours arrêter le tour, mais l’instruction doit rester disponible dans l’historique. Le test de régression décrit dans la modification vérifie que le prompt est enregistré une seule fois et qu’aucune autre requête au modèle ne suit l’échec. Il ne prétend pas que la compression ne puisse plus échouer. [4]

Le second correctif restaure les tâches enregistrées lorsque le daemon géré, c’est-à-dire le service en arrière-plan, redémarre. La restauration s’effectue en arrière-plan et les objectifs actifs peuvent continuer avant la reconnexion d’un client. Si une tâche ne peut pas être restaurée, le processus poursuit avec les autres. [5]

J’y vois des améliorations de la continuité des sessions. Elles complètent la conservation du contexte utile du dépôt, qui traite une autre question : préserver une instruction ne garantit pas que le modèle dispose des bonnes informations sur le projet. Les modifications du daemon concernent aussi le service local de Codex, et non l’Agents API hébergée.

Le nettoyage des worktrees indique leur tâche propriétaire

L’explorateur de worktrees relie désormais chaque copie de travail gérée à sa tâche propriétaire. Il indique son titre, sa dernière mise à jour et son état archivé ou indisponible. Un worktree est une copie de travail distincte du dépôt ; cette relation aide à comprendre pourquoi un répertoire existe avant de le supprimer. [3]

La suppression exige une confirmation, sélectionne Annuler par défaut et conserve l’historique de conversation. Elle se limite aux worktrees gérés du dépôt courant. Elle refuse la copie de travail actuelle ainsi que toute copie contenant des modifications locales, des fichiers non suivis ou des fichiers ignorés. [3]

La prise en compte des fichiers ignorés mérite une explication. Un répertoire peut contenir des fichiers générés que Git omet normalement de la liste des modifications. Ce contrôle de suppression en tient tout de même compte. Je préfère cette prudence lorsque je nettoie après des tâches parallèles. Elle apporte des informations avant de supprimer des fichiers, indépendamment de l’agent qui réalise le mieux une grande fonctionnalité.

Pourquoi 0.155.1 a-t-il changé les résumés de raisonnement ?

La version 0.155.0 demandait par défaut des résumés détaillés dans les nouvelles sessions locales du terminal. Certains fournisseurs ne les prennent pas en charge et rejetaient la requête. Le correctif du 18 septembre rétablit none par défaut, tout en respectant les réglages explicites auto, concise et detailed. [6]

C’est une correction de compatibilité, pas l’annonce que le modèle raisonne moins. Le changement concerne le résumé demandé du raisonnement. Si l’annonce de 0.155.0 vous faisait attendre des résumés en direct automatiquement après la mise à jour, ce correctif explique la différence. [6]

Les premiers signalements doivent aussi être mis en perspective. Un utilisateur de r/codex rapporte que 0.155.0 ne pouvait pas initialiser le sandbox Windows et que revenir à 0.154.0 a résolu son problème. Il s’agit d’un témoignage individuel, pas d’une défaillance confirmée de toutes les installations Windows. [8] Le correctif documenté de 0.155.1 concerne les résumés de raisonnement ; je ne supposerais donc pas qu’il résout cette autre difficulté.

Pour un travail déjà organisé autour du terminal, je vérifierais la conservation des prompts et la reprise des tâches avant de consacrer beaucoup de temps à la voix. Une nouvelle manière de donner une instruction est utile ; retrouver cette instruction après une interruption permet de poursuivre le travail.