Codex se queda en Reconnecting: cómo recuperar la tarea sin borrar sesiones

Reconnecting significa que Codex intenta recuperar una conexión interrumpida. No significa automáticamente que el proxy esté mal, que la cuenta haya caducado ni que el modelo esté caído. El mismo estado visible puede aparecer por una tarea guardada, una versión del cliente, la autenticación, la ruta de red o una interrupción temporal del servicio.

Por eso no conviene empezar borrando ~/.codex, todas las sesiones o las credenciales. Los cambios del repositorio suelen seguir en el disco, pero la tarea incompleta conserva la última instrucción, las aprobaciones, la salida de herramientas y el último paso confirmado: justo la evidencia que permite reanudar sin repetir operaciones.

Si Codex muestra Reconnecting 1/5 hasta 5/5 y termina con:

stream disconnected before completion

copia la última instrucción, apunta los archivos afectados y anota qué acción llegó a completarse. No reenvíes de inmediato una orden que publique, borre o envíe algo fuera del equipo. La operación puede haber terminado aunque el evento final no llegara a la interfaz.

Tres comprobaciones que no destruyen la tarea

Deja la tarea afectada intacta y realiza pruebas pequeñas:

1. Abre una tarea nueva en el mismo proyecto y pide algo de solo lectura, como identificar el directorio actual.
2. En la terminal integrada, ejecuta pwd o git status.
3. Si utilizas otro cliente de Codex, manda una petición igual de pequeña por CLI o por la extensión del IDE.

Cada resultado reduce posibilidades:

La guía oficial de OpenAI propone las mismas señales para un estado atascado: comprobar si espera una aprobación, ejecutar un comando básico y abrir un chat más pequeño y enfocado. Son pruebas de alcance, no una promesa de que exista una sola causa.

Anota la versión de cada cliente

En CLI:

codex --version
codex --help

En la aplicación de escritorio, abre About; en el IDE consulta la ficha de la extensión. “Tengo la última versión” no permite comparar nada. OpenAI explica que la app de escritorio y CLI pueden incluir versiones distintas de Codex.

Actualizar merece prioridad antes de reescribir configuración. El changelog oficial de ChatGPT y Codex registró en Codex CLI 0.148.0 la recuperación de turnos durante interrupciones temporales del proveedor. Las notas del cliente de esa fecha también corrigieron tareas que quedaban inaccesibles tras periodos de inactividad o reconexiones.

Eso demuestra que algunos bucles se corrigen en el cliente. No demuestra que una versión antigua sea la causa de todos. Tras actualizar, repite la misma petición mínima sin cambiar también red, modelo y sesión.

Distingue los errores concretos de una respuesta interrumpida

Lee el mensaje completo:

• access token could not be refreshed corresponde a la guía de renovación del token.
• HTTP 429 o un aviso de límite de uso y hora de reinicio se trata en límites de Codex.
• Un tiempo de espera agotado que mencione un comando, un servidor MCP o la configuración de la nube requiere localizar la operación afectada con la guía de tiempos de espera.
• Solo stream disconnected before completion con reconexiones sigue siendo un corte del flujo hasta que otra evidencia lo limite.

No cierres sesión por un corte genérico. Cerrar sesión cambia el estado de autenticación y dificulta saber si el origen era el token, la red o una interrupción temporal. Vuelve a autenticarte cuando el error señale la identidad, el token o el espacio de trabajo; conserva antes el mensaje original.

Comprueba la red desde el equipo que ejecuta Codex

Que el navegador abra ChatGPT solo valida la ruta del navegador. Codex Desktop, una terminal, el proceso de extensiones de VS Code, WSL, un contenedor o Remote SSH pueden usar DNS, certificados, proxy y firewall diferentes.

Identifica dónde se ejecuta el proceso. Mantén constantes la cuenta, el proyecto, la versión y el tamaño de la petición. Cambia una condición permitida:

• compara la red corporativa con otra ruta autorizada;
• compara VPN activada/desactivada si la política lo permite;
• si necesitas proxy local, verifica que el proceso escucha en el puerto accesible desde el equipo que ejecuta Codex;
• si falla dentro de WSL, contenedor o Remote SSH, prueba desde allí.

Registra hora, último estado y error exacto antes y después. Si otra red funciona, la ruta original participa en el problema. Una sola recuperación aún no distingue DNS, inspección TLS, WebSocket, reglas del proxy u otro intermediario.

La red de los comandos y la conexión de la aplicación son distintas

Muchas soluciones mezclan .env, HTTP_PROXY y un supuesto interruptor de WebSocket. Hay al menos dos planos distintos:

1. la conexión del cliente Codex que transporta respuestas del modelo;
2. el acceso de red de comandos ejecutados dentro del sandbox.

La especificación oficial de permisos define un proxy para el tráfico de los comandos ejecutados en el entorno aislado. Puede proporcionar variables HTTP(S) y WebSocket a las herramientas. Que curl o un gestor de paquetes cambie de conexión no demuestra que la aplicación de escritorio utilice la misma configuración para recibir las respuestas del modelo.

Trata una clave no documentada de config.toml como experimento, no como solución permanente. Conserva el valor anterior, modifica una sola entrada y prepara la restauración del valor anterior. Si has configurado otro proveedor de modelos, consulta sus requisitos de conexión y los de la versión instalada.

Reinicia solo el alcance que falló

Si falla una tarea antigua, consérvala. Lleva a una tarea nueva el objetivo, pasos terminados, archivos implicados e incertidumbre restante. Pide que inspeccione git status antes de editar.

Si falla un cliente, espera a que terminen las demás tareas activas y cierra por completo la aplicación o el IDE que la aloja. Cerrar la ventana puede dejar un proceso en segundo plano. La guía oficial recomienda reiniciar después de que finalicen los chats activos.

Si fallan todos los clientes, consulta OpenAI Status, guarda la hora local y realiza una comparación de red. Reinstalar varias veces no aporta evidencia mientras el alcance siga siendo amplio.

Cuando se recupere la conexión, revisa git status y cualquier sistema externo antes de repetir. Una herramienta o escritura puede haber concluido aunque no recibieras el mensaje final.

Conserva los historiales y los registros para el diagnóstico

OpenAI documenta estas ubicaciones:

• registros de la aplicación en macOS: ~/Library/Logs/com.openai.codex/YYYY/MM/DD;
• historiales de sesiones activas: $CODEX_HOME/sessions, normalmente ~/.codex/sessions;
• historiales de sesiones archivadas: $CODEX_HOME/archived_sessions.

Pueden contener instrucciones, rutas, nombres de repositorios y resultados de herramientas. Revisa el fragmento que vayas a compartir y oculta los datos privados; no subas todo el directorio. Si no puedes identificar con seguridad el archivo de la tarea, usa /feedback desde la tarea afectada.

Si una tarea antigua falla de forma persistente y las nuevas funcionan en el mismo proyecto, conserva ese contraste para soporte. Antes de mover un archivo de sesión, confirma cuál corresponde a la tarea y qué procedimiento admite tu versión; guarda una copia recuperable. Eliminar todas las sesiones de una fecha no permite aislar el problema.

Si el problema persiste tras comparar versión, una red y un reinicio completo, prepara para /feedback: cliente y versión, sistema y equipo donde se ejecuta, hora y zona horaria, secuencia de Reconnecting, resultado de una tarea nueva, otro cliente, el comando básico y la prueba de red, más el fragmento mínimo del registro con los datos privados ocultos.

Localizar el fallo permite elegir el siguiente paso, pero la recuperación solo queda comprobada cuando una petición nueva termina correctamente en el entorno afectado y los archivos conservan el estado esperado. Si todavía falla, entrega a soporte el contraste entre clientes, tareas y redes que hayas obtenido.