Codex token exchange failed (403 Forbidden): 5 soluciones probadas paso a paso

Inicias sesión en el navegador, la página te dice que ya puedes volver a la terminal y Codex responde Token exchange failed: es el error codex token exchange failed. Casi siempre el problema está en la única petición que Codex envía por su cuenta: no pasó por tu proxy, salió desde un país que OpenAI no admite o no llegó a conectarse. Los dos mensajes más habituales son Token exchange failed: token endpoint returned status 403 Forbidden y Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token). Aquí los separamos según el texto exacto, con los issues de GitHub del repositorio openai/codex, la documentación oficial de inicio de sesión de Codex y nuestras pruebas con codex-cli 0.165.0 en una máquina Linux.

En qué paso aparece codex token exchange failed

El inicio de sesión con ChatGPT tiene dos partes. En el navegador inicias sesión y autorizas; el navegador devuelve un código de un solo uso a Codex en el puerto local 1455. Después, el propio proceso de Codex envía ese código a https://auth.openai.com/oauth/token y recibe tus credenciales. Esa segunda petición es el intercambio de token, y codex token exchange failed significa que falló.

Que el navegador funcione no garantiza nada sobre esa segunda petición. El navegador usa su proxy o el del sistema; Codex usa las variables de entorno que ve. En nuestra máquina de prueba, codex doctor muestra respect system proxy disabled en la sección Connectivity, es decir, por defecto no lee el proxy del sistema. En el código fuente de openai/codex, la opción respect_system_proxy figura como en desarrollo y desactivada por defecto, y el intercambio de token solo reintenta con el proxy del sistema cuando falla la conexión, no cuando el servidor responde 403. Esto último es nuestra lectura del código, no algo que diga la documentación.

Los dos mensajes no significan lo mismo:

Token exchange failed: token endpoint returned status 403 Forbidden
Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token)

Con 403, la petición llegó al servidor y fue rechazada. Con «error sending request», ni siquiera llegó.

403 Forbidden: la petición salió sin tu proxy o desde un país no admitido

El issue #10466 de openai/codex trata exactamente este error. Se abrió en febrero de 2026 y sigue abierto. Casi todas las soluciones de las respuestas tienen que ver con el proxy. El usuario aweng126 lo resume en una respuesta de septiembre de 2026: el intercambio de token lo hace el proceso de Codex, que solo lee https_proxy, http_proxy y all_proxy (en mayúsculas o minúsculas) e ignora el proxy del navegador y del sistema. Si esas variables no están, la petición sale con tu IP real y vuelve un 403.

España y la mayoría de los países de América Latina están en la lista de países y territorios admitidos por OpenAI, así que si te sale este 403 conviene revisar por dónde sale tu conexión: una VPN con el nodo de salida en un país que no está en la lista, o un proxy corporativo, pueden provocarlo. Lo explicamos en el error 403 de OpenAI Country, region, or territory not supported. Nuestra máquina de prueba está en EE. UU. Un POST directo a https://auth.openai.com/oauth/token con un código no válido devolvió 401 con token_expired, no 403. Es decir, cuando la petición llega desde un país admitido, un código incorrecto da 401; un 403 apunta más bien a la IP de salida o a una política de red. Es una deducción: OpenAI no documenta cuándo este endpoint responde 403.

Para arreglar el codex token exchange failed con 403 cuando usas un proxy, define las variables en la misma terminal y luego inicia sesión:

export https_proxy=http://127.0.0.1:TU_PUERTO
export http_proxy=http://127.0.0.1:TU_PUERTO
export no_proxy=127.0.0.1,localhost,::1
codex login

No quites la línea no_proxy. El navegador tiene que llegar a localhost:1455, y si esa llamada local se manda al proxy, la devolución del código falla. En el issue #10466, UnCrownGod lo resolvió en Ubuntu con Clash Verge usando NO_PROXY=127.0.0.1,localhost,::1 y el puerto HTTP del proxy. Pon el puerto HTTP o mixto que muestre tu propia aplicación de proxy.

Con la extensión de VS Code o la app de escritorio de Codex, las variables tienen que existir antes de que arranque el programa. Exportarlas en una terminal mientras la app ya está abierta no sirve: ciérrala y ábrela desde la terminal donde las definiste. En el issue #50994, un usuario de Windows cuenta que la app de escritorio ignora el proxy, y afukuda1111 lo esquivó abriendo la app con HTTP_PROXY, HTTPS_PROXY y ALL_PROXY definidas.

Con SOCKS, escribe socks5://

Otra respuesta del issue #10466 pasa fácilmente desapercibida: chenzhaoqiJM cambió all_proxy de socks:// a socks5://127.0.0.1:7897 y el 403 desapareció. Comprobamos el motivo. Sin nada escuchando en 127.0.0.1:7897, ejecutamos codex login --device-auth con cada forma:

• all_proxy=socks5://127.0.0.1:7897 falló con error sending request for url (https://auth.openai.com/api/accounts/deviceauth/usercode): Codex estaba usando el proxy.
• all_proxy=socks://127.0.0.1:7897 funcionó y mostró un código de dispositivo. Con el puerto del proxy vacío eso no puede funcionar, así que la variable se ignoró y Codex se conectó directo.

