"Turn timed out after 600000ms" sul provider Codex di NanoClaw significa che il Responses WebSocket di Codex ha smesso di inviare eventi e che il primo errore segnalato da Codex arriva solo dopo che è già scattato il timer fisso di dieci minuti del turno di NanoClaw. Codex attende cinque minuti per uno stream inattivo, riprova silenziosamente la prima volta e segnala solo il secondo tentativo. Lo abbiamo riprodotto il 1° ottobre 2026 con Codex 0.138.0 — la versione del bug report — e 0.155.1, la versione attualmente fissata da NanoClaw, contro un endpoint locale che accetta la connessione e poi rimane silenzioso.
Questa è la riproduzione alla base di NanoClaw issue #3338, aperta senza risposta di un maintainer al momento della verifica. Per le scelte del provider, consulta NanoClaw API cost and providers; se il bot è silenzioso su Telegram per altri motivi, consulta NanoClaw Telegram not responding.
Cosa vedi
Un messaggio inviato al bot non riceve risposta — nessun errore né risposta parziale — per dieci minuti, poi arriva un errore. I messaggi inviati nel frattempo sembrano scomparire. Nei log:
# 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 600000msCosa ha mostrato la riproduzione
| Secondi dall'inizio del turno | Codex 0.138.0 | Codex 0.155.1 (pin di NanoClaw) |
|---|---|---|
| ≈1–16 | Prima richiesta inviata tramite WebSocket; nessuna risposta | Una richiesta di riscaldamento, chiusa da Codex a 16 s; segue la richiesta reale |
| ≈300–316 | La prima richiesta va in timeout; Codex reinvia la richiesta del turno — nessuna notifica | Timeout di inattività; registrato il tentativo 1 — nessuna notifica |
| 600 | Il timer di NanoClaw termina il turno: "Turn timed out after 600000ms" | |
| ≈601–616 | Timeout di inattività; registrato "retrying sampling request (1/5)" — ancora nessuna notifica (nessuna in 750 s) | Prima notifica error: "Reconnecting... 2/5", "idle timeout waiting for websocket" — con 15 secondi di ritardo |
L'endpoint era un sostituto che accettava il WebSocket senza inviare nulla; il client era il vero binario app-server di Codex, pilotato con le stesse chiamate effettuate da NanoClaw e valutato secondo la regola propria di NanoClaw — qualsiasi notifica di errore o un turno completato lo termina, altrimenti interviene il timer di dieci minuti.
Perché i tempi si allineano così male
- Codex attende 300 secondi il prossimo evento su uno stream Responses prima di considerare morto lo stream e riprova fino a cinque volte. Questi sono i valori predefiniti del provider OpenAI integrato in entrambe le versioni.
- Codex nasconde il primo tentativo WebSocket. Il codice di retry lo dichiara in un commento — "In release builds, hide the first websocket retry notification to reduce noisy transient reconnect messages" — quindi il front-end non riceve nulla fino al secondo tentativo, dopo circa dieci minuti.
- NanoClaw assegna a un turno Codex esattamente 600.000 ms e lo termina a ogni notifica di errore. Due finestre di inattività più il riscaldamento di Codex superano questo valore, quindi con le impostazioni predefinite vince il timer.
I messaggi inviati durante il silenzio vanno persi
NanoClaw invia a turn/steer di Codex un follow-up arrivato durante un turno attivo. Nell'esecuzione, Codex lo ha accettato nel turno bloccato e non ha inviato altro upstream; dopo il timeout, riprendere il thread mostrava il prompt originale nella cronologia, ma non il messaggio indirizzato. È questo che fa sembrare il bot completamente bloccato: tutto ciò che digiti finisce in un turno che non terminerà mai.
Come uscirne
Verificato: dopo il timeout, il messaggio successivo riprende lo stesso thread su un nuovo app-server — ciò che fa NanoClaw — e nell'esecuzione è terminato in 0,16 secondi non appena l'endpoint ha risposto. Quindi: attendi il timeout, poi reinvia ciò che hai digitato durante il silenzio. Se anche il messaggio successivo si blocca, il problema è ancora la connessione upstream — controlla lo stato di OpenAI e, se il container raggiunge OpenAI tramite un proxy, verifica se il proxy consente il passaggio delle richieste di upgrade al protocollo WebSocket (la pull request #2672 descrive proxy che non lo fanno; non testato qui).
Opzioni che riducono l'attesa, misurate ma non distribuite:
| Modifica | Primo errore visto da NanoClaw | Nota |
|---|---|---|
| Codex su HTTP/SSE invece che WebSockets — PR #3851, aperta, non integrata | 300 s: "Reconnecting... 1/5" | La notifica dice che Codex riproverà, e lo ha fatto, ma NanoClaw termina il turno in risposta — un fallimento dopo cinque minuti invece che dopo dieci |
Codex stream_idle_timeout_ms = 60.000 su WebSockets | 136 s | NanoClaw scrive autonomamente config.toml di Codex, quindi si tratta di una modifica al codice, non di un'impostazione che puoi aggiungere |
Entrambi terminano comunque il turno come fallimento. Le misurazioni indicano un problema lato NanoClaw — trattare un errore con retry come progresso anziché come fine, oppure misurare il budget del turno dall'ultimo evento reale — ma questa è un'inferenza basata su queste esecuzioni, non una correzione confermata dai maintainer.
Domande frequenti
Perché l'agente Codex di NanoClaw resta silenzioso per dieci minuti e poi va in timeout?
Perché il primo segnale di problemi che Codex è disposto a segnalare arriva dopo che NanoClaw ha già rinunciato. Quando il Responses WebSocket smette di inviare eventi, Codex attende un timeout di inattività di 300 secondi e riprova — e nelle build di release nasconde deliberatamente il primo tentativo di riconnessione WebSocket. La prima notifica di errore arriva dopo una seconda finestra di 300 secondi, oltre il timer fisso di 600.000 ms del turno di NanoClaw. Lo abbiamo riprodotto il 1° ottobre 2026: Codex 0.138.0 non ha inviato alcuna notifica in 750 secondi, mentre 0.155.1 — il pin attuale di NanoClaw — ha inviato la prima a 615,7 secondi; la regola di NanoClaw ha terminato il turno a 600.
Che fine fanno i messaggi che invio mentre il bot è bloccato?
Vengono indirizzati al turno bloccato e, nella nostra esecuzione, sono andati persi. NanoClaw indirizza a turn/steer di Codex un follow-up ricevuto durante un turno attivo; Codex lo ha accettato nello stesso turno bloccato, non ha inviato altro upstream e, dopo il timeout e la ripresa, il testo indirizzato non era nella cronologia del thread. Reinvia tutto ciò che hai digitato durante il silenzio quando il bot risponde di nuovo.
Come recupero da un timeout del turno Codex di NanoClaw?
Invia il messaggio successivo. NanoClaw avvia un nuovo app-server e riprende lo stesso thread; nella nostra esecuzione il turno ripreso è terminato in 0,16 secondi non appena l'endpoint ha risposto, con il prompt originale ancora nella cronologia. Se l'upstream continua a bloccarsi, il nuovo turno si bloccherà nello stesso modo, quindi controlla prima lo stato di OpenAI o il percorso di rete — e reinvia gli eventuali follow-up che sono stati inghiottiti.
Passare Codex a HTTP invece che a WebSockets risolve il problema?
Accorcia il silenzio, ma non è stato integrato. La pull request #3851 (aperta, dell'autore dell'issue) aggiunge NANOCLAW_CODEX_TRANSPORT=http e instrada Codex tramite HTTP/SSE. Nella nostra esecuzione di quel modello, la prima notifica di errore è arrivata a 300 secondi invece che dopo il timer — ma riportava willRetry true mentre Codex stava già reinviando, e NanoClaw termina un turno a ogni notifica di errore; quindi il turno fallirebbe dopo cinque minuti invece di recuperare.
È un timeout generale di Codex?
No. Codex continua a riprovare; il silenzio di dieci minuti deriva dal modo in cui il timer del turno di NanoClaw si allinea con il primo tentativo nascosto di Codex. Su 0.155.1 l'app-server ha riportato "Reconnecting... 2/5" a circa 616 secondi — un client con un budget di turno più lungo lo vedrebbe; NanoClaw no. Il provider predefinito di NanoClaw è Claude Agent SDK, che non è coinvolto.
Riprodotto il 1° ottobre 2026 con i binari nativi codex app-server da npm (@openai/codex 0.138.0 e 0.155.1, darwin-arm64), pilotati tramite stdio con i parametri initialize, thread/start, turn/start e turn/steer nel ramo providers di NanoClaw (commit 3959d1f055), contro un sostituto locale di Responses tramite WebSocket e HTTP/SSE. I valori predefiniti di Codex e il primo retry nascosto sono stati letti da codex-rs ai tag rust-v0.138.0 e rust-v0.155.1. Non eseguiti: orchestrator e container di NanoClaw, OneCLI, Telegram o l'endpoint reale di OpenAI — il sostituto riproduce uno stream silenzioso, non ciò che ha reso silenzioso quello di OpenAI. Stato dell'issue e della pull request letto lo stesso giorno.