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ón | Qué identifica localhost | Primera comprobación |
|---|---|---|
| Navegador de tu equipo | Pila de red local | Que el servidor escucha en el puerto previsto |
| Navegador o comando en VM alojada | Loopback de la VM | Que exista un servicio en ese entorno |
| Navegador o comando en contenedor | Espacio de red del contenedor en la configuración aislada habitual | Si el servicio está dentro o fuera |
| Navegador que usa una vista previa HTTPS | El destino real es el dominio de la vista previa | Acceso, 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.

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 solicitante | Servicio que escucha allí | Resultado |
|---|---|---|
| Mac anfitrión | Servicio anfitrión | host-loopback |
| Invitado Alpine | Ninguno | Connection refused |
| Invitado Alpine | Servicio invitado | guest-loopback |
| Mac tras iniciar el servicio invitado | Servicio anfitrión | host-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/probeEn 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
| Necesidad | Primera opción | Qué comprobar |
|---|---|---|
| Inspeccionar el servidor de tu equipo | Navegador autorizado en ese equipo | Puerto y compilación local correctos |
| Ejecutar pruebas dentro de una tarea alojada | Arrancar el servicio allí | Cliente y servicio en la red prevista |
| Revisar una copia de prueba desde la nube | Vista previa HTTPS autorizada | Acceso y compilación esperada |
| Acceder a un servicio de prueba privado | Ruta privada aprobada por la organización | Identidad, 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.