Si tu salida directa está bloqueada, conectarse directo significa 403. Escribe socks5:// o usa el puerto HTTP del proxy.

error sending request: puertos viejos, certificados y máquinas remotas

error sending request for url (https://auth.openai.com/oauth/token) es el issue #26764, con 25 respuestas. En esta forma de codex token exchange failed, la petición ni siquiera conectó. Las causas que encontró la gente:

• Un puerto de proxy viejo. Un usuario seguía con HTTP_PROXY en 127.0.0.1:6850 cuando su app de proxy ya usaba el 7892. Otro tenía un puerto antiguo en ~/.codex/.env en macOS. Codex lee ese archivo al arrancar, así que cambiar el puerto en la app de proxy no basta.
• Un SSL_CERT_FILE incorrecto. La documentación oficial dice que Codex toma una CA personalizada de CODEX_CA_CERTIFICATE y, si no está, usa SSL_CERT_FILE. En redes de empresa que inspeccionan HTTPS, apúntalo a la CA de la empresa como indica la documentación.
• Iniciar sesión en una máquina remota. Con VS Code Remote SSH, el navegador está en tu equipo y Codex en el servidor, así que la devolución del código nunca llega. La documentación propone ssh -L 1455:localhost:1455 o el inicio de sesión con código de dispositivo.
• Una versión antigua. Un usuario de WSL lo resolvió al pasar la CLI incluida de 0.142 a 0.144.5.
• Un desafío de Cloudflare. En el issue #16052, un usuario en Australia se topó con un desafío de Cloudflare en el intercambio de token. Ahí suele ayudar más cambiar de red que tocar la configuración.

Reprodujimos el caso del puerto viejo de codex token exchange failed. Pusimos en ~/.codex/.env un puerto de proxy sin nada detrás (nuestro CODEX_HOME apunta a una carpeta de prueba) y ejecutamos codex doctor y codex login --device-auth:

codex doctor mostró HTTP_PROXY, HTTPS_PROXY leídas de .env, el handshake de WebSocket falló con Connection refused (os error 111) y la prueba de alcance marcó como inaccesible el endpoint de ChatGPT. El inicio de sesión con código de dispositivo falló con error sending request for url. Al borrar ese archivo, codex doctor mostró no proxy env vars, el endpoint respondió y el inicio de sesión mostró un código.

Revisa en este orden

• Lee el mensaje completo: ¿es 403 o «error sending request»?
• Ejecuta codex doctor y mira Connectivity: qué variables de proxy encontró y si reachability tiene ✓. Es lo que ve Codex, y cuenta más que si una web abre en tu navegador.
• Revisa ~/.codex/.env y el perfil de tu shell por si hay puertos viejos o un SSL_CERT_FILE desactualizado.
• Exporta https_proxy, http_proxy y no_proxy en una misma terminal, escribe SOCKS como socks5:// y ejecuta codex login.
• Si la devolución local falla una y otra vez, usa codex login --device-auth. La documentación lo marca como beta y antes hay que activar el inicio de sesión con código de dispositivo en la configuración de seguridad de ChatGPT. Se salta el puerto 1455, pero la petición de token la sigue enviando Codex, así que las variables de proxy siguen haciendo falta.
• Tras un fallo, lee ~/.codex/log/codex-login.log. Según la documentación, ahí van los registros del inicio de sesión.
• Confirma con codex login status.
• Como último recurso, la documentación permite iniciar sesión en una máquina donde funcione y copiar ~/.codex/auth.json a la otra. Ese archivo es tu sesión: no lo compartas ni lo subas a un repositorio.

En el issue #26764 alguien lo arregló borrando todo ~/.codex. No empezaríamos por ahí, porque guarda tu configuración y tu historial. Encontrar la causa suele significar cambiar una o dos variables.

Si no necesitas tu cuenta de ChatGPT, puedes usar codex login --with-api-key. La API tiene las mismas reglas de países, así que el proxy sigue importando. Si la clave da 401, mira cómo arreglar el error 401 Incorrect API key provided.

Preguntas frecuentes

¿codex token exchange failed significa que me bloquearon la cuenta?

Normalmente no. En los casos resueltos de los issues #10466 y #26764 se cambió el proxy, el certificado o el puerto. La cuenta no se tocó.

ChatGPT abre en mi navegador. ¿Por qué Codex sigue dando codex token exchange failed con 403?

No comparten la configuración del proxy. Por defecto Codex solo lee variables de entorno, y eso es lo que indica respect system proxy disabled en codex doctor.

¿Sigue fallando con el modo TUN activado?

El modo TUN enruta todo el tráfico del equipo, así que no depende de variables de entorno. Si con TUN sigues viendo 403, revisa si tu nodo de salida está en un país admitido por OpenAI. No probamos el modo TUN; lo deducimos de cómo funciona.

Una vez resuelto codex token exchange failed, para otros mensajes de Codex consulta la tabla de errores de OpenAI Codex. Si aún no tienes Codex instalado, empieza por cómo instalar Codex CLI e iniciar sesión.