Accueil / Articles

Utiliser Codex dans VS Code : portée, points de récupération et solutions aux pannes fréquentes

Un Codex dans VS Code sans les temps d’attente habituels : installation et connexion, une première tâche d’agent limitée, cloud contre CLI, configuration partagée, ainsi que des correctifs pour WSL et les approbations.

Éditeur : REACTAPP.TOP18 min de lecture4113 mots

Sources: How to Use Codex in VS Code: From First Task to Reliable Agent Workflow

Il faut quelques minutes pour faire fonctionner Codex dans VS Code : installez l’extension officielle openai.chatgpt, connectez-vous, ouvrez un dossier de projet, passez en mode Agent et assignez-lui une tâche à portée restreinte indiquant les fichiers concernés. Chaque modification de l’espace de travail et chaque résultat de test doit être vérifié par un humain avant d’être conservé. Les tâches plus longues conviennent à la délégation vers le cloud, et les problèmes qui freinent la plupart des utilisateurs — à savoir les approbations répétées, la connexion à distance et le blocage lors du chargement de WSL sous Windows — ont chacun une solution spécifique présentée ci-dessous.

Le champ d’application ici se limite à l’interface de VS Code : une première tâche définie, suivie des contrôles qui permettent de garder l’agent prévisible. L’installation dans le terminal, le plugin Cursor, les tableaux de bord d’utilisation ainsi que les comparaisons avec d’autres outils relèvent de sujets distincts.

Des suggestions à un agent capable de déplacer des fichiers

De nombreux développeurs sont habitués aux suggestions de texte qui apparaissent au fur et à mesure que l’on tape, que l’on retient ou que l’on ignore, sans que rien d’autre ne se produise dans l’arborescence. Le mode Agent dans Codex est une expérience complètement différente : une barre latérale permet de lire des fichiers, d’éditer l’arborescence de travail et d’exécuter des vérifications pendant que son utilisateur va chercher un café. Confondre les deux fait que la première utilisation du mode Agent semble ressembler à une intrusion, alors qu’il s’agit simplement d’un type de travail différent.

Une analogie peut aider. Un passager qui montre du doigt un panneau routier laisse les deux mains du conducteur sur le volant, et la voiture ne bouge que parce que le conducteur la fait avancer. Remettre les clés est une autre affaire : on revient de la cuisine et la voiture se trouve dans une nouvelle place de parking, avec un coffre réorganisé et davantage de kilomètres au compteur, sans que personne n’ait demandé quel était le itinéraire. L’autocomplétion en ligne, c’est le passager qui montre du doigt. Le mode agent, c’est l’ensemble des clés. Omettre un point de récupération, c’est accorder des droits d’écriture à un répertoire qui contient encore des travaux non enregistrés de l’après-midi.

Qu’est-ce que l’extension actuelle représente réellement

L’extension Codex IDE d’aujourd’hui fonctionne comme un agent de codage asynchrone. Il s’agit d’un processus qui s’exécute en arrière-plan et qui a la permission de lire le répertoire, de réécrire des fichiers sur le disque et d’exécuter des commandes de terminal, contrairement à l’autocomplétion qui ne propose que le token suivant. Elle n’a rien à voir avec l’API d’autocomplétion Codex de 2021 ni avec le texte généré par Copilot, et tout tutoriel qui la décrit comme une meilleure alternative à la touche Tab parle en réalité d’autre chose.

En mode Agent, le travail est réparti entre le répertoire et le terminal, c’est pourquoi le champ d’application et la capacité de récupération sont plus importants que jamais avec l’autocomplétion. Une suggestion en une ligne reste dans l’éditeur jusqu’à ce qu’elle soit acceptée. Une tâche d’agent peut être exécutée dans src/ tandis que le premier paragraphe de son plan est encore en cours de lecture.

Le mode chat, lorsque l’outil de composition le propose, est uniquement destiné à la discussion, sans possibilité d’édition de fichiers ni d’exécution de commandes. Il convient pour examiner le problème. Agent est la solution à choisir lorsque le arbre doit réellement être déplacé.

