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:
textstream disconnected before completion
copia el último prompt, 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:
- Abre una tarea nueva en el mismo proyecto y pide algo de solo lectura, como identificar el directorio actual.
- En la terminal integrada, ejecuta
pwdogit status. - Si tienes otra superficie de Codex, manda una petición igual de pequeña por CLI o por la extensión del IDE.
Cada resultado reduce posibilidades:
| Resultado | Frontera más probable | Próximo paso seguro |
|---|---|---|
| La tarea nueva funciona y la antigua reconecta | Estado de esa tarea o su stream | Continuar con un handoff breve en la tarea nueva; conservar la antigua |
| CLI funciona y Desktop falla | Build de Desktop, proceso host o su ruta | Comparar versiones y cerrar Desktop por completo |
| La terminal funciona, pero fallan varias superficies de Codex | El comando local no es el bloqueo principal | Revisar auth, versión, servicio y una variable de red |
También se bloquea git status | Repositorio, filesystem, shell o proceso local | Resolver primero la ejecución local |
| Fallan varias superficies en dos redes autorizadas | Aumenta la posibilidad de cuenta, servicio o fallo amplio del cliente | Dejar de cambiar datos y preparar diagnóstico |
La guía oficial de OpenAI propone las mismas señales para un estado atascado: comprobar si espera una approval, 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 una versión para cada superficie
En CLI:
bashcodex --version codex --help
En Desktop usa 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 provider. Las notas del cliente de esa fecha también corrigieron tareas que quedaban inaccesibles tras idle o reconnecting.
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.
Separa los errores explícitos del corte de stream
Lee el mensaje completo:
access token could not be refreshedcorresponde a la guía de renovación del token.- HTTP 429, usage limit o reset time corresponde a límites de Codex.
- Un timeout que nombra command, MCP server o cloud config bundle necesita identificar la espera con la guía de timeout.
- Solo
stream disconnected before completioncon reconexiones sigue siendo un corte del flujo hasta que otra evidencia lo limite.
No cierres sesión por un corte genérico. Logout altera el estado de autenticación y dificulta saber si el origen era token, red o una interrupción temporal. Reautentica cuando el error nombre identity, token o workspace, guardando antes el texto original.
Prueba la red en el host donde corre Codex
Que el navegador abra ChatGPT solo valida la ruta del navegador. Codex Desktop, una terminal, el extension host de VS Code, WSL, un contenedor o Remote SSH pueden usar DNS, certificados, proxy y firewall diferentes.
Identifica el host real del proceso. Mantén constantes account, proyecto, versión y 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 que recibe el host de 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.
El proxy del sandbox no es el stream de la app
Muchas soluciones mezclan .env, HTTP_PROXY y un supuesto interruptor de WebSocket. Hay al menos dos planos distintos:
- la conexión del cliente Codex que transporta respuestas del modelo;
- el acceso de red de comandos ejecutados dentro del sandbox.
La especificación oficial de permissions define el network proxy del perfil para sandboxed command traffic. Puede entregar variables HTTP(S) y WebSocket a las herramientas. Que curl o un package manager cambie de ruta no demuestra que el stream propio de Desktop use esa misma configuración.
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 el rollback. Para un custom model provider, sigue la documentación de transporte de ese provider y 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 app o el IDE host. 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 todas las superficies, 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 reconnect funciona, revisa git status y cualquier sistema externo antes de repetir. Una herramienta o escritura puede haber concluido aunque no recibieras el mensaje final.
No borres transcripts como primer arreglo
OpenAI documenta estas ubicaciones:
- logs de la app en macOS:
~/Library/Logs/com.openai.codex/YYYY/MM/DD; - transcripts activos:
$CODEX_HOME/sessions, normalmente~/.codex/sessions; - transcripts archivados:
$CODEX_HOME/archived_sessions.
Pueden contener prompts, rutas, nombres de repositorios y tool output. Revisa y redacta antes de compartir; no subas todo el directorio. Si no puedes identificar con seguridad el archivo de la tarea, usa /feedback desde la tarea afectada.
Solo cuando una tarea antigua falla de forma estable y las nuevas funcionan en el mismo proyecto tiene sentido aislar su transcript. Haz primero una copia recuperable, mueve únicamente el archivo exacto fuera del directorio activo y repite la prueba mínima. Eliminar por fecha todas las sesiones no es un diagnóstico.
Si el problema persiste tras comparar versión, una red y un reinicio completo, prepara para /feedback: superficie y versión, sistema y host real, hora y zona horaria, secuencia de Reconnecting, resultado de una tarea nueva, otra superficie, el comando básico y la prueba de red, más el fragmento mínimo del log ya redactado.
La recuperación está verificada cuando puedes nombrar el alcance: una tarea guardada, un cliente, una ruta de red o todas las superficies. Esa conclusión se puede volver a probar; borrar todo el estado de Codex al azar, no.
