TabbitBlog

Por qué Codex Cloud no abre el localhost de tu equipo

Identifica desde dónde sale la petición, reproduce el límite de red y elige un navegador local o una vista previa autorizada.

En este artículo
  1. Puntos clave
  2. Traza la petición antes de cambiar el servidor
  3. Dos respuestas para la misma dirección
  4. Decide dónde ejecutar la aplicación y el navegador
  5. Investiga donde apareció el error

Localhost apunta al entorno que envía la petición. Si Codex Cloud realiza la petición desde su entorno alojado, http://localhost:3000 apunta a ese entorno. La solicitud no llega al servidor enlazado al loopback de tu ordenador.

Un usuario de Reddit contó que la vista previa abría repetidamente un puerto que su proyecto no usaba. Anota el destino real antes de cambiar la red.

Primero averigua dónde se ejecuta el navegador o comando. Después elige un navegador local, arranca la aplicación dentro del entorno alojado o usa una vista previa a la que pueda acceder. La comparación entre Tabbit y Codex explica sus funciones. El límite de red depende de dónde se ejecuta el navegador.

Puntos clave

  • El puerto identifica un servicio dentro del entorno que posee esa dirección.

  • Un terminal alojado y un navegador local pueden recibir respuestas distintas de la misma URL.

  • Cambiar la dirección de escucha no crea una ruta a tu equipo.

  • Comprueba la vista previa desde el entorno que vaya a usarla.

  • Incluso con un 200, verifica una marca exclusiva de la instancia.

Traza la petición antes de cambiar el servidor

Origen de la peticiónQué identifica localhostPrimera comprobación
Navegador de tu equipoPila de red localQue el servidor escucha en el puerto previsto
Navegador o comando en VM alojadaLoopback de la VMQue exista un servicio en ese entorno
Navegador o comando en contenedorEspacio de red del contenedor en la configuración aislada habitualSi el servicio está dentro o fuera
Navegador que usa una vista previa HTTPSEl destino real es el dominio de la vista previaAcceso, compilación y resultado

IANA clasifica 127.0.0.0/8 como loopback. OpenAI documenta que Codex Cloud usa entornos alojados con políticas propias de Internet y red privada. El entorno alojado no hereda el acceso a la red local de tu equipo. Registro de IANA, entornos de OpenAI, administración del espacio de trabajo.

Diagrama con una dirección de loopback local, otra alojada y una ruta HTTPS de vista previa independiente

Pregunta qué proceso hizo la petición. Si la herramienta remota ordena a un navegador autorizado de tu ordenador abrir una página, la petición sale del navegador local. Si inicia un navegador en una VM alojada, la petición sale de allí. Consulta la guía de navegadores virtuales y la introducción a los agentes de navegador.

Dos respuestas para la misma dirección

La prueba local utilizó un Mac anfitrión y un invitado Alpine Linux en Apple Virtualization. El servidor Node del anfitrión escuchaba en 127.0.0.1:61616 y devolvía host-loopback. Desde el invitado, la conexión a la misma dirección se rechazó. Tras iniciar allí otro servicio en el mismo puerto, el invitado recibió guest-loopback. El Mac siguió recibiendo su valor.

Entorno solicitanteServicio que escucha allíResultado
Mac anfitriónServicio anfitriónhost-loopback
Invitado AlpineNingunoConnection refused
Invitado AlpineServicio invitadoguest-loopback
Mac tras iniciar el servicio invitadoServicio anfitriónhost-loopback
Registro de terminal con respuestas distintas del Mac y Alpine para la misma dirección de loopback

Era una pila de red separada y real en el mismo Mac. La VM no tenía adaptador externo. La prueba demuestra el aislamiento del loopback. No se ejecutó una tarea de Codex Cloud ni se probó una vista previa real.

Puedes repetirlo con una VM o un contenedor aislado. Usa un puerto libre. Ejecuta Node en el anfitrión y déjalo activo, ejecuta curl en otra terminal y repite la petición en el invitado con la misma URL.