Portée, preuves et moyen de revenir en arrière

La documentation propre à l’IDE d’OpenAI ainsi que les articles pratiques s’accordent sur un fait évident concernant l’interface : le mode Agent local applique directement les modifications dans le répertoire de travail. L’extension ne présente pas d’affichage en ligne des différences à accepter ou à rejeter comme le font certains autres éditeurs. Git constitue le bouton « annuler », et sans un répertoire initialisé, il n’existe pas de moyen simple de revenir en arrière.

Trois choses doivent être faites avant la première demande :

  1. Ouvrir un vrai dossier de projet et non un seul fichier.
  2. Commiter ou stocker temporairement tout ce qui ne doit pas être perdu. git stash push -u -m “pre-codex” suffit.
  3. Insérez la vérification d’acceptation dans la demande : quels tests doivent réussir, quel fichier est dans les limites autorisées et à quoi ressemble un état « terminé ».

Une demande bien formulée sur un arbre non commité est plus risquée qu’une demande négligée sur une branche propre.

Lorsque des problèmes surviennent, les dommages sont généralement anodins : un simple renommage, un fichier d’aide intégré au mauvais endroit, des tests qui n’ont jamais été exécutés. Rien d’extrange n’est impliqué. C’est simplement ce que fait l’agent une fois qu’il dispose d’un arbre fonctionnel et que l’utilisateur a imaginé une boîte de suggestions. Ne pas ouvrir de dossier, ne pas utiliser Git, ou demander d’« améliorer la base de code » sans nommer les fichiers n’empêche pas l’extension de s’exécuter, et c’est là le danger.

Installation de la véritable extension

Le chemin le plus simple est court. La vérification d’identité est ce que la plupart des vidéos d’installation omettent.

Vérifier l’éditeur et l’identifiant

Le package correct est l’extension officielle Codex disponible sur le Marketplace, et non un wrapper communautaire portant un nom similaire. Elle est indiquée sous le nom de Codex - l’agent de codage d’OpenAI, publiée par OpenAI, avec l’identifiant unique openai.chatgpt. Cet identifiant permet de distinguer l’article authentique d’un plugin d’autocomplétion indésirable.

Pour ouvrir rapidement l’outil, utilisez Cmd+P sous macOS et Ctrl+P sous Windows et Linux. Collez ce texte et appuyez sur Entrée :

ext install openai.chatgpt

La vue des extensions fonctionne également : recherchez le titre exact et comparez l’éditeur ainsi que l’identifiant avant de cliquer sur Installer. Le nombre d’installations, les évaluations en étoiles et les numéros de version ne constituent pas de preuves fiables, car ils changent constamment.

La page du Microsoft Store dédiée à openai.chatgpt ainsi que la documentation de l’extension IDE Codex d’OpenAI méritent d’être mémorisées. Le flux de travail décrit ici s’appuie sur ces outils sans pour autant les remplacer.

Une fois installé, l’icône de Codex peut être déplacée vers la barre d’activités de droite afin que le code reste à gauche et l’agent à droite, disposition privilégiée par la plupart des utilisateurs. La disparition de l’icône après une mise à jour n’exige pas un réinstallage ; la méthode de récupération indiquée ci-dessous suffit.

Connexion avec un compte ChatGPT

Ouvrez le panneau Codex et sélectionnez « Se connecter avec ChatGPT ». Terminez le redirigement du navigateur vers le compte qui possède réellement le forfait. Les catégories affichées sur le Marketplace sont Plus, Pro, Business, Edu et Enterprise.

GitHub Copilot Pro+ et Copilot Max disposent d’un parcours Insiders distinct, avec l’option « Se connecter avec Copilot » ainsi qu’une vue des sessions d’agent. Ces deux méthodes de connexion sont toutes deux réelles et ne doivent pas être confondues, car il s’agit de boutons différents.

