"Turn timed out after 600000ms" no provedor Codex do NanoClaw significa que o Responses WebSocket do Codex parou de enviar eventos, e o primeiro erro relatado pelo Codex só chega depois que o temporizador fixo de dez minutos do NanoClaw já disparou. O Codex espera cinco minutos por um stream inativo, tenta novamente silenciosamente pela primeira vez e só relata a segunda tentativa. Reproduzimos isso em 1º de outubro de 2026 com o Codex 0.138.0 — a versão do relatório de bug — e o 0.155.1, a versão atualmente fixada pelo NanoClaw, contra um endpoint local que aceita a conexão e depois fica silencioso.
Esta é a reprodução por trás do issue #3338 do NanoClaw, que estava aberto sem resposta de mantenedor quando verificado. Para as próprias opções de provedor, consulte custo e provedores de API do NanoClaw; se o bot estiver silencioso no Telegram por outros motivos, consulte NanoClaw Telegram não responde.
O que você vê
Uma mensagem enviada ao bot não recebe resposta — nenhum erro, nenhuma resposta parcial — por dez minutos, e então surge um erro. As mensagens enviadas nesse intervalo parecem desaparecer. Nos logs:
# 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 600000msO que a reprodução mostrou
| Segundos após o início do turno | Codex 0.138.0 | Codex 0.155.1 (versão fixada pelo NanoClaw) |
|---|---|---|
| ≈1–16 | Primeira solicitação enviada pelo WebSocket; nenhuma resposta | Uma solicitação de aquecimento, fechada pelo Codex aos 16 s; a solicitação real vem em seguida |
| ≈300–316 | A primeira solicitação atinge o tempo limite; o Codex envia novamente a solicitação do turno — nenhuma notificação | Tempo limite de inatividade; tentativa 1 registrada — nenhuma notificação |
| 600 | O temporizador do NanoClaw encerra o turno: "Turn timed out after 600000ms" | |
| ≈601–616 | Tempo limite de inatividade; "retrying sampling request (1/5)" registrado — ainda sem notificação (nenhuma em 750 s) | Primeira notificação error: "Reconnecting... 2/5", "idle timeout waiting for websocket" — 15 segundos atrasada |
O endpoint era um substituto que aceitava o WebSocket e não enviava nada; o cliente era o binário real do app-server do Codex, acionado com as mesmas chamadas que o NanoClaw faz e avaliado pela própria regra do NanoClaw — qualquer notificação de erro ou um turno concluído o encerra; caso contrário, o temporizador de dez minutos o faz.
Por que os tempos se alinham tão mal
- O Codex espera 300 segundos pelo próximo evento em um stream Responses antes de considerar o stream morto e tenta novamente até cinco vezes. Esses são os padrões do provedor OpenAI integrado nas duas versões.
- O Codex oculta a primeira tentativa de reconexão pelo WebSocket. O código de nova tentativa diz isso em um comentário — "In release builds, hide the first websocket retry notification to reduce noisy transient reconnect messages" — portanto a interface frontal não ouve nada até a segunda tentativa, aproximadamente dez minutos depois.
- O NanoClaw dá a um turno do Codex exatamente 600,000 ms e o encerra em qualquer notificação de erro. Duas janelas de inatividade mais o aquecimento do Codex são mais longos do que isso, então, com as configurações padrão, o temporizador vence.
As mensagens enviadas durante o silêncio são perdidas
O NanoClaw envia um acompanhamento que chega durante um turno ativo ao turn/steer do Codex. Na execução, o Codex o aceitou no turno travado e não enviou nada novo upstream; após o tempo limite, retomar a thread mostrou o prompt original no histórico, mas não a mensagem de direcionamento. É isso que faz o bot parecer completamente travado: tudo o que você digita vai para um turno que nunca terminará.
Como sair disso
Verificado: após o tempo limite, a próxima mensagem retoma a mesma thread em um app-server novo — é isso que o NanoClaw faz — e, na execução, foi concluída em 0,16 segundo assim que o endpoint respondeu. Portanto: aguarde o tempo limite e reenvie o que você digitou durante o silêncio. Se a próxima mensagem também travar, o problema ainda está na conexão upstream — verifique o status da OpenAI e, se o container acessar a OpenAI por meio de um proxy, se esse proxy permite upgrades de WebSocket (o pull request #2672 descreve proxies que não permitem; não testado aqui).
Opções que reduzem o tempo de espera, medidas mas não lançadas:
| Alteração | Primeiro erro que o NanoClaw vê | Captura |
|---|---|---|
| Codex sobre HTTP/SSE em vez de WebSockets — PR #3851, aberto, não mesclado | 300 s: "Reconectando... 1/5" | A notificação diz que o Codex tentará novamente, e ele tentou, mas o NanoClaw encerra o turno nesse ponto — uma falha de cinco minutos em vez de uma de dez minutos |
Codex stream_idle_timeout_ms = 60.000 em WebSockets | 136 s | O NanoClaw grava o config.toml do Codex por conta própria, então isso é uma alteração de código, não uma configuração que você possa adicionar |
Ambos ainda encerram o turno como uma falha. O que as medições indicam está no lado do NanoClaw — tratar um erro que está tentando novamente como progresso, em vez de um encerramento, ou um orçamento de turno medido a partir do último evento real — mas isso é uma inferência dessas execuções, não uma correção confirmada pelos mantenedores.
Perguntas frequentes
Por que o agente Codex do NanoClaw fica silencioso por dez minutos e depois atinge o tempo limite?
Porque o primeiro sinal de problema que o Codex está disposto a relatar chega depois que o NanoClaw já desistiu. Quando o Responses WebSocket para de enviar eventos, o Codex aguarda um tempo limite de inatividade de 300 segundos e tenta novamente — e, nas versões de lançamento, oculta deliberadamente a primeira tentativa de reconexão pelo WebSocket. A primeira notificação de erro chega depois de uma segunda janela de 300 segundos, após o temporizador fixo de turno de 600.000 ms do NanoClaw. Reproduzimos isso em 1º de outubro de 2026: o Codex 0.138.0 não enviou nenhuma notificação em 750 segundos, e o 0.155.1 — a versão atualmente fixada pelo NanoClaw — enviou a primeira aos 615,7 segundos; a regra do NanoClaw encerrou o turno aos 600.
O que acontece com as mensagens que envio enquanto o bot está travado?
Elas são direcionadas ao turno travado e, em nossa execução, foram perdidas. O NanoClaw encaminha um acompanhamento que chega durante um turno ativo para o turn/steer do Codex; o Codex o aceitou no mesmo turno travado, não enviou nada novo para upstream e, após o tempo limite e uma retomada, o texto direcionado não estava no histórico da conversa. Reenvie tudo o que digitou durante o silêncio assim que o bot responder novamente.
Como me recupero de um tempo limite de turno do Codex no NanoClaw?
Envie a próxima mensagem. O NanoClaw inicia um novo app-server e retoma a mesma conversa; em nossa execução, o turno retomado foi concluído em 0.16 segundos assim que o endpoint respondeu, com o prompt original ainda no histórico. Se o upstream ainda estiver travando, o novo turno travará da mesma forma, então verifique primeiro o status da OpenAI ou seu caminho de rede — e reenvie quaisquer acompanhamentos que tenham sido engolidos.
Mudar o Codex para HTTP em vez de WebSockets resolve o problema?
Isso reduz o silêncio, e não foi integrado. O pull request #3851 (aberto, do autor do issue) adiciona NANOCLAW_CODEX_TRANSPORT=http, que encaminha o Codex por HTTP/SSE. Em nossa execução desse formato, a primeira notificação de erro chegou aos 300 segundos, em vez de depois do temporizador — mas trazia willRetry true enquanto o Codex já reenviava, e o NanoClaw encerra um turno em qualquer notificação de erro, portanto o turno falharia em cinco minutos em vez de se recuperar.
Este é um tempo limite geral do Codex?
Não. O próprio Codex continua tentando novamente; o silêncio de dez minutos vem da forma como o temporizador de turno do NanoClaw se alinha com a primeira tentativa de reconexão oculta do Codex. No 0.155.1, o app-server informou "Reconnecting... 2/5" por volta de 616 segundos — um cliente com um orçamento de turno maior veria isso; o NanoClaw nunca vê. O provedor padrão do NanoClaw é o Claude Agent SDK, que não está envolvido.
Reproduzido em 1º de outubro de 2026 com os binários nativos do app-server do codex provenientes do npm (@openai/codex 0.138.0 e 0.155.1, darwin-arm64), executados por stdio com os parâmetros initialize, thread/start, turn/start e turn/steer na branch providers do NanoClaw (commit 3959d1f055), contra um substituto local de Responses sobre WebSocket e HTTP/SSE. Os padrões do Codex e a primeira nova tentativa oculta foram lidos do codex-rs nas tags rust-v0.138.0 e rust-v0.155.1. Não executado: o orquestrador e o container do NanoClaw, OneCLI, Telegram ou o endpoint real da OpenAI — o substituto reproduz um fluxo silencioso, não o que fez o fluxo da OpenAI ficar silencioso. O status de issue e pull request foi consultado no mesmo dia.