Un mensaje de tiempo de espera agotado no demuestra por sí solo que OpenAI esté caído, que falten créditos o que la red sea el problema. Codex puede detenerse antes de conectar, durante la inicialización de la aplicación o extensión, al arrancar un servidor MCP, dentro de una herramienta, esperando que termine un proceso hijo o cuando un turno largo deja de mostrar avances. La pausa se parece; el responsable cambia.
Conserva primero lo que ya existe. No abras varias copias de la misma tarea ni cambies a la vez cuenta, modelo, red, proveedor, herramientas y configuración. Revisa los cambios del repositorio y los procesos activos. Anota el error exacto, fecha, hora y zona horaria, superficie y versión de Codex, última acción completada e ID de request o sesión si aparece. Antes de compartirlo, elimina tokens, correos, prompts privados, código y los identificadores completos del proyecto.
La pregunta decisiva es: ¿qué finalización estaba esperando Codex cuando venció el tiempo?
Usa el último progreso confirmado
| Último estado visible | Frontera que conviene revisar | Primera prueba acotada |
|---|---|---|
| La app, CLI o extensión nunca quedó lista | Inicialización, autenticación o conexión | Un arranque limpio con la misma cuenta y proyecto |
| Connecting o reconexiones del stream | Red del host, proxy/VPN, host remoto o ruta de servicio | Una reproducción en la misma ruta, sin duplicados |
| Falló el arranque de un MCP | Proceso local, entorno o URL remota | codex mcp list y comprobar solo ese servidor |
| Una herramienta MCP agotó el tiempo | Herramienta, servicio downstream o tamaño de entrada | La operación mínima de solo lectura en el mismo tool |
| Un comando no termina | Watcher, stdin, proceso hijo o cleanup | Ejecutarlo directamente en el mismo directorio y entorno |
| El turno sigue activo pero no avanza | Request del modelo, bucle de herramientas, approval, contexto o UI | Estado de sesión y última acción antes de reanudar |
| El error contiene HTTP 429 | Límite de cuenta, proyecto, workspace o proveedor | Ir al diagnóstico de Codex 429 |
Que una página abra en el navegador no prueba que un comando dentro del sandbox, el host de una extensión, un contenedor, WSL, una máquina Remote SSH o un proceso MCP pueda alcanzar el mismo destino. La documentación oficial de sandboxing separa las approvals de los recursos de archivos y red accesibles para los comandos. No ver un cuadro de aprobación y disponer de una ruta de red son hechos distintos.
Registra un estado breve antes de tocar nada
El registro útil cabe en pocos puntos:
- app de escritorio, CLI, IDE, cloud o remote;
- versión del cliente, sistema operativo y host real de ejecución;
- ChatGPT sign-in, API key directa o proveedor personalizado, sin incluir el secreto;
- error exacto, timestamp e ID de request/sesión;
- último servidor MCP, tool o comando shell;
- archivos modificados y procesos en segundo plano;
- un dato de configuración relacionado, no todo el archivo.
La referencia oficial de comandos para desarrolladores asigna preguntas diferentes a cada herramienta. /status muestra configuración de sesión y uso de token/context; /debug-config enseña las capas efectivas de configuración y las fuentes de políticas; codex login status informa del modo de autenticación activo. Ninguno es, por sí solo, una prueba de red o de un endpoint MCP. Si tu versión no ofrece un comando, consulta codex --help en lugar de forzar instrucciones de otra versión.
MCP separa el arranque de la ejecución de herramientas
Una configuración de MCP en el host de Codex puede definir dos esperas:
toml[mcp_servers.example] command = "example-mcp" startup_timeout_sec = 20 tool_timeout_sec = 90
La guía oficial de MCP documenta un valor predeterminado de 10 segundos para startup_timeout_sec y de 60 segundos para tool_timeout_sec. El primero cubre la inicialización del servidor; el segundo, una ejecución de herramienta.
Si falla el arranque, verifica executable, variables de entorno, entrada interactiva, URL remota y autenticación. Si falla un único tool call, reduce su entrada y consulta logs del servidor, servicio downstream y request ID. Solo tiene sentido aumentar un timeout cuando la misma operación termina correctamente pero supera de forma estable la frontera actual por poco. No arregla una ruta inaccesible, credenciales incorrectas, un crash o un deadlock.
Un MCP STDIO local y uno HTTP remoto dejan evidencias distintas. Además, app de escritorio, CLI y extensión IDE pueden compartir configuración MCP en el mismo Codex host sin compartir necesariamente el process environment ni el host remoto. Registra dónde se ejecuta realmente el servidor.
Un proceso hijo puede seguir vivo con la conexión sana
Un servidor de desarrollo, un test watcher o un script que espera stdin quizá no deba terminar. A veces el trabajo principal acaba, pero un handle abierto o la limpieza mantiene vivo el proceso. Eso no demuestra un fallo de conexión de Codex.
Ejecuta el comando directamente en el mismo working directory y entorno, y comprueba:
- si emite nuevas líneas o ya publicó una dirección de escucha;
- si está diseñado para terminar solo;
- si espera una entrada interactiva que la ejecución de Codex no puede proporcionar.
Gestiona un servicio persistente como proceso de fondo deliberado y usa una prueba de readiness separada. Si el comando debería finalizar, investiga su propio log, árbol de procesos y exit behavior. Aumentar el tiempo general de Codex solo oculta esa diferencia.
Reanuda sin repetir a ciegas
Cuando la sesión sigue guardada, resume conserva mejor el contexto que una copia. La documentación oficial incluye codex resume para sesiones interactivas y codex exec resume para ejecuciones no interactivas compatibles. Recuperar la conversación no garantiza que repetir una escritura externa sea idempotente. Comprueba primero Git, jobs cloud y servicios remotos por si hubo finalización parcial.
Mantén cuenta, ruta, modelo y proyecto constantes. Cambia solo la condición respaldada por la evidencia y ejecuta una acción pequeña, de solo lectura o fácilmente reversible. Compara el nuevo último avance con el registro original. Si funciona, amplía de forma gradual. Si se detiene en la misma etapa, ya tienes una reproducción mínima y un ID de request, sesión, servidor o proceso que puede usar soporte.
Si la evidencia señala permisos, precedencia de configuración o red de comandos, sigue la guía de sandbox y config.toml. Si señala 429, créditos o una ventana de uso, mantén el diagnóstico en la ruta de límites. La solución duradera no es esperar más: es identificar qué espera terminó y probar únicamente a su responsable.