node -e "require('node:http').createServer((_, res) => res.end('host-loopback\n')).listen(61616, '127.0.0.1')"
curl --noproxy '*' -fsS http://127.0.0.1:61616/probe

En el invitado, inicia el mismo comando con el texto de respuesta guest-loopback y compara. Ciertas configuraciones de red de anfitrión pueden compartir el espacio de red. Para la prueba usa el modo aislado. host.docker.internal es una ruta específica de Docker Desktop. Consulta la documentación de Docker.

Decide dónde ejecutar la aplicación y el navegador

NecesidadPrimera opciónQué comprobar
Inspeccionar el servidor de tu equipoNavegador autorizado en ese equipoPuerto y compilación local correctos
Ejecutar pruebas dentro de una tarea alojadaArrancar el servicio allíCliente y servicio en la red prevista
Revisar una copia de prueba desde la nubeVista previa HTTPS autorizadaAcceso y compilación esperada
Acceder a un servicio de prueba privadoRuta privada aprobada por la organizaciónIdentidad, ruta, dominio y permisos

Para revisar una interfaz local, deja el navegador y el servidor en el mismo equipo. La guía de navegador de escritorio de OpenAI explica cómo abrir una aplicación local. Tabbit Browser puede abrir una página de prueba en el mismo equipo y trabajar con ella según el permiso concedido. Consulta cómo funciona Tabbit. En una prueba separada, Tabbit Tango abrió una URL de prueba en Tabbit Browser y leyó el marcador local esperado.

Para una vista previa alojada, usa una copia de prueba y limita quién puede acceder. Verifica por separado la conectividad, la autenticación y la política de red. Una respuesta 200 solo confirma que respondió algún servicio. Busca la compilación o el estado previsto.

Investiga donde apareció el error

“Connection refused” suele indicar que el destino no tiene un servicio escuchando desde el punto de vista del cliente. Un timeout, bloqueo de política, inicio de sesión o error de certificado exige otra comprobación. Guarda qué herramienta hizo la petición, el destino sin secretos, el error y la instancia esperada. La guía de depuración distingue el documento de una solicitud posterior fallida.

Un desarrollador que usaba entornos de Python locales preguntó qué partes de Codex se ejecutaban en su equipo y cuáles en la nube. En este diagnóstico, distingue comando, navegador y servidor.

Pide al agente la URL seleccionada y una marca no sensible. Si solo compruebas el renderizado, empieza en modo de lectura. Consulta la lista para una primera tarea, la guía de automatización y la guía de seguridad. Elige la ruta mínima y verifica que la respuesta procede de la copia prevista.

Preguntas frecuentes

¿Codex Cloud puede abrir el localhost de mi ordenador?

Una petición a localhost desde la nube se queda en el entorno alojado. Usa un navegador autorizado en tu equipo, ejecuta la aplicación en el mismo entorno remoto o proporciona una vista previa autorizada.

¿De quién es localhost cuando Codex abre un navegador?

Pertenece al proceso que envía la petición. Un navegador de tu equipo usa el loopback de tu equipo. Un navegador o comando alojado usa el de su propio entorno.

¿Escuchar en 0.0.0.0 permite el acceso desde Codex Cloud?

Permite escuchar en más interfaces del mismo entorno. No crea una ruta desde la nube ni concede permisos.

¿host.docker.internal apunta a mi equipo desde Codex Cloud?

Es un nombre documentado para el acceso de un contenedor de Docker Desktop a su anfitrión. No es una ruta general desde Codex Cloud hacia tu equipo.

¿Cuándo uso una vista previa remota?

Cuando un navegador o comando remoto necesita revisar una copia desplegada de prueba. Comprueba desde ese entorno el acceso y la marca de la compilación.

¿Cómo sé si llegué al servidor correcto?

Compara la URL final, la respuesta y un identificador de la instancia o compilación. Un 200 puede venir de otro servicio en el mismo puerto.

Da el siguiente paso

Deja que Tabbit trabaje junto a ti.

Investiga entre pestañas, automatiza el trabajo repetitivo del navegador y mantén todo el contexto al alcance.