Si Codex indique que l’accès au navigateur est indisponible, notez la première erreur et identifiez le chemin utilisé. Un outil absent, une origine bloquée et une page inaccessible exigent des contrôles différents. Commencez par une URL exacte et une tâche en lecture seule.
Consigner l’erreur et l’environnement
Notez le message exact, l’heure, la version et le build, le système, le point d’entrée Codex et l’outil. Indiquez si le navigateur s’est ouvert, si l’adresse a changé et si une page publique simple fonctionne par le même chemin. Masquez comptes, URL internes et identifiants. Une erreur avant navigation invite à vérifier l’outil, son lien à la session et les règles.
| Vérification | Option |
|---|---|
| Outil absent | @Browser / Computer Use |
| URL ou titre différent | URL / localhost |
| Page de connexion | Vérifier le profil |
Vérifier l’outil et les droits effectifs
Pour le navigateur intégré, vérifiez que la session propose @Browser et que l’accès local est activé. Pour une extension compatible, vérifiez Settings > Computer Use et le profil actif. Une règle d’espace de travail peut bloquer une fonction ou une origine même si le réglage local est actif. Demandez à l’administrateur de vérifier la règle effective. Un fichier local ne peut pas lever un refus géré.
Distinguer connexion du navigateur et accès à la page
Une fois l’outil lancé, vérifiez son URL exacte. Un refus de connexion signale une adresse sans service à l’écoute ou un rejet local. Vérifiez l’adresse, le port, le processus et le trajet avant de redémarrer. Dans le cloud, localhost désigne l’environnement distant. Un écran de connexion indique que la page répond, mais le profil peut être différent ou non connecté.
Reproduire une erreur et confirmer le rétablissement
Dans une même tâche Codex sur ordinateur, nous avons utilisé Tabbit CLI externe et une page HTTP de test. Le port local 60206 sans service a renvoyé net::ERR_CONNECTION_REFUSED. Seule l’URL a changé, vers le port 60205 qui hébergeait la page. La même tâche et le même onglet ont renvoyé HTTP 200, le titre Browser Connection Restored et le repère B03-RECOVERED. Le paquet de l’app était 26.1029.61003, build 24614. Le rétablissement concernait le transport. Les droits natifs et les routes cloud n’ont pas été testés.
GET http://127.0.0.1:60206/ → net::ERR_CONNECTION_REFUSED
GET http://127.0.0.1:60205/ → HTTP 200 → B03-RECOVERED| Environnement | Vérification |
|---|---|
| 60206 | ERR_CONNECTION_REFUSED |
| 60205 | HTTP 200 · B03-RECOVERED |
Si la panne persiste, refaire un test contrôlé
Pour une extension compatible, OpenAI recommande de vérifier le blocage du site, de mettre à jour l’app, de vérifier le profil et d’essayer une nouvelle conversation avant de redémarrer. Changez un seul paramètre et répétez le test en lecture seule avec le même chemin et la même cible. Comparez les deux résultats. Si le repère manque encore, signalez l’erreur via le canal officiel.
Ce que montrent les témoignages
Un utilisateur de r/codex rapporte que le bureau fonctionnait mais que la CLI ou l’éditeur échouait. Un autre voyait les onglets mais rencontrait une erreur de vérification des droits enregistrés. Ces cas orientent des contrôles différents. Ils ne démontrent aucune cause commune, et la modification de fichiers décrite sur un forum ne constitue pas une procédure générale.
r/codex · Browser access r/codex · Saved permissions
Redémarrer Codex rétablit-il toujours l’accès ?
Un redémarrage peut effacer un état périmé. Une origine bloquée, un outil absent, un port erroné ou une route cloud se vérifient séparément.
Questions fréquentes
Redémarrer Codex rétablit-il toujours l’accès ?
Un redémarrage peut effacer un état périmé. Une origine bloquée, un outil absent, un port erroné ou une route cloud se vérifient séparément.
Codex dans le cloud peut-il accéder au localhost de mon ordinateur ?
Une fois l’outil lancé, vérifiez son URL exacte. Un refus de connexion signale une adresse sans service à l’écoute ou un rejet local. Vérifiez l’adresse, le port, le processus et le trajet avant de redémarrer. Dans le cloud, localhost désigne l’environnement distant. Un écran de connexion indique que la page répond, mais le profil peut être différent ou non connecté.
Que vérifier si @Browser est absent ?
Pour le navigateur intégré, vérifiez que la session propose @Browser et que l’accès local est activé. Pour une extension compatible, vérifiez Settings > Computer Use et le profil actif. Une règle d’espace de travail peut bloquer une fonction ou une origine même si le réglage local est actif. Demandez à l’administrateur de vérifier la règle effective. Un fichier local ne peut pas lever un refus géré.
Comment vérifier le rétablissement ?
Pour une extension compatible, OpenAI recommande de vérifier le blocage du site, de mettre à jour l’app, de vérifier le profil et d’essayer une nouvelle conversation avant de redémarrer. Changez un seul paramètre et répétez le test en lecture seule avec le même chemin et la même cible. Comparez les deux résultats. Si le repère manque encore, signalez l’erreur via le canal officiel.
Que faut-il consigner si l’accès échoue ?
Notez le message exact, l’heure, la version et le build, le système, le point d’entrée Codex et l’outil. Indiquez si le navigateur s’est ouvert, si l’adresse a changé et si une page publique simple fonctionne par le même chemin. Masquez comptes, URL internes et identifiants. Une erreur avant navigation invite à vérifier l’outil, son lien à la session et les règles.