Codex dans VS Code : consignes disparues ou bloquées, que vérifier ?

Des utilisateurs signalent que certaines consignes disparaissent dans l’extension Codex pour VS Code sans qu’une tâche démarre, ou restent bloquées dans la file d’attente. Si cela vous arrive, les réglages du PC et le réseau ne sont pas les seules pistes : le traitement des requêtes par l’extension mérite aussi d’être examiné. Des symptômes similaires ne prouvent cependant pas une cause unique dans tous les environnements.

Ce guide distingue les témoignages individuels des recommandations officielles de dépannage. Avant de renvoyer une demande, l’objectif est de vérifier ce qui a réellement été exécuté afin de protéger votre travail et d’éviter les doublons.

Une réponse lente et une demande qui ne démarre pas sont deux situations différentes

Codex peut prendre du temps pour lire du code ou utiliser des outils. Une tâche inscrite dans la conversation et dont l’activité continue est différente d’un champ de saisie qui se vide sans nouveau message. Inversement, l’absence temporaire de progression visible ne prouve pas que la requête est définitivement perdue.

• Seul le champ de saisie se vide : regardez si la consigne apparaît dans la conversation.
• Un message de suivi reste en attente : vérifiez si la tâche précédente est réellement terminée et si d’autres éléments attendent encore.
• Une demande terminée réapparaît en attente : comparez l’interface avec son résultat effectif.
• Un redémarrage aide temporairement : relevez les conditions de réapparition du problème avant de conclure qu’il est résolu.

Par exemple, si une consigne de modification de fichier manque dans la conversation, examinez les fichiers et les travaux en cours avant de la renvoyer. Un message absent ne suffit pas à démontrer qu’aucune action n’a eu lieu.

Quels problèmes ont été signalés sur GitHub ?

Le dépôt OpenAI Codex contient les signalements suivants. Les dates d’ouverture sont celles des fiches publiques GitHub en UTC. L’environnement d’un auteur ne doit pas être généralisé à tous les utilisateurs ; l’état indiqué dans le tableau correspond au relevé historique du 22 octobre 2026.

Sources : premier envoi sans démarrage, #50075, état de traitement persistant, #50486, messages et file d’attente sous Windows, #50491, et envoi et affichage en attente, #50653.

Ces fiches établissent que d’autres personnes décrivent des symptômes proches. Un signalement ne signifie pas à lui seul que les développeurs ont reproduit le défaut ou confirmé son origine. Même une fiche fermée demande une lecture attentive : elle peut être classée comme doublon, sans qu’un correctif soit disponible pour toutes les versions.

Dans un commentaire du 4 octobre sur #50653, une personne indique ainsi une amélioration après installation de 26.930.41038, tout en précisant poursuivre ses essais. C’est un retour individuel provisoire, pas la confirmation d’une version corrigée dans tous les cas.

Pourquoi un message de suivi peut-il rester en attente ?

Une explication possible est un décalage entre l’achèvement réel d’une tâche et l’état conservé par l’extension. Les journaux rapportés dans #50486 associent un tour terminé à markedStreaming=true et à une erreur de libération du verrou de la file. Le streaming désigne la réception progressive d’une réponse ; ici, l’indicateur décrit une tâche que l’extension semble encore considérer comme active.

Source : signalement concernant l’état de traitement persistant.

Le tableau suivant explique comment un tel décalage pourrait affecter les requêtes suivantes. Il s’agit d’un schéma explicatif simplifié, pas d’une description vérifiée de l’implémentation interne.

Le fait établi est l’existence de signalements similaires. La gestion de l’état constitue une explication rapportée, pas une cause universelle démontrée. Il faut d’autres éléments pour savoir si tous les cas ont la même origine ou si votre installation est concernée. Des problèmes d’authentification et de connexion peuvent produire des symptômes proches : examinez les journaux avant de retenir une seule cause.

Le problème peut-il survenir quand l’état du service est normal ?

Oui. La page officielle d’état sert à repérer des incidents de service, sans garantir le fonctionnement de chaque version de l’extension et de chaque environnement. OpenAI précise que ses mesures de disponibilité sont agrégées et que la disponibilité individuelle peut varier. Comparez les services concernés et l’historique des incidents avec l’heure exacte de l’échec ; l’état actuel ne prouve pas la réussite d’une requête antérieure.

Source : état des services OpenAI.

Une courte demande avec le même compte dans un autre client peut aider à délimiter le problème. Si seule l’extension échoue de manière répétée alors que l’application ou l’interface en ligne de commande fonctionne, commencez par examiner la piste de l’extension. Si plusieurs clients échouent, étudiez aussi service, authentification, limites d’usage et connexion. Un seul essai réussi ou raté ne suffit pas à trancher.

Dans quel ordre effectuer le dépannage ?

Les étapes suivantes constituent une démarche de diagnostic, pas un correctif officiel ni une solution garantie. Si la consigne incertaine concernait une suppression, une publication ou un déploiement, contrôlez d’abord le résultat réel avant tout nouvel envoi.

