El mensaje error loading configuration: timed out waiting for cloud config bundle after 15s aparece durante el arranque de Codex, antes de que una petición normal llegue al modelo. El cliente intentaba aplicar requisitos administrados del workspace y no logró completar esa etapa dentro del tiempo observado.
La frase identifica una frontera, no una causa. Por sí sola no demuestra una incidencia general de OpenAI, un bloqueo de proxy, VPN o firewall, una sesión caducada, un workspace equivocado, una caché dañada ni un defecto del cliente. Borrar datos o reinstalar de inmediato elimina precisamente el estado que permite distinguir esas posibilidades.
Qué esperaba Codex durante esos 15 segundos
La documentación de OpenAI sobre configuración administrada explica que los clientes locales compatibles pueden recibir requisitos de la organización mediante un cloud config bundle. Se aplica a ChatGPT desktop, Codex CLI y la extensión del IDE, aunque las funciones disponibles pueden variar según el cliente y la versión.
Al arrancar, el cliente comprueba primero si existe una caché firmada, válida y asociada a la identidad actual. Si no puede usarla, solicita el bundle con reintentos y guarda el resultado después de validarlo. Si la petición falla o vence y tampoco hay caché válida, el cliente devuelve un error en lugar de iniciar ignorando las reglas del workspace.
De ese comportamiento se desprenden tres límites útiles:
- el timeout corresponde a la carga de configuración antes de la sesión, no a una respuesta lenta del modelo;
- una caché de otra identidad, o una que ya no sea válida, no funciona como sustituto;
- borrar la caché “por si acaso” puede quitar la única copia válida que permitiría arrancar ante un problema temporal de red.
El config.toml local pertenece a otro plano. La precedencia de configuración combina overrides de CLI, proyecto de confianza, perfil, usuario y sistema. Los requisitos administrados imponen límites del workspace; no son simplemente otro valor local que se pueda reemplazar. Editar TOML no prueba que el proceso alcance el servicio que entrega el bundle.
Guarda una línea base antes de cambiar nada
Registra estos datos:
- texto exacto del error y hora con zona horaria;
- superficie: aplicación de escritorio, CLI o extensión IDE;
- versión de Codex, sistema operativo y host donde corre el proceso;
- tipo de autenticación y account/workspace seleccionado, sin token ni correo;
- ruta real: red de oficina o doméstica, VPN, proxy, contenedor, WSL o Remote SSH;
- si comenzó en el primer arranque, tras actualizar, cambiar de workspace o volver a iniciar sesión.
Cuando la versión instalada lo admita, empieza por comandos que no borran nada:
bashcodex --version codex --help codex doctor --summary codex login status
Según la referencia oficial de comandos para desarrolladores, codex doctor resume instalación, configuración, autenticación, runtime y otros componentes. La opción --json se documenta como salida redactada. Aun así, un informe correcto no demuestra por sí solo que el bundle remoto sea alcanzable.
codex login status muestra el modo de autenticación activo; tampoco es una prueba de conectividad. Usa codex --help como verdad para la versión instalada. No ejecutes codex logout por un timeout genérico: esa orden elimina las credenciales guardadas.
Antes de compartir logs, retira tokens, cookies, correo, rutas privadas, nombres de repositorios y prompts. No es necesario enviar todo el directorio de datos de Codex ni un volcado completo del entorno.
Haz una comparación cambiando una sola condición
Mantén constantes account, workspace, proyecto y versión. Cambia una condición permitida, una sola vez, y anota la hora, duración y último punto alcanzado. El objetivo no es confirmar de inmediato una causa, sino saber qué frontera debe revisar el siguiente responsable.
| Observación | Comparación controlada | Siguiente frontera |
|---|---|---|
| OpenAI Status muestra una incidencia relacionada | No alteres datos locales; repite tras la recuperación | Servicio, recordando que el estado es agregado |
| Solo falla en la red de oficina o con VPN | Una ejecución desde otra ruta autorizada en el mismo host | Proxy, firewall, inspección TLS, DNS o egress |
| Empezó justo después de una actualización | Conserva ambas versiones y revisa una actualización compatible | Versión del cliente o empaquetado |
| Coincide con un cambio de account/workspace | Confirma la identidad seleccionada sin borrar la caché | Autenticación, asignación del workspace o política |
| Afecta a varios miembros del mismo workspace a la vez | Compara versión, región y hora sin secretos | Administrador del workspace o soporte de OpenAI |
| Solo afecta a una persona en varias rutas autorizadas | Adjunta diagnóstico y timestamps | Cuenta, workspace, cliente o ruta individual |
Que una web abra en el navegador es una señal insuficiente. El proceso de Codex puede usar otro proxy, DNS o almacén de certificados, o ejecutarse en el host de una extensión, un contenedor o una máquina remota. Compara la ruta del proceso que produce el error.
No desactives controles corporativos ni eludas las reglas de la organización. Si no está permitida una ruta alternativa, entrega la prueba al equipo de red con hora, host, cliente, versión y tipo de ruta, pero nunca con credenciales.
Qué no conviene hacer primero
No borres .codex, una carpeta de caché desconocida ni todos los datos de la aplicación. La documentación pública describe una caché validada y ligada a la identidad, pero no recomienda su eliminación manual como recuperación ordinaria. Limpiarla cambia varias condiciones a la vez y destruye evidencia.
Tampoco aumentes los temporizadores de MCP. El cloud config bundle se carga antes de una sesión normal, mientras que startup_timeout_sec y tool_timeout_sec corresponden a un servidor MCP o a una llamada de herramienta posterior. Si Codex supera la configuración y se detiene después en MCP, ese nuevo punto requiere otro diagnóstico.
No modifiques muchos valores de config.toml a la vez. Si la evidencia señala precedencia local o sandbox, continúa con la guía de config.toml. Un mensaje explícito de refresh token corresponde a la guía de renovación de acceso, y un HTTP 429 a la ruta de límites de Codex. Haber aparecido al mismo tiempo no convierte esas fronteras en una sola.
Cuándo tiene sentido volver a iniciar sesión
La reautenticación requiere una señal independiente: login status muestra un modo inesperado, el workspace seleccionado no es el correcto, aparece un error explícito de refresh token o el administrador confirma un cambio de asignación. Guarda primero el estado y el diagnóstico, prepara el método de acceso y solo entonces considera logout/login sabiendo que logout borra credenciales.
Si el único síntoma es el timeout de 15 segundos, salir de la cuenta sigue siendo una hipótesis, no una conclusión.
Qué entregar al administrador o a soporte
Prepara el error exacto, dos o tres timestamps con zona horaria, superficie, versión, sistema operativo, host real, tipo de autenticación, identificación segura de account/workspace, resultado de Status, una comparación de red autorizada y codex doctor --summary o JSON redactado si están disponibles. Añade qué cambió antes del primer caso y qué acciones ya probaste.
Una observación como “misma versión y workspace: funciona en la ruta doméstica, falla en la oficina” vale más que “lo reinstalé varias veces”. No adjuntes tokens, cookies, el entorno completo ni archivos sin revisar.
La secuencia segura es reconocer la frontera de managed configuration, conservar caché y evidencia, variar una sola condición y escalar al responsable que indique el resultado. Si el siguiente arranque supera el bundle y se detiene más tarde, registra esa etapa nueva sin trasladarle las conclusiones del timeout inicial.
