"Turn timed out after 600000ms" en el proveedor de Codex de NanoClaw significa que el WebSocket de Responses de Codex dejó de enviar eventos, y el primer error que informa Codex llega solo después de que ya se haya activado el temporizador fijo de turno de diez minutos de NanoClaw. Codex espera cinco minutos a que haya actividad en un flujo inactivo, reintenta en silencio la primera vez y solo informa del segundo reintento. Lo reproducimos el 1 de octubre de 2026 con Codex 0.138.0 —la versión del informe del error— y 0.155.1, la versión que NanoClaw fija actualmente, contra un endpoint local que acepta la conexión y después permanece en silencio.
Esto reproduce el problema de NanoClaw issue #3338, que seguía abierto sin respuesta de un mantenedor cuando se comprobó. Para consultar las opciones de proveedor, véase NanoClaw API cost and providers; si el bot permanece en silencio en Telegram por otros motivos, véase NanoClaw Telegram not responding.
Lo que ves
Un mensaje al bot no recibe respuesta —ni error ni respuesta parcial— durante diez minutos, y después aparece un error. Los mensajes enviados mientras tanto parecen desaparecer. En los registros:
# Codex, inside the agent container (from the issue; our 0.155.1 run printed the same reason)
stream error: idle timeout waiting for websocket
stream disconnected - retrying sampling request (1/5 ...)
# NanoClaw, ten minutes after the message
Error: Turn timed out after 600000msLo que mostró la reproducción
| Segundos transcurridos del turno | Codex 0.138.0 | Codex 0.155.1 (versión fijada por NanoClaw) |
|---|---|---|
| ≈1–16 | Primera solicitud enviada por WebSocket; sin respuesta | Una solicitud de calentamiento, cerrada por Codex a los 16 s; después llega la solicitud real |
| ≈300–316 | La primera solicitud agota el tiempo de espera; Codex vuelve a enviar la solicitud del turno — sin notificación | Tiempo de espera por inactividad; se registra el reintento 1 — sin notificación |
| 600 | El temporizador de NanoClaw termina el turno: "Turn timed out after 600000ms" | |
| ≈601–616 | Tiempo de espera por inactividad; se registra "retrying sampling request (1/5)" — todavía sin notificación (ninguna en 750 s) | Primera notificación error: "Reconnecting... 2/5", "idle timeout waiting for websocket" — llega 15 segundos tarde |
El endpoint era un sustituto que aceptaba el WebSocket y no enviaba nada; el cliente era el binario real del app-server de Codex, ejecutado con las mismas llamadas que hace NanoClaw y evaluado según la regla del propio NanoClaw: cualquier notificación de error o un turno completado lo termina; de lo contrario, lo hace el temporizador de diez minutos.
Por qué los tiempos coinciden tan mal
- Codex espera 300 segundos al siguiente evento en un flujo de Responses antes de darlo por muerto, y reintenta hasta cinco veces. Esos son los valores predeterminados del proveedor integrado de OpenAI en ambas versiones.
- Codex oculta el primer reintento de WebSocket. Su código de reintento lo indica en un comentario: "In release builds, hide the first websocket retry notification to reduce noisy transient reconnect messages", por lo que la interfaz no recibe nada hasta el segundo reintento, aproximadamente diez minutos después.
- NanoClaw asigna a un turno de Codex exactamente 600,000 ms y lo termina ante cualquier notificación de error. Dos ventanas de inactividad más el calentamiento de Codex duran más que eso, por lo que, con la configuración predeterminada, gana el temporizador.
Los mensajes enviados durante el silencio se pierden
NanoClaw envía un seguimiento que llega durante un turno activo al turn/steer de Codex. En la ejecución, Codex lo aceptó en el turno bloqueado y no envió nada nuevo al upstream; después del tiempo de espera, al reanudar el hilo se mostró la solicitud original en el historial, pero no el mensaje de dirección. Eso hace que el bot parezca completamente bloqueado: todo lo que escribes entra en un turno que nunca terminará.
Cómo salir del problema
Verificado: después del tiempo de espera, el siguiente mensaje reanuda el mismo hilo en un app-server nuevo —lo que hace NanoClaw— y en la ejecución se completó en 0.16 segundos una vez que el endpoint respondió. Por tanto: espera a que venza el tiempo de espera y vuelve a enviar lo que hayas escrito durante el silencio. Si el siguiente mensaje también se bloquea, la conexión upstream sigue siendo el problema: comprueba el estado de OpenAI y, si el contenedor llega a OpenAI a través de un proxy, verifica si dicho proxy permite actualizaciones de WebSocket (la solicitud de incorporación de cambios #2672 describe proxies que no lo permiten; no se probó aquí).
Opciones que acortan la espera, medidas pero no publicadas:
| Cambio | Primer error que ve NanoClaw | Consecuencia |
|---|---|---|
| Codex mediante HTTP/SSE en lugar de WebSockets — PR #3851, abierta, sin fusionar | 300 s: "Reconnecting... 1/5" | La notificación indica que Codex volverá a intentar, y así lo hizo, pero NanoClaw termina el turno al recibirla: un fallo de cinco minutos en lugar de uno de diez |
Codex stream_idle_timeout_ms = 60,000 en WebSockets | 136 s | NanoClaw escribe por sí mismo el config.toml de Codex, por lo que esto requiere un cambio de código, no una configuración que puedas añadir |
Ambos siguen terminando el turno como un fallo. Lo que indican las mediciones está del lado de NanoClaw: tratar un error que está reintentando como progreso en lugar de como final, o medir el presupuesto del turno desde el último evento real; pero esto es una inferencia basada en estas ejecuciones, no una solución confirmada por los mantenedores.
Preguntas frecuentes
¿Por qué el agente Codex de NanoClaw queda en silencio durante diez minutos y luego agota el tiempo de espera?
Porque la primera señal de problemas que Codex está dispuesto a notificar llega después de que NanoClaw ya se haya rendido. Cuando Responses WebSocket deja de enviar eventos, Codex espera 300 segundos de inactividad y reintenta; en las compilaciones de lanzamiento oculta deliberadamente el primer reintento de WebSocket. La primera notificación de error llega después de una segunda ventana de 300 segundos, más allá del temporizador fijo de turno de 600,000 ms de NanoClaw. Lo reprodujimos el 1 de octubre de 2026: Codex 0.138.0 no envió ninguna notificación durante 750 segundos, y 0.155.1 —la versión fijada actualmente por NanoClaw— envió la primera a los 615.7 segundos; la regla de NanoClaw terminó el turno a los 600.
¿Qué ocurre con los mensajes que envío mientras el bot está bloqueado?
Se redirigen al turno bloqueado y, en nuestra ejecución, se pierden. NanoClaw dirige a turn/steer de Codex cualquier seguimiento que llega durante un turno activo; Codex lo aceptó en el mismo turno bloqueado, no envió nada nuevo al servidor y, después del tiempo de espera y una reanudación, el texto dirigido no aparecía en el historial del hilo. Vuelve a enviar todo lo que escribiste durante el silencio cuando el bot responda de nuevo.
¿Cómo me recupero de un tiempo de espera agotado en un turno de Codex de NanoClaw?
Envía el siguiente mensaje. NanoClaw inicia un app-server nuevo y reanuda el mismo hilo; en nuestra ejecución, ese turno reanudado terminó en 0.16 segundos una vez que el endpoint respondió, con el prompt original todavía en el historial. Si el servidor ascendente sigue bloqueándose, el nuevo turno se bloqueará de la misma manera, así que comprueba primero el estado de OpenAI o tu ruta de red; y vuelve a enviar los seguimientos que se hayan perdido.
¿Cambiar Codex a HTTP en lugar de WebSockets lo soluciona?
Acorta el silencio, pero no está fusionado. La solicitud de incorporación de cambios #3851 (abierta, de quien informó del problema) añade NANOCLAW_CODEX_TRANSPORT=http, que dirige Codex a través de HTTP/SSE. En nuestra ejecución con esa configuración, la primera notificación de error llegó a los 300 segundos en lugar de después de que venciera el temporizador, pero incluía willRetry true mientras Codex ya estaba reenviando, y NanoClaw termina un turno ante cualquier notificación de error, por lo que el turno fallaría a los cinco minutos en lugar de recuperarse.
¿Se trata de un tiempo de espera general de Codex?
No. Codex sigue reintentando por sí mismo; el silencio de diez minutos se debe a cómo el temporizador de turno de NanoClaw coincide con el primer reintento oculto de Codex. En 0.155.1, el app-server informó "Reconnecting... 2/5" aproximadamente a los 616 segundos; un cliente con un presupuesto de turno más largo lo vería, pero NanoClaw nunca lo hace. El proveedor predeterminado de NanoClaw es Claude Agent SDK, que no interviene.
Reproducido el 1 de octubre de 2026 con los binarios nativos del app-server de codex de npm (@openai/codex 0.138.0 y 0.155.1, darwin-arm64), ejecutados mediante stdio con los parámetros initialize, thread/start, turn/start y turn/steer de la rama de proveedores de NanoClaw (commit 3959d1f055), contra un sustituto local de Responses mediante WebSocket y HTTP/SSE. Los valores predeterminados de Codex y el primer reintento oculto se obtuvieron de codex-rs en las etiquetas rust-v0.138.0 y rust-v0.155.1. No se ejecutaron: el orquestador y el contenedor de NanoClaw, OneCLI, Telegram ni el endpoint real de OpenAI; el sustituto reproduce un flujo silencioso, no aquello que hizo que OpenAI dejara de responder. El estado del issue y de la pull request se consultó ese mismo día.