Certains carrousels lors de la première utilisation incluent une étape de configuration dans un environnement de test. Une vidéo d’installation très regardée parcourt les écrans de bienvenue puis choisit l’option d’environnement de test de secours afin que le conteneur local puisse démarrer. Si ce contrôle apparaît, c’est que l’environnement isolé utilisé par l’agent est en cours de mise en place, et il ne s’agit pas d’installer un deuxième produit.

L’accès via ChatGPT est lié à un abonnement. Les budgets de messages, les outils de sélection de modèles ainsi que les montants financiers changent, de sorte que toute indication spécifique concernant les quotas Plus ou Pro mentionnée dans une synthèse de mi-2026 doit être considérée comme obsolète. L’écran d’utilisation actuel du compte constitue la source d’information fiable avant de planifier une session prolongée.

Quand une clé API est utile

La méthode « bring-your-own-key » consiste à s’authentifier à l’aide d’une clé API d’OpenAI plutôt qu’avec un compte ChatGPT. La page de connexion affiche un bouton « Utiliser une clé API ». Cette solution est pratique lorsque le quota de ChatGPT est épuisé ou lorsque l’équipe facture déjà via l’API.

Ce système ne remplace pas un abonnement Plus. Selon les rapports de 2026 sur les tarifs, la facturation via une clé API dans les extensions et la ligne de commande prive de la délégation cloud et de l’analyse de code sur GitHub ; par conséquent, ceux qui ont besoin de ces fonctionnalités doivent rester sur un abonnement ChatGPT.

Lorsque le bouton ne suffit pas, il est possible de définir explicitement la configuration partagée :

preferred_auth_method = "apikey"

Un fichier de clés ne contenant que des placeholders est placé à ~/.codex/auth.json :

{"OPENAI_API_KEY": "YOUR_API_KEY_HERE"}

Si le panneau continue de demander ChatGPT, exportez la clé dans le même shell qui lance l’éditeur, puis ouvrez le dossier à partir de là :

export OPENAI_API_KEY="your-api-key-here"
code .

PowerShell sous Windows utilise $env:OPENAI_API_KEY="votre-clé-api-ici" suivi de code .. Les clés réelles ne doivent pas figurer dans les captures d’écran, les tickets ou les commentaires. Le JSON affiché est un modèle.

Les rapports de la communauté décrivent également un problème spécifique à WSL avec le bouton « Utiliser la clé API ». Sous Windows Subsystem for Linux, un bouton inactif signifie qu’il faut recourir à config.toml ainsi qu’à la variable d’environnement, ou lancer l’éditeur depuis une invite de commande qui possède déjà la clé.

Une première tâche contrôlée

La première tâche n’a pas pour but d’impressionner qui que ce soit. Son objectif est de prouver que Codex dans VS Code accède aux fichiers indiqués, exécute la vérification spécifiée et laisse un diff lisible.

Ouvrez le dossier et indiquez un résultat testable

Choisissez Fichier > Ouvrir dossier et sélectionnez la racine du projet, c’est-à-dire le dossier contenant le fichier de verrouillage, pyproject.toml ou le fichier de solution qui sera réellement compilé. Initialisez Git s’il n’est pas présent, ouvrez le panneau Codex et configurez le composeur en Agent.

Formulez l’objectif de manière à ce qu’un collègue fatigué puisse le vérifier à six heures du soir. Il doit comporter :

  • Un changement de comportement.
  • Une famille de fichiers.
  • Une commande ou un test qui le prouve.

Un exemple d’invite pour la première session pourrait ressembler à ceci :

Update token expiry handling in @src/auth.ts. Run the existing tests and summarize changed files.

La phrase contient un fichier, un résultat et la preuve. « Améliorer l’authentification » ne contient rien de tout cela.

Un panneau caché est accessible via la Palette de commandes en utilisant Codex: Open Codex Sidebar. Chercher dans la barre d’activité de gauche est une perte de temps, car les mises à jour ont déplacé l’icône dans la barre d’outils en haut à droite à plusieurs reprises.

Diriger l’agent vers les bons fichiers

