Token exchange failed: token endpoint returned status 403 Forbidden confirma que se rechazó una petición de autenticación, pero no demuestra por sí solo una caída de OpenAI, un proxy defectuoso, una restricción regional o credenciales antiguas. Primero separa la devolución a localhost, el intercambio saliente del código por tokens y la primera petición autenticada. Antes de restablecer nada, guarda codex --version, ejecuta codex login status, anota dónde se ejecuta realmente Codex y conserva el cuerpo de la respuesta sin secretos. Mientras no conozcas el punto de rechazo, no borres ~/.codex, no desactives TLS, no eludas una restricción regional y no compartas la URL de callback ni tokens.
| Lo que ocurrió | Paso que falló | Primera comprobación útil |
|---|---|---|
| El navegador no volvió a Codex | callback localhost | ¿El navegador puede alcanzar al proceso que escucha? |
| El navegador autorizó y después apareció el 403 exacto | intercambio saliente | Cuerpo, proxy/WAF, CA, región/cuenta y entorno de ejecución |
| El inicio terminó y la primera operación devolvió 403 | petición autenticada | Permisos del espacio, modelo, proveedor y origen de credenciales |
Un fallo de callback no es un rechazo del token endpoint. Un 403 posterior de API tampoco es un fallo de intercambio. Corrige el paso que puedas demostrar. Si el cuerpo nombra cuenta, espacio de trabajo, política o país compatible, deja de modificar el proxy.
“Comprobado el 12 de julio de 2026: OpenAI Status no mostraba un incidente general conocido. Ese estado no garantiza la ruta de una red corporativa, una cuenta, un espacio de trabajo o una región concretos.
Cinco comprobaciones antes de cambiar la configuración
1. Registra la versión y la sesión en el mismo entorno
bashcodex --version codex login status
Ejecuta ambos comandos en el mismo macOS, Windows, Linux, WSL, contenedor, host SSH o terminal del IDE donde apareció el error. La prueba actual mostró codex-cli 0.144.0-alpha.4; es una observación, no una versión mínima.
2. Comprueba el estado del servicio
Abre OpenAI Status y conserva la hora. Si hay un incidente de autenticación o Codex, espera antes de reescribir ajustes locales. Si está operativo, continúa con la ruta local.
3. Identifica el entorno que ejecuta Codex
El navegador puede estar en el portátil mientras Codex vive en WSL, un contenedor o un servidor remoto. Si el navegador no alcanza al listener, el problema es la topología del callback. Si Codex recibió el callback y luego informó del 403 del token endpoint, investiga el intercambio saliente.
4. Conserva la respuesta de forma segura
Guarda el error exacto, fecha y zona horaria, versión, comando, código breve y request ID. Elimina authorization code, access/refresh token, URL completa de callback, cookies, API key, correo, ID de organización y credenciales del proxy. Un código de política o una página corporativa de bloqueo tiene más valor diagnóstico que el número 403.
5. Haz un solo reintento controlado
Cambia una variable: versión de Codex, red autorizada, entorno correcto, CA aprobada o estado de sesión. La señal de éxito no es solo la pantalla del navegador: codex login status debe mostrar el método esperado en el mismo entorno y una operación pequeña debe funcionar.
Las cinco etapas de autenticación
El recorrido es: autorización del navegador, callback localhost, intercambio del código, almacenamiento de credenciales y primera petición autenticada. El mensaje exacto pertenece a la tercera etapa. Todavía pueden rechazarlo controles de cuenta o política de OpenAI, un proxy/WAF corporativo, inspección TLS y CA, el entorno equivocado o un contexto de sesión antiguo.
La documentación de autenticación de Codex define los métodos admitidos y el almacenamiento. La referencia de variables documenta CODEX_CA_CERTIFICATE para una CA personalizada aprobada. Es el camino seguro frente a desactivar la verificación.
Matriz de prueba, acción y parada
| Rama | Prueba | Acción acotada | Éxito | Límite |
|---|---|---|---|---|
| proxy/WAF | página corporativa o ID del proxy | pedir al responsable de red que permita la ruta; mantener loopback local | un inicio limpio en la ruta aprobada | no eludir la política de la organización |
| CA corporativa | error de cadena e inspección TLS documentada | configurar el PEM aprobado | intercambio con verificación activa | no usar TLS inseguro |
| WSL/contenedor/remoto | navegador y listener en redes distintas | iniciar donde el callback sea alcanzable o usar autenticación oficial alternativa | el mismo proceso recibe el callback | no publicar el listener |
| región/cuenta | unsupported_country_region_territory o restricción de cuenta | consultar países compatibles y contactar con soporte si es erróneo | la ruta oficial queda habilitada | no usar VPN ni cuenta ajena para eludir |
| espacio administrado | cuenta personal funciona, SSO se rechaza | pedir al administrador que confirme Codex e identity policy | acceso al espacio correcto | dejar de tocar el proxy cuando la política es explícita |
| caché de autenticación | red y política correctas; logout cambia el resultado | codex logout y un solo codex login limpio | método esperado y petición correcta | no borrar todo el directorio primero |
Proxy y certificados: loopback no es salida a Internet
Si el proxy es obligatorio, el tráfico local suele mantenerse fuera:
bashexport NO_PROXY="localhost,127.0.0.1,::1"
El token endpoint saliente puede necesitar el proxy corporativo autorizado. No añadas todos los dominios de OpenAI a NO_PROXY sin confirmación. Cuando exista inspección TLS aprobada, utiliza el PEM proporcionado por seguridad:
bashexport CODEX_CA_CERTIFICATE="/path/to/company-ca-bundle.pem" codex login
Un error de certificado y un HTTP 403 son señales distintas; aplica esta rama solo si hay evidencia de cadena o inspección.
Restablece únicamente la capa de autenticación
bashcodex logout codex login
No empieces por rm -rf ~/.codex: puede borrar configuración, estado y diagnóstico. Consulta la función de cada archivo en Codex config.toml. No copies el auth.json de otra persona ni publiques el tuyo.
El CLI comprobado el 12 de julio de 2026 ofrece --device-auth, --with-api-key y --with-access-token. Device auth puede resolver la topología navegador-localhost, pero no una política de cuenta o región. Una API key cambia a facturación y funciones de desarrollador; revisa API key frente a suscripción de Codex. Un access token solo debe entrar en automatizaciones de confianza y documentadas.
Cómo interpretar variantes concretas
Si el navegador muestra éxito y el terminal sigue esperando, probablemente el callback no llegó al proceso Codex. Comprueba si navegador y CLI están separados entre host, WSL, contenedor o SSH. La pantalla de éxito confirma el consentimiento, no la entrega al listener. Usa un entorno alcanzable o device auth oficial; no expongas el puerto local a Internet.
Si aparece el token endpoint 403 exacto, distingue un JSON con código de política de un HTML corporativo con block ID. Conserva el cuerpo redactado, request ID y hora. El mismo código de cuenta o región en varias redes autorizadas pesa más que la hipótesis de proxy.
Cuando conviven un error de certificado y un 403, ordénalos en el tiempo. Un fallo de TLS puede ocurrir antes de recibir un HTTP real. Si una CA aprobada arregla el handshake pero queda un JSON 403, la confianza ya está corregida y queda otra rama. No descargues certificados desconocidos ni desactives TLS globalmente.
Una nota reproducible debe incluir hora, OS/entorno, versión, método de autenticación, resultado del callback, estado de exchange redactado, tipo de red, un único cambio y resultado. Cambiar navegador, red, cuenta y versión a la vez elimina la causalidad. Tampoco confundas el 403 de un proveedor API compatible con el OAuth oficial de OpenAI.
Escalada y paquete de pruebas
Escala de inmediato si el cuerpo identifica política, cuenta, espacio de trabajo o región. En los demás casos, detente tras un reintento limpio con una versión actual y una ruta aprobada. Entrega error y cuerpo redactado, hora, versión, método de autenticación, sistema y entorno, resultado del callback, presencia de proxy/WAF/TLS, request ID o ID de /feedback, y el único cambio probado.
No envíes callback URL, authorization code, token, API key, cookie, auth.json completo ni URL de proxy con credenciales. Una vez reparado el acceso, los problemas de consumo pertenecen a límites de Codex, no al intercambio de autenticación.
Preguntas frecuentes
¿Por qué el navegador indica éxito y Codex falla?
La autorización del usuario y el intercambio del código son peticiones distintas. La segunda puede ser rechazada por proxy, política, cuenta o contexto antiguo.
¿Debo poner los dominios de OpenAI en NO_PROXY?
No de forma indiscriminada. Mantén localhost local, pero deja que la petición saliente siga la política de red autorizada.
¿Una API key evita el 403?
Puede ser el método correcto para desarrollo, pero cambia facturación y funciones. No evita políticas de cuenta, espacio o país compatible.
¿Cuándo debo dejar de probar localmente?
Cuando el cuerpo nombre policy/account/workspace/region o cuando un único reintento limpio por la ruta aprobada produzca la misma evidencia.