1. Vérifier les validations et l’état de la demande. Codex peut attendre une permission ou une réponse. Consultez cette demande et prenez la décision nécessaire ; un indicateur de chargement ne prouve pas une panne. Conservez la consigne, l’heure avec son fuseau, la dernière réponse réussie et les éléments en attente. Vérifiez si le nouveau message a été enregistré.
2. Examiner les changements effectifs. Pour un travail sur fichiers, consultez les modifications et les terminaux actifs. Pour un service externe, contrôlez le résultat dans ce service. Évitez de répéter la même demande sans cette vérification.
3. Protéger le travail en cours. Enregistrez les fichiers ouverts. Avec Git, relisez les changements puis enregistrez uniquement le travail voulu dans un commit, ou faites une sauvegarde distincte. Autant que possible, vérifiez que les tâches actives sont terminées ou arrêtées avant de redémarrer. Des modifications peuvent provenir d’un travail antérieur ou d’un autre outil : leur seule présence ne prouve pas l’exécution de la dernière consigne.
4. Fermer complètement puis rouvrir VS Code. Si le rechargement de la fenêtre ne suffit pas, fermez les fenêtres concernées et relancez l’application. Ne commencez pas par forcer l’arrêt des processus, au risque de perdre des données non enregistrées.
5. Essayer une courte consigne sans modification dans une nouvelle conversation. Demandez une explication d’une phrase, puis une reformulation. Si cela fonctionne, réintroduisez une à une les conditions présentes lors de l’échec, par exemple une pièce jointe.
6. Comparer les clients et rechercher un correctif. Gardez le même compte et, si possible, le même modèle, sans relancer simultanément ailleurs le travail au résultat incertain. Consultez les mises à jour et les commentaires des signalements concernés.

Le guide officiel de dépannage recommande aussi de vérifier les validations, le fonctionnement élémentaire du terminal et une nouvelle conversation avec une consigne plus limitée. Pour un essai sans action, demandez : « Sans modifier de fichier ni exécuter de commande, explique HTML en une phrase », puis : « Raccourcis cette explication. » Vérifiez que les deux messages sont inscrits et produisent chacun une réponse.

Un tel essai réussi ne démontre pas que le défaut initial est corrigé. Ajoutez séparément les conditions associées à l’échec, comme une image ou un suivi en file d’attente, et notez le dernier changement et l’heure si le blocage revient. N’utilisez pas une publication, une suppression ou un déploiement comme tâche de diagnostic.

L’auteur de #50491 rapporte une amélioration temporaire après un redémarrage complet, alors que le simple rechargement de fenêtre n’aidait pas systématiquement. Cette possibilité reste un contournement à évaluer, sans garantie de résolution durable.

Source : retour sur l’effet et les limites du redémarrage.

Quand envisager une version antérieure de l’extension ?

Si le problème débute juste après une mise à jour et empêche toujours le travail après redémarrage, comparer temporairement avec une version déjà utilisée peut être raisonnable. Aucun numéro présenté ici ne constitue une version universellement stable. Relevez d’abord la version installée, son canal de distribution et les réglages utiles.

Vérifiez en priorité les mises à jour proposées par la distribution officielle. Dans la vue des extensions, la commande Show Extension Updates ou le filtre @updates affiche celles disponibles. Choisissez Update pour l’extension concernée, puis Restart Extensions lorsque VS Code le demande. Une comparaison avec une ancienne version reste une option de diagnostic temporaire.

Sous Windows, ouvrez les extensions avec Ctrl+Shift+X et trouvez Codex publié par OpenAI. Faites un clic droit, choisissez Install Another Version, puis une version disponible. Si nécessaire, désactivez temporairement Auto Update uniquement pour cette extension. Les libellés peuvent être traduits selon la langue de VS Code.

Pour revenir, mettez l’extension à jour et réactivez les mises à jour automatiques. Une ancienne version peut manquer de correctifs ou ne pas accepter des réglages récents. Commencez par des demandes en lecture seule ; si la comparaison aggrave la situation, rétablissez la version et les paramètres relevés.

Source : documentation VS Code sur les versions et mises à jour d’extensions.

Quelles informations conserver si le problème persiste ?

Une heure précise et une séquence reproductible sont plus utiles qu’un simple « l’extension se bloque ». Rassemblez les éléments suivants, sans divulguer mots de passe, jetons d’authentification, clés API ni fichiers privés :

• Version et canal de Codex, version de VS Code et système d’exploitation.
• Modèle, méthode d’authentification et heure de l’échec avec fuseau.
• Ordre des actions, notamment la fin de la tâche et l’envoi du message de suivi.
• Présence du défaut dans une nouvelle conversation, avec une image ou avec la file d’attente.
• Résultats avant et après redémarrage complet, et dans un autre client.
• Erreurs de la même période et captures expurgées des informations sensibles.

Un exemple de séquence minimale serait : « nouvelle conversation → première question en lecture seule → réponse terminée → message de suivi → champ vidé sans message enregistré ». Remplacez la dernière observation par ce qui s’est réellement produit. Séparez le comportement attendu, par exemple un suivi enregistré et exécuté une seule fois, de l’interface observée, des journaux et des changements de fichiers. Ne présentez pas les journaux d’une autre personne comme les vôtres.

Dans VS Code, ouvrez View → Output et, si un canal Codex ou OpenAI existe, examinez l’heure de l’échec. Son nom et sa disponibilité dépendent de la version. Si vous voyez une erreur 401, 429 ou une connexion interrompue, conservez l’heure et le contexte au lieu d’en déduire immédiatement une cause unique.

Si un signalement existant correspond à votre environnement, utilisez-le comme référence. Un nouveau rapport doit distinguer résultat attendu et résultat observé, avec une reproduction minimale. Lorsqu’un correctif est annoncé, vérifiez la version et son champ d’application, puis rejouez le déroulement qui échouait.