En tapant @nom_fichier, on transmet à l’agent un seul fichier sans submerger le contexte avec toute la structure. Joignez uniquement ce qui est important et indiquez quels fichiers sont interdits. Les conventions peuvent être consignées dans un AGENTS.md situé à la racine du répertoire pour les sessions ultérieures, bien que la simple instruction suffise pour la première tâche.

Concentrez-vous sur une seule tâche pour le premier travail, par exemple gérer l’expiration, corriger un test qui échoue, ajouter une ligne de journal ou rectifier un type. Les refacteurs impliquant plusieurs fichiers viendront plus tard, souvent en tant que travail dans le cloud. Le mode Local Agent commencera volontiers l’un d’eux, mais la patience de l’examinateur ne suffira pas.

Examiner les modifications et les preuves de test

Lorsque l’exécution est terminée, trois éléments méritent d’être vérifiés dans cet ordre :

  1. Fichiers modifiés : vérifier si l’agent est resté dans le chemin spécifié.
  2. Tests : s’assurer qu’ils ont bien été exécutés et s’ils ont réussi.
  3. Git : git diff et git status servent de tableau de contrôle, puisque l’extension a déjà enregistré des données sur le disque.

Même si la carte de résultat indique « Passé » avec src/auth.ts comme seul fichier modifié, il reste nécessaire de lire le diff. Les tests réussis ne disent rien sur le fait qu’un commentaire ajouté doive figurer dans une API publique.

Le résultat de tout cela est un panneau authentifié, une exécution d’Agent ciblée et un changement visible dans Git. Avec un répertoire propre, toute la séquence prend environ huit minutes. Ensuite vient la décision de conserver le changement ou de le réinitialiser, suivie d’une arrêt. Une autre question qui se pose immédiatement concerne la manière dont les utilisateurs en viennent à effectuer une réécriture accidentelle.

Local, cloud ou CLI

Trois approches portent le nom Codex dans VS Code, mais elles n’ont pas le même rayon d’action. La question pratique est de savoir laquelle est nécessaire pour le travail d’aujourd’hui.

L’agent local

Le mode Agent local est l’approche par défaut ici. Le travail s’effectue dans l’espace de travail, et l’examen passe par les fichiers modifiés, les tests et Git. Sa principale limite a déjà été mentionnée : les modifications sont appliquées directement dans l’arbre de travail. Il convient aux modifications limitées qui peuvent être surveillées.

Délégation au cloud

La délégation dans le cloud envoie une tâche plus longue vers un environnement cloud isolé, laissant l’éditeur disponible ou même fermé. Le Marketplace qualifie cela de « Déléguer à Codex dans le cloud ». Les guides de 2026 expliquent comment lier un répertoire sous chatgpt.com/codex/settings/environments, sélectionner cet environnement dans la barre latérale et choisir « Exécuter dans le cloud » par rapport à une branche de base telle que main ou la branche actuelle.

Cela convient aux travaux volumineux, lents ou qui sont mieux présentés sous forme de diff plutôt que de modifications en temps réel. Il faut un accès au cloud du côté de ChatGPT, donc une configuration limitée à une clé API n’est pas le mode d’authentification approprié pour cette fonctionnalité.

Le terminal intégré et la CLI

Le Codex CLI est l’agent natif du terminal, issu de la même famille de modèles mais utilisé depuis une invite de commande et non depuis la barre latérale. Il peut fonctionner dans le terminal intégré de VS Code. L’installation sur la plateforme, les mises à jour ainsi que les paramètres de sandbox figurent dans un guide d’installation CLI et ne sont pas répétés ici.

C’est la décision qui compte ici. Le CLI est le choix idéal pour un contrôle prioritaire via le terminal, en cas de dysfonctionnement de la barre latérale, ou pour des exécutions longues de /review qui échouent constamment dans l’extension. Des documents de 2026 montrent que le simple codex ouvre une session interactive, tandis qu’une instruction entre guillemets transmise à codex exec s’exécute une seule fois sans interaction, par exemple pour lui demander de corriger tous les erreurs de linting dans src/. Installez le CLI uniquement s’il est manquant.

La question de savoir quel outil privilégier en général est distincte de la manière dont l’agent VS Code fonctionne, et une comparaison entre Claude Code et Codex y répond.

Une couche de configuration commune pour les deux

Un fait architectural qui apparaît rarement sur les pages du Marketplace : l’extension VS Code est à code fermé, et ses développeurs la décrivent comme une interface utilisateur entourant la CLI open source Codex. Cela explique pourquoi un seul dossier peut influencer le comportement des deux outils.

Le répertoire partagé ~/.codex/

Sur macOS et Linux, le répertoire commun est ~/.codex/ ; dans ce répertoire, config.toml contient les paramètres par défaut et auth.json les identifiants. Tant l’extension que la CLI le lisent, de sorte qu’une modification affecte les deux interfaces.

L’équivalent sous Windows se trouve dans le profil utilisateur. Les configurations à distance et celles utilisant un serveur de code ajoutent d’autres copies de auth.json à l’intérieur du dossier des extensions, ce qui constitue des solutions de contournement et non une seconde source fiable. ~/.codex/ est le meilleur endroit possible. Il est plus facile de corriger le texte que d’utiliser une capture d’écran de ce dossier.

Paramètres par défaut basés sur une source

Un exemple global circule dans les guides de 2026 concernant l’éditeur :

# ~/.codex/config.toml
model = "gpt-5.3-codex"
approval_mode = "agent"

Considérez la chaîne de modèle comme étant éphémère. Les noms présentés dans les tutoriels ont déjà évolué, allant de GPT-5.1 à GPT-5.3-Codex, pour arriver aux versions ultérieures GPT-5.x. Lorsque le panneau affiche unexpected status 400 Bad Request: {"detail":"Unsupported model"}, cela signifie que le sélecteur propose un nom que cette version du logiciel ne peut pas gérer. Choisissez d’abord un modèle pris en charge dans l’interface ; si vous souhaitez néanmoins utiliser un modèle par défaut, indiquez celui qui a réellement été sélectionné.

La valeur par défaut pour approval_mode = "agent" permet de lire et d’éditer des fichiers dans l’espace de travail, d’exécuter des commandes dans le répertoire de travail ainsi que sur un réseau restreint. Le mode « Chat uniquement » ne permet que des discussions. Le mode « Agent – Accès complet » élargit les possibilités d’exécution locale et autorise les recherches sur Internet. Le mode choisi doit correspondre à la tâche à effectuer, et l’accès complet ne doit pas être activé simplement parce qu’une installation npm la semaine précédente nécessitait l’accès au réseau.

La préférence relative à la clé API mentionnée dans la section précédente se trouve dans le même fichier. En regroupant la politique d’authentification et la politique d’approbation, l’ensemble du contrat peut être lu en vingt secondes.

Boucles d’approbation et indicateur de chargement de Windows

Ces problèmes sont ceux que les guides de configuration ignorent et que les utilisateurs recherchent dès que Codex cesse de fonctionner dans VS Code. Ils ressemblent à des bugs de produit, et ce sont parfois le cas. D’autres fois, le sandbox avertit que l’agent est sur le point de faire quelque chose que personne n’a supervisé. Être plus fluide ne signifie pas être plus sûr.

Réduire les obstacles à l’approbation sans enlever les contraintes

Les utilisateurs de Windows décrivent en particulier un cercle vicieux de permissions, avec une pause à chaque lecture ou écriture de fichier. Le logiciel propose des options Chat, Agent et Agent Full Access. Cette dernière option masque la plupart des demandes, car elle autorise des actions locales et une utilisation du réseau plus étendues. C’est là le véritable compromis, et c’est aussi pourquoi une demande de renommer une fonction se transforme en téléchargement non planifié d’un package.

Une solution de contournement proposée par la communauté et souvent mentionnée concerne cette ligne de configuration :

approval_mode = "auto"

Certaines discussions proposent une valeur intermédiaire appelée workspace-write, et, à l’extrême, danger-full-access. Ces deux noms proviennent de publications communautaires, et aucun d’eux ne justifie de configurer l’agent pour un répertoire personnel.

Un mode automatique ou un mode composer plus étendu n’est raisonnable que si toutes les conditions suivantes sont remplies :

  • Git affiche un arbre propre, ou les modifications ont été mises de côté.
  • Aucun secret ne se trouve dans l’espace de travail, ou Git les ignore.
  • La portée du fichier peut être décrite en une seule phrase.
  • git diff est lu avant tout envoi.

Si l’une de ces conditions n’est pas remplie, conservez les demandes de confirmation. Le cycle est agaçant, mais une écriture silencieuse dans .env est encore pire.

L’expérience montre les limites de l’approche directe. Le passage à l’accès complet en tant que solution pour « cesser simplement de demander » a effectivement mis fin aux sollicitations, mais la session a également acquis un accès au réseau qui n’était jamais nécessaire avec un simple renomage local. La ligne de configuration fonctionne comme un scalpel, tandis que l’accès complet agit comme un seau.

Le cas de chargement de WSL sous Windows 11

Un cas documenté sous Windows 11 fait que le panneau reste bloqué sur « Chargement ». Dans l’issue #7082 de openai/codex, les utilisateurs ont identifié le problème comme étant lié à la configuration d’intégration WSL. Les premières réponses des mainteneurs ont attribué le problème à une panne régionale, tandis que des réponses ultérieures ont proposé une correction encore utilisée aujourd’hui.

Dans Paramètres, recherchez Codex WSL, trouvez « Exécuter Codex dans le sous-système Windows pour Linux » et désactivez-le, puis rouvrez le panneau dans l’environnement de exécution souhaité. Il s’agit d’une modification dans les Paramètres et non d’un paramètre en ligne de commande, donc il ne faudrait pas inventer l’option codex --no-wsl, puisqu’aucune source ne la mentionne.

Tout ceux qui souhaitent vraiment utiliser Codex dans WSL2 doivent conserver le projet sur le système de fichiers Linux ainsi que les outils correspondants dans cet environnement. Un répertoire situé sur le système Windows associé à un agent Linux est la cause de problèmes de limites de fichiers et de permissions, ce qui rend le panneau difficile à utiliser.

Après le changement, vérifiez que la CLI démarre toujours dans le terminal fiable. Une CLI fonctionnelle accompagnée d’un panneau défaillant indique un problème avec WebView ou une extension, et non un problème d’authentification. Si les deux fonctionnent mal, l’authentification est la première cause à examiner.

Séparation des temps d’exécution et des historiques

Les historiques de chat de Codex sont isolés entre les systèmes de fichiers Windows et WSL. Le changement de mode affiche des threads différents. Il ne s’agit pas d’un bug de synchronisation, mais bien de deux espaces distincts.

Un environnement d’exécution par répertoire, conservé pendant une semaine, évite toute confusion. Lorsqu’un changement est inévitable, supposez que la conversation ne se poursuivra pas. Les instructions permanentes doivent se trouver dans AGENTS.md du répertoire, et non dans un fil de barre latérale qui disparaîtra d’ici mardi.

Associer le symptôme à la correction

Partez du symptôme. Appliquer la solution WSL à un icône cachée prend vingt minutes. Un panneau manquant, un nom de modèle refusé, une évaluation échouée et un accès distant qui ne revient jamais correspondent à quatre corrections différentes, à essayer une par une sans les combiner.

Barre latérale cachée ou modèle non pris en charge

Si l’icône a quitté la barre de gauche, jetez un coup d’œil en haut à droite avant de réinstaller. Le problème n°14586 indique que les mises à jour conservent l’accès via un contrôle de barre latérale Open Codex dans la barre d’outils, et la palette de commandes propose également Codex: Open Codex Sidebar.

Si le panneau s’ouvre puis échoue immédiatement avec unexpected status 400 Bad Request: {"detail":"Unsupported model"}, le modèle choisi n’est pas valide pour la version installée. Le sélecteur en bas du panneau liste ceux qui sont pris en charge. Une fois le modèle sélectionné, ~/.codex/config.toml doit être mis à jour afin qu’une ligne model = "..." obsolète ne provoque plus le même erreur.

Les panneaux vides et les boucles de connexion se situent à un niveau inférieur, dans le WebView, les cookies ou un jeton invalide. La solution peu élégante consiste à se déconnecter, à supprimer la session ChatGPT dans le navigateur et à se reconnecter. Réinstaller en utilisant un jeton invalide ne fait qu’afficher un nouvel icône au-dessus du même fichier d’authentification.

Les analyses longues devraient se faire via la CLI

La commande /review de l’extension présente un temps d’attente rapporté d’environ cinq minutes. Dans un grand répertoire, l’exécution peut se terminer par l’agent indiquant qu’il a déjà appliqué de nombreuses corrections et qu’il manque de temps pour identifier précisément les problèmes.

Ces cinq minutes s’appliquent dans la barre latérale, tandis qu’aucune limite correspondante n’est mentionnée pour la même revue via la ligne de commande. Toute personne qui souhaite effectuer une revue et constate que la fenêtre s’éteint doit l’exécuter depuis la CLI de Codex dans le terminal intégré et examiner le résultat dans Git. Relancer /review dans la barre latérale ne modifiera pas ce délai. Un processus de revue plus approfondi, incluant la demande de revue sans déclencher une réécriture, mérite son propre guide.

SSH distant et machines headless

OAuth via le navigateur échoue systématiquement sur des machines distantes SSH, Docker, vscode-server et autres machines sans interface, car la page de connexion ne peut pas revenir à l’hôte qui a besoin du jeton. La discussion GitHub #4650 rassemble les expériences de la communauté.

La solution de contournement la plus proche de celle officielle consiste au redirigement de port dans VS Code : dans l’onglet PORTS, choisissez « Forward a Port », saisissez 1455, assurez-vous que l’adresse affichée soit localhost:1455, puis exécutez :

codex login

Étape du navigateur : elle s’effectue sur la machine capable d’ouvrir un navigateur, et le port redirigé transmet la réponse à la session distante.

La copie des identifiants est l’option la plus complexe. Connectez-vous sur un ordinateur portable où OAuth fonctionne, puis déplacez ~/.codex/auth.json dans le chemin des extensions distantes. Pour Code Server, le répertoire cible est ~/.local/share/code-server/extensions/openai.chatgpt-[version]/. Sous Windows, le répertoire correspondant se trouve dans le profil utilisateur sous .vscode\extensions. Dans les deux cas, [version] désigne le suffixe du répertoire installé, et le fichier est placé à l’intérieur sous le nom auth.json. Ce fichier n’est pas inclus dans les commits ni dans les journaux de conversation, car il fonctionne comme une cookie de session. Redirigez d’abord, et ne copiez que si la redirection est impossible.

VS Code : l’éditeur adapté ?

Les pages anciennes peuvent amener les lecteurs à chercher un plugin obsolète, donc une limite à jour est utile.

JetBrains et VS Code

VS Code s’appuie sur l’extension officielle Codex IDE, identifiée par openai.chatgpt. Les IDEs JetBrains constituent un système distinct. Des articles anciens de PyCharm affirmaient qu’il n’y avait pas de version native de Codex, ce qui est désuet : JetBrains a annoncé un support natif en janvier 2026, à partir de la version 2025.3 de l’IDE, couvrant IntelliJ IDEA, PyCharm, WebStorm et Rider. Les recherches concernant IntelliJ ou PyCharm Codex mènent à cette voie native et non à l’identifiant du Marketplace. Les utilisateurs de JetBrains devraient se référer à la documentation officielle de l’AI Assistant et de Codex fournie par JetBrains.

Les utilisateurs de Cursor doivent effectuer une nouvelle installation et configurer un nouveau panneau. Le flux du Marketplace dans VS Code ne doit pas être imposé au système d’extensions de Cursor, qui dispose de sa propre voie pour les plugins.

Visual Studio Community 2022

Visual Studio Community 2022 n’apparaît pas dans la liste des clients GPT-5.1-Codex pris en charge. Une discussion communautaire sur GitHub énumère quatre outils dans cette version préliminaire : VS Code, JetBrains, Xcode et Eclipse. Les développeurs C# qui continuent à travailler dans Visual Studio le conservent souvent pour la compilation et utilisent VS Code en parallèle pour les extensions sur les mêmes fichiers, ce qui est peu pratique et constitue pour l’instant la solution recommandée selon la documentation.

Une tâche limitée aujourd’hui

Un bon point de départ est un répertoire déjà bien connu. Mettez à jour l’arbre de travail avec un commit ou un stash jusqu’à ce que git status ne montre rien, installez l’extension si elle manque, connectez-vous et ouvrez le dossier. Ensuite, envoyez une tâche Agent désignant un fichier et un test, de manière à ce qu’ils puissent être affichés ensemble sur une seule page de diff.

Observez les fichiers changer, lisez la différence et conservez-la ou réinitialisez-la. C’est ce cycle qui caractérise l’utilisation de Codex dans VS Code, contrairement à une simple installation.

Les éditeurs continueront d’ajouter des boutons, la délégation vers le cloud deviendra plus fluide et les noms de modèles changeront à nouveau. Ce qui reste coûteux, c’est de donner des droits d’écriture à une structure qui ne peut pas être déroulée. Une fois cette partie devenue ennuyeuse, le reste de l’agent peut devenir intéressant.

Il y a une habitude à adopter. La prochaine fois que le panneau demandera l’approbation pour écrire dans un fichier, dites à haute voix la commande Git qui permettrait de revenir en arrière. Si vous ne pouvez pas terminer la phrase, mettez d’abord le fichier de côté et demandez à nouveau, car cette pause constitue toute la révision.

Lectures complémentaires

  • RAG agentiel avec Agno Teams : réécriture des queries, boucle de critique et Qdrant — Une équipe de coordination réécrit les queries, itère la récupération d’informations avec un module de critique et ne répond que à partir de contextes approuvés, en utilisant des méthodes de recherche hybrides dense, BM25 et ColBERT dans Qdrant.
  • Cinq couches au sein de Claude Code : mémoire, compétences, hooks, sous-agents et plugins — Claude Code considéré comme un environnement d’exécution d’agents : mémoire CLAUDE.md, compétences sur demande, hooks déterministes, sous-agents isolés et plugins qui regroupent tout cela pour une équipe.
  • Le plugin Codex pour Claude Code : installation, configuration, évitement des boucles de révision — Comment exécuter Codex et Claude Code ensemble : choisir un hôte, installer le plugin officiel, partager les règles AGENTS.md, utiliser les commandes de révision et de sauvetage, et limiter les boucles de révision.
  • Les compétences Agent sont du code : définir leur portée, les divulguer, les scripter et les tester — Pourquoi SKILL.md constitue la logique de production : n’écrire que des connaissances procédurales, ajuster l’activation, charger progressivement, transférer le travail précis vers des scripts, créer des évaluations et supprimer les éléments inefficaces.
  • Claude Code ou Codex en septembre 2026 : prix, modèles et adaptation — Local et synchrone contre cloud et asynchrone : en quoi Claude Code et Codex diffèrent en termes de coût, de référentiels, de flux de travail et de résidence des données en UE.
  • API des agents d’OpenAI : un outil Codex géré et ce que les équipes possèdent encore — Comment l’API des agents d’OpenAI gère automatiquement l’outil Codex pour vous, avec des sessions, des outils MCP, des sous-agents et des environnements de test, ainsi que les contrôles de vérification, d’accès et les limites de données auxquelles votre équipe est encore soumise.