El navegador no funciona en Codex: comprobaciones y recuperación

La página se veía, pero Codex no podía controlar el navegador. Dos problemas en el mismo equipo —una conexión con el navegador ausente y una página de error antigua— necesitaron medidas distintas. Este artículo explica el orden de las comprobaciones y qué se recuperó realmente.

Navegador integrado, integración con Chrome y búsqueda web

Pedir a Codex que «lo busque en el navegador» no siempre utiliza el mismo mecanismo. Identificar qué función falla y qué no puede hacer ayuda a evitar cambios de configuración innecesarios.

La documentación oficial del navegador de OpenAI indica que Codex en la aplicación de escritorio puede abrir el navegador integrado, hacer clic, escribir e inspeccionar páginas. No afirma que la CLI o la extensión del IDE tengan por sí mismas un navegador integrado. Primero hay que distinguir desde dónde se usa Codex.

El navegador integrado tiene un perfil distinto del navegador habitual. Que la extensión de Chrome esté instalada no demuestra que el control del navegador integrado esté conectado. Del mismo modo, que este funcione no comparte automáticamente las pestañas existentes de Chrome. Explicación de OpenAI sobre el navegador y su perfil

Priorizamos el navegador integrado y utilizamos Chrome para comprobar una vía de conexión independiente. Evitamos reducir la visualización de páginas, la conexión con el navegador y las operaciones de un sitio a un único resultado de «funciona o no».

La página se abre, pero Codex no encuentra el navegador

La investigación comenzó cuando Codex empezó a informar de que ya no podía realizar operaciones que antes funcionaban. El navegador estaba habilitado en los ajustes de la aplicación y Chrome mostraba su extensión instalada. También era posible abrir páginas en el navegador integrado.

Sin embargo, el inventario de la interfaz de control no permitía obtener ni el navegador integrado ni Chrome. El único destino visible correspondía a una superficie independiente de MCP Apps. La pantalla que veía el usuario no coincidía con los destinos de control disponibles para Codex.

Para confirmar la recuperación debíamos comprobar que Codex pudiera obtener la pestaña, leer su contenido y utilizar enlaces, además de que la página se mostrara.

Tres síntomas que conviene distinguir primero

Un problema de conexión como este necesita comprobaciones distintas de un fallo que afecta a un solo sitio. Primero identifica hasta qué punto llega la operación.

Haz una prueba más concreta que «repara el navegador»: pídele abrir una página pública → leer un encabezado → pulsar un enlace visible → volver atrás. Así no se confunde una búsqueda web correcta con clics que funcionan en el navegador.

Otro chat donde bastó recargar para resolverlo

En otro chat de desarrollo quedó abierta una página de «No se puede acceder a este sitio» de cuando el servidor local estaba detenido. Aunque el servidor se había recuperado, el intento de Codex de obtener la pestaña se rechazaba porque el formato de URL no estaba permitido.

La URL real indicada por el inventario normal de pestañas utilizaba el formato data:, que contiene HTML directamente. Cuando el usuario recargó normalmente esa pestaña, la URL real volvió a HTTP y Codex pudo leer los encabezados y botones. No fue necesario reiniciar toda la aplicación ni cambiar permisos.

Este caso es distinto de que falte la conexión con el navegador en el inventario. En aquel chat solo se verificó la lectura de contenido, no la entrada al juego ni su control. La causa interna de los errores previos de la vía de conexión sigue sin determinarse.

Qué cambiamos antes de la recuperación

En este equipo, los datos reales del directorio principal de Codex ya estaban en D:\CodexHome. La ubicación predeterminada %USERPROFILE%\.codex era una unión hacia D, pero las variables CODEX_HOME de usuario y de equipo no estaban configuradas.

OpenAI documenta CODEX_HOME como raíz de ajustes, autenticación, registros, sesiones, skills y estado relacionado. Aquí la utilizamos para probar una referencia directa a la ruta real ya existente en D. No se documenta como un interruptor específico para reparar el navegador. Especificación de variables de entorno de OpenAI

1. Detuvimos la aplicación y los procesos relacionados de Codex. Tras confirmar con el usuario que los otros chats habían terminado, hicimos la copia con esos procesos detenidos.
2. Copiamos el directorio principal y otros datos y comprobamos el contenido. Comparamos cantidades, tamaños y fechas de modificación de unos 68.6GB repartidos en 445,279 archivos, además de hashes de 144 archivos importantes.
3. Especificamos la ruta real de D para un único inicio. Tras cerrar por completo la misma versión de la aplicación, la iniciamos y confirmamos que el shell y la configuración de control generada apuntaban a D.
4. Probamos por separado el navegador integrado y Chrome. Pudimos obtener ambos y funcionaron la lectura de páginas y los enlaces.
5. También comprobamos el inicio habitual. Tras obtener autorización, configuramos la variable de entorno del usuario. Una instancia nueva abierta desde la barra de tareas utilizó las mismas referencias y superó las mismas operaciones.

Es importante que no trasladamos primero la aplicación a otra unidad. La recuperación del navegador se confirmó antes del traslado. Durante ese traslado posterior hubo un fallo distinto, por lo que este caso no justifica utilizar la función de mover aplicaciones de Windows para reparar el navegador.

Tampoco borramos la unión ni reescribimos manualmente la configuración de MCP. Leímos las referencias de la configuración generada después del inicio para comprobar que coincidieran con lo previsto. La diferencia entre el directorio principal y la aplicación se explica en nuestro registro de migración desde C a otra unidad.

Operaciones para confirmar la recuperación

Después de la recuperación no nos limitamos a ver el navegador en el inventario: controlamos páginas públicas. Estas comprobaciones no exigieron al usuario iniciar sesión, comprar ni subir archivos.

No conservamos un inventario de las pestañas privadas existentes de Chrome como prueba para el artículo. Bastó una pestaña nueva de prueba para confirmar la recuperación. Investigar el navegador no exige recopilar correos abiertos ni sitios internos de una empresa.

También comprobamos el estado guardado. Los elementos seleccionados, incluidos 2 chats fijados, 18 proyectos fijados y 63 proyectos locales, coincidían con la copia. La comprobación del estado de inicio de sesión de la CLI también terminó correctamente. No hizo falta reconstruir el historial ni volver a iniciar sesión.

Reiniciar la aplicación no equivale a reiniciar el PC. Comprobamos lo primero, pero dejamos las comprobaciones tras reiniciar el PC y futuras actualizaciones para un momento adecuado para el usuario. Estos resultados abarcan la recuperación inmediata y el inicio normal de la aplicación.

Qué evitar al principio

Borrar datos de la aplicación o perfiles del navegador antes de distinguir un problema de conexión de uno del sitio o de la ubicación de almacenamiento puede hacer perder sesiones, ajustes y pruebas de comparación. En este caso no borramos todos los datos del navegador ni reinstalamos la aplicación para recuperarlo.

Restaurar antiguas skills del navegador tampoco fue la solución estándar. En el equipo investigado, su ausencia formaba parte del cambio a Computer Use unificado. Que falte un archivo antiguo no basta para identificarlo como causa de un fallo.

No utilizamos ajustes internos no documentados, parches del código de la aplicación ni sustituciones de ejecutables. Cambiar de versión podría parecer una recuperación, pero dejaría de ser una comparación anterior y posterior con la misma versión, como en este caso.

Tampoco fue necesario relajar progresivamente la seguridad cuando los permisos necesarios del navegador integrado y de Chrome ya estaban habilitados. Tener permiso para controlar un sitio es distinto de confiar en su contenido. Elige una página de prueba sin información sensible ni acciones de consecuencias importantes.

Información que conviene conservar si sigue fallando

Para soporte o investigación, registrar hasta dónde llega cada operación es más útil que un «no funciona» genérico. Aquí la diferencia importante fue que las páginas se mostraban, pero no se podían obtener los destinos de control; después de la recuperación también funcionaban los enlaces.

• La versión y si se utiliza la aplicación de escritorio, la CLI o el IDE.
• Si el síntoma afecta al navegador integrado, a Chrome o a ambos.
• Si puedes abrir manualmente la página, si Codex puede leerla y si puede hacer clic.
• Si afecta a un solo sitio o también a páginas públicas sin inicio de sesión.
• Si cerraste por completo y abriste una instancia nueva, y si utilizas otra unidad o una ubicación principal personalizada.
• La hora del fallo y el mensaje de error real. Excluye los registros sin filtrar que contengan secretos.

Al comprobar el directorio principal, distingue el valor $env:CODEX_HOME del shell, el ajuste de usuario de Windows y el valor utilizado por la aplicación en ejecución. Quien no utilice una ubicación personalizada no necesita imitar este caso apuntando a una carpeta vacía en D.

No poder abrir el historial o fallar solo al enviar no implica necesariamente un problema de control del navegador. Según el mensaje, también puedes consultar nuestro artículo Codex thread not found y comprobación del historial.

Orden de comprobación basado en este caso

Primero comprueba desde dónde utilizas Codex y qué navegador está afectado. Si queda una página de error después de recuperarse el servidor, recarga normalmente esa pestaña. Después prueba por separado la visualización, la lectura y los clics en una página pública. Si no existe conexión alguna con el navegador, guarda el trabajo y considera cerrar por completo y reiniciar la aplicación. En equipos con un directorio principal trasladado, también puede servir comprobar la ubicación referenciada.

En este equipo funcionó combinar la ruta real del directorio principal ya existente en D con un inicio tras cerrar la aplicación por completo. Podemos afirmar que hubo recuperación, pero no que la unión fuera la única causa. Comprobar cambios reversibles de uno en uno resulta más práctico que tratar los traslados o el borrado de datos como soluciones universales.

Preguntas frecuentes

Si veo la página, ¿puede Codex controlarla?

En este equipo la página se veía, pero no podía obtenerse como destino de control. Comprueba también la lectura del contenido y los clics en enlaces.

¿Instalar la extensión de Chrome repara el navegador integrado?

El navegador integrado y Chrome utilizan vías independientes. Comprueba cuál falla. En este caso también probamos cada uno por separado.

¿Configurar CODEX_HOME siempre lo soluciona?

No lo demostramos. Aquí especificamos la ruta real y cerramos y reiniciamos por completo la aplicación al mismo tiempo; después se recuperó. Eso no justifica recomendar primero trasladar el directorio principal en equipos cuya ubicación de almacenamiento no ha cambiado.

¿Tengo que mover la aplicación a D para recuperarlo?

El navegador se recuperó antes de mover la propia aplicación. Trasladar una aplicación de Windows es una operación independiente de reparar el control del navegador.