Navigateur Codex indisponible : vérifications et récupération

La page était visible, mais Codex ne pouvait pas commander le navigateur. Deux problèmes sur le même ordinateur —une connexion au navigateur absente et une ancienne page d’erreur— ont nécessité des mesures différentes. Cet article explique l’ordre des contrôles et ce qui a réellement refonctionné.

Navigateur intégré, intégration Chrome et recherche web

Demander à Codex de « chercher dans le navigateur » ne fait pas toujours appel au même mécanisme. Identifier la fonction en panne et ce qu’elle ne peut pas faire évite des changements de réglages inutiles.

La documentation officielle du navigateur d’OpenAI indique que Codex dans l’application de bureau peut ouvrir le navigateur intégré, cliquer, saisir du texte et inspecter les pages. Elle ne dit pas que la CLI ou l’extension IDE disposent elles-mêmes d’un navigateur intégré. Il faut d’abord distinguer où l’on utilise Codex.

Le navigateur intégré possède un profil distinct du navigateur habituel. La présence de l’extension Chrome ne prouve pas que la commande du navigateur intégré est connectée. Inversement, un navigateur intégré fonctionnel ne partage pas automatiquement les onglets existants de Chrome. Explication d’OpenAI sur le navigateur et son profil

Nous avons donné la priorité au navigateur intégré et utilisé Chrome pour vérifier une autre voie de connexion. Nous avons distingué l’affichage, la connexion au navigateur et les opérations sur un site, plutôt que de tout ramener à « cela fonctionne ou non ».

La page s’ouvre, mais Codex ne trouve pas le navigateur

L’enquête a commencé quand Codex a signalé qu’il ne pouvait plus effectuer des opérations qui fonctionnaient auparavant. Le navigateur était activé dans les réglages de l’application et l’extension Chrome était indiquée comme installée. Il était aussi possible d’ouvrir des pages dans le navigateur intégré.

Pourtant, l’inventaire de l’interface de commande ne permettait d’obtenir ni le navigateur intégré ni Chrome. La seule cible visible correspondait à une surface distincte de MCP Apps. Ce que voyait l’utilisateur ne correspondait pas aux cibles accessibles à Codex.

Pour confirmer la récupération, il fallait vérifier que Codex pouvait obtenir l’onglet, lire son contenu et suivre les liens, en plus de constater l’affichage de la page.

Trois symptômes à distinguer d’abord

Un problème de connexion comme celui-ci exige d’autres contrôles qu’une panne limitée à un seul site. Commencez par identifier jusqu’où va l’opération.

Ne demandez pas seulement de « réparer le navigateur ». Décrivez plutôt une séquence précise : ouvrir une page publique → lire un titre → cliquer sur un lien visible → revenir en arrière. Cela évite de confondre une recherche web réussie avec des clics fonctionnels dans le navigateur.

Un autre chat où un simple rechargement a suffi

Dans un autre chat de développement, une page « Ce site est inaccessible » était restée dans l’onglet après l’arrêt du serveur local. Même une fois le serveur rétabli, l’obtention de l’onglet par Codex était rejetée, car le format de l’URL n’était pas autorisé.

L’URL réelle indiquée par l’inventaire normal des onglets utilisait le format data:, qui contient directement du HTML. Quand l’utilisateur a rechargé normalement cet onglet, l’URL réelle est redevenue HTTP et Codex a pu lire les titres et les boutons. Aucun redémarrage complet ni changement d’autorisation n’a été nécessaire.

Ce cas diffère d’une connexion au navigateur absente de l’inventaire. Dans ce chat, seule la lecture du contenu a été vérifiée, pas l’entrée dans le jeu ni sa commande. La cause interne des erreurs précédentes de voie de connexion reste également indéterminée.

Ce que nous avons changé avant la récupération

Sur cet ordinateur, les données réelles du répertoire principal de Codex se trouvaient déjà à D:\CodexHome. L’emplacement par défaut %USERPROFILE%\.codex était une jonction vers D, mais les variables CODEX_HOME de l’utilisateur et de la machine n’étaient pas définies.

OpenAI présente CODEX_HOME comme la racine des réglages, de l’authentification, des journaux, sessions, skills et états associés. Nous l’avons utilisé pour tester une référence directe au chemin réel existant sur D. Il n’est pas documenté comme un réglage dédié à la réparation du navigateur. Spécification des variables d’environnement d’OpenAI

1. Nous avons arrêté l’application et les processus Codex associés. Après confirmation que les autres chats avaient terminé leur travail, nous avons sauvegardé les données avec ces processus arrêtés.
2. Nous avons copié le répertoire principal et d’autres données, puis vérifié le contenu. Nous avons comparé nombre, tailles et dates de modification pour environ 68.6Go répartis dans 445,279 fichiers, ainsi que les empreintes de 144 fichiers importants.
3. Nous avons indiqué le chemin réel sur D pour un seul lancement. Après fermeture complète de la même version, nous avons lancé l’application et confirmé que le shell et la configuration de commande générée référençaient D.
4. Nous avons testé séparément le navigateur intégré et Chrome. Les deux ont pu être obtenus ; lecture des pages et opérations sur les liens ont réussi.
5. Nous avons aussi vérifié le démarrage habituel. Après autorisation, nous avons défini la variable d’environnement utilisateur. Une nouvelle instance ouverte depuis la barre des tâches utilisait les mêmes références et réussissait les mêmes opérations.

Nous n’avons surtout pas commencé par déplacer l’application sur un autre lecteur. La récupération du navigateur a été confirmée avant le déplacement. Une autre panne s’est produite lors de ce déplacement ultérieur ; ce cas ne justifie donc pas d’utiliser cette fonction Windows pour réparer le navigateur.

Nous n’avons pas supprimé la jonction ni réécrit manuellement la configuration MCP. Nous avons lu les références générées après le démarrage pour vérifier leur conformité à l’état prévu. La différence entre répertoire principal et application est expliquée dans notre récit de migration de C vers un autre lecteur.

Opérations de confirmation

Après la récupération, nous ne nous sommes pas contentés de voir le navigateur dans l’inventaire : nous avons commandé des pages publiques. Ces contrôles ne demandaient ni connexion au compte, ni achat, ni envoi de fichier.

Nous n’avons pas conservé l’inventaire des onglets privés existants de Chrome comme preuve pour l’article. Un nouvel onglet de test suffisait. Enquêter sur le navigateur n’exige pas de collecter les e-mails ouverts ou les sites internes d’une entreprise.

Nous avons aussi vérifié l’état enregistré. Les éléments sélectionnés, dont 2 chats épinglés, 18 projets épinglés et 63 projets locaux, correspondaient à la sauvegarde. Le contrôle du statut de connexion de la CLI a également réussi. Il n’a pas fallu reconstruire l’historique ni se reconnecter.

Redémarrer l’application est différent de redémarrer le PC. Nous avons vérifié le premier cas, mais reporté les contrôles après redémarrage du PC et futures mises à jour à un moment convenant à l’utilisateur. Ces résultats couvrent la récupération immédiate et le démarrage normal de l’application.

Actions à éviter au départ

Supprimer les données de l’application ou les profils du navigateur avant de distinguer les problèmes de connexion, de site et de stockage risque de faire perdre sessions, réglages et preuves de comparaison. Nous n’avons ni effacé toutes les données du navigateur ni réinstallé l’application pour récupérer son fonctionnement.

Restaurer les anciennes skills du navigateur n’était pas non plus notre solution habituelle. Sur cet ordinateur, leur absence faisait partie du passage à Computer Use unifié. Un ancien fichier manquant ne suffit pas à identifier la cause d’une panne.

Nous n’avons utilisé aucun réglage interne non documenté, modifié le code de l’application ni remplacé d’exécutable. Un changement de version pourrait sembler rétablir le fonctionnement, mais ce ne serait plus une comparaison avant-après sur la même version.

Il n’a pas non plus fallu assouplir progressivement la sécurité alors que les autorisations requises du navigateur intégré et de Chrome étaient déjà actives. L’autorisation de commander un site est distincte de la confiance accordée à son contenu. Choisissez une page de test sans informations sensibles ni actions lourdes de conséquences.

Informations à conserver si la panne persiste

Pour l’assistance ou une enquête, noter jusqu’où va chaque opération est plus utile qu’un simple « cela ne fonctionne pas ». Ici, la différence importante était que les pages s’affichaient, mais que les cibles de commande restaient introuvables ; après récupération, même la navigation par liens fonctionnait.

• La version de l’application et l’usage du bureau, de la CLI ou de l’IDE.
• Si le symptôme touche le navigateur intégré, Chrome ou les deux.
• Si vous pouvez ouvrir la page manuellement, si Codex peut la lire et cliquer.
• Si un seul site est concerné ou aussi des pages publiques sans connexion.
• Si vous avez tout fermé puis lancé une nouvelle instance, et si vous utilisez un autre lecteur ou un répertoire principal personnalisé.
• L’heure de la panne et le message exact. Excluez les journaux bruts contenant des secrets.

Pour vérifier l’emplacement du répertoire principal, distinguez la valeur $env:CODEX_HOME du shell, le réglage utilisateur de Windows et la valeur utilisée par l’application en cours. Si vous n’utilisez pas d’emplacement personnalisé, il n’est pas nécessaire d’imiter ce cas en ciblant un dossier vide sur D.

Un historique inaccessible ou un échec limité à l’envoi ne sont pas nécessairement des problèmes de commande du navigateur. Selon le message, vous pouvez aussi consulter notre article Codex thread not found : vérifier l’historique.

Ordre de vérification tiré de ce cas

Commencez par vérifier où vous utilisez Codex et quel navigateur est concerné. Si une page d’erreur reste après le rétablissement du serveur, rechargez normalement l’onglet. Testez ensuite séparément affichage, lecture et clics sur une page publique. En l’absence totale de connexion au navigateur, enregistrez le travail et envisagez une fermeture complète suivie d’un redémarrage. Si le répertoire principal a été déplacé, vérifier l’emplacement référencé peut aussi être utile.

Sur cet ordinateur, c’est la combinaison du chemin réel du répertoire principal déjà présent sur D et d’un lancement après fermeture complète qui a fonctionné. Nous pouvons constater la récupération, mais pas attribuer la panne à la seule jonction. Tester les changements réversibles un par un est plus praticable que de traiter le déplacement d’applications ou l’effacement des données comme des remèdes universels.

Questions fréquentes

Si la page est visible, Codex peut-il la commander ?

Sur cet ordinateur, la page était visible, mais ne pouvait pas être obtenue comme cible de commande. Vérifiez aussi la lecture du contenu et les clics sur les liens.

Installer l’extension Chrome répare-t-il le navigateur intégré ?

Le navigateur intégré et Chrome utilisent des voies distinctes. Vérifiez laquelle échoue. Nous les avons également testées séparément ici.

Définir CODEX_HOME résout-il toujours le problème ?

Nous ne l’avons pas établi. Nous avons indiqué le chemin réel et fermé puis redémarré complètement l’application en même temps, après quoi elle a refonctionné. Cela ne justifie pas de recommander d’abord une migration du répertoire principal si son emplacement n’a pas changé.

Faut-il déplacer l’application sur D pour récupérer le navigateur ?

Le navigateur a refonctionné avant le déplacement de l’application. Déplacer une application Windows est distinct de réparer la commande du navigateur.