"Turn timed out after 600000ms" on NanoClaw's Codex provider means Codex's Responses WebSocket stopped sending events, and the first error Codex reports arrives only after NanoClaw's fixed ten-minute turn timer has already fired. Codex waits five minutes for an idle stream, retries silently the first time, and reports only the second retry. We reproduced it on October 1, 2026 with Codex 0.138.0 — the version in the bug report — and 0.155.1, the version NanoClaw currently pins, against a local endpoint that accepts the connection and then goes quiet.
This is the reproduction behind NanoClaw issue #3338, which was open with no maintainer reply when checked. For the provider choices themselves, see NanoClaw API cost and providers; if the bot is silent on Telegram for other reasons, NanoClaw Telegram not responding.
What you see
A message to the bot gets no answer — no error, no partial reply — for ten minutes, and then an error. Messages sent in the meantime seem to vanish. In the 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 600000msWhat the reproduction showed
| Seconds into the turn | Codex 0.138.0 | Codex 0.155.1 (NanoClaw's pin) |
|---|---|---|
| ≈1–16 | First request sent over WebSocket; no reply | A warm-up request, closed by Codex at 16 s; the real request follows |
| ≈300–316 | First request times out; Codex sends the turn's request again — no notification | Idle timeout; retry 1 logged — no notification |
| 600 | NanoClaw's timer ends the turn: "Turn timed out after 600000ms" | |
| ≈601–616 | Idle timeout; "retrying sampling request (1/5)" logged — still no notification (none at all in 750 s) | First error notification: "Reconnecting... 2/5", "idle timeout waiting for websocket" — 15 seconds too late |
The endpoint was a stand-in that accepted the WebSocket and sent nothing; the client was the real Codex app-server binary, driven with the same calls NanoClaw makes and judged by NanoClaw's own rule — any error notification or a completed turn ends it, otherwise the ten-minute timer does.
Why the timing lines up so badly
- Codex waits 300 seconds for the next event on a Responses stream before it calls the stream dead, and retries up to five times. Those are the defaults for the built-in OpenAI provider in both versions.
- Codex hides the first WebSocket retry. Its retry code says so in a comment — "In release builds, hide the first websocket retry notification to reduce noisy transient reconnect messages" — so a front end hears nothing until the second retry, roughly ten minutes in.
- NanoClaw gives a Codex turn exactly 600,000 ms and ends it on any error notification. Two idle windows plus Codex's warm-up are longer than that, so with the default settings the timer wins.
Messages sent during the silence are lost
NanoClaw sends a follow-up that arrives during an active turn to Codex's turn/steer. In the run, Codex accepted it into the stalled turn and sent nothing new upstream; after the timeout, resuming the thread showed the original prompt in history but not the steered message. That is what makes the bot look completely stuck: everything you type goes into a turn that will never finish.
Getting out of it
Verified: after the timeout, the next message resumes the same thread on a fresh app-server — what NanoClaw does — and in the run it completed in 0.16 seconds once the endpoint answered. So: wait for the timeout, then resend whatever you typed during the silence. If the next message stalls too, the upstream connection is still the problem — check OpenAI's status and, if the container reaches OpenAI through a proxy, whether that proxy passes WebSocket upgrades (pull request #2672 describes proxies that do not; not tested here).
Options that shorten the wait, measured but not shipped:
| Change | First error NanoClaw sees | Catch |
|---|---|---|
| Codex over HTTP/SSE instead of WebSockets — PR #3851, open, unmerged | 300 s: "Reconnecting... 1/5" | The notification says Codex will retry, and it did, but NanoClaw ends the turn on it — a five-minute failure instead of a ten-minute one |
Codex stream_idle_timeout_ms = 60,000 on WebSockets | 136 s | NanoClaw writes Codex's config.toml itself, so this is a code change, not a setting you can add |
Both still end the turn as a failure. What the measurements point to is on NanoClaw's side — treating a retrying error as progress rather than an end, or a turn budget measured from the last real event — but that is an inference from these runs, not a fix the maintainers have confirmed.
FAQ
Why does NanoClaw's Codex agent go silent for ten minutes and then time out?
Because the first sign of trouble Codex is willing to report arrives after NanoClaw has already given up. When the Responses WebSocket stops sending events, Codex waits out a 300-second idle timeout and retries — and in release builds it deliberately hides the first WebSocket retry. The first error notification comes after a second 300-second window, past NanoClaw's fixed 600,000 ms turn timer. We reproduced it on October 1, 2026: Codex 0.138.0 sent no notification at all in 750 seconds, and 0.155.1 — NanoClaw's current pin — sent its first at 615.7 seconds; NanoClaw's rule ended the turn at 600.
What happens to messages I send while the bot is stuck?
They are steered into the stuck turn and, in our run, lost. NanoClaw routes a follow-up that arrives during an active turn to Codex's turn/steer; Codex accepted it into the same stalled turn, sent nothing new upstream, and after the timeout and a resume the steered text was not in the thread's history. Resend anything you typed during the silence once the bot answers again.
How do I recover from a NanoClaw Codex turn timeout?
Send the next message. NanoClaw starts a fresh app-server and resumes the same thread; in our run that resumed turn completed in 0.16 seconds once the endpoint answered, with the original prompt still in history. If the upstream is still stalling, the new turn stalls the same way, so check OpenAI's status or your network path first — and resend any follow-ups that were swallowed.
Does switching Codex to HTTP instead of WebSockets fix it?
It shortens the silence, and it is not merged. Pull request #3851 (open, from the issue's reporter) adds NANOCLAW_CODEX_TRANSPORT=http, which routes Codex through HTTP/SSE. In our run of that shape, the first error notification arrived at 300 seconds instead of after the timer — but it carried willRetry true while Codex was already re-sending, and NanoClaw ends a turn on any error notification, so the turn would fail at five minutes rather than recover.
Is this a general Codex timeout?
No. Codex itself keeps retrying; the ten-minute silence comes from how NanoClaw's turn timer lines up with Codex's hidden first retry. On 0.155.1 the app-server reported "Reconnecting... 2/5" at about 616 seconds — a client with a longer turn budget would see it; NanoClaw never does. NanoClaw's default provider is the Claude Agent SDK, which is not involved.
Reproduced on October 1, 2026 with the native codex app-server binaries from npm (@openai/codex 0.138.0 and 0.155.1, darwin-arm64), driven over stdio with the initialize, thread/start, turn/start and turn/steer parameters in NanoClaw's providers branch (commit 3959d1f055), against a local Responses stand-in over WebSocket and HTTP/SSE. Codex defaults and the hidden first retry read from codex-rs at tags rust-v0.138.0 and rust-v0.155.1. Not run: NanoClaw's orchestrator and container, OneCLI, Telegram, or OpenAI's real endpoint — the stand-in reproduces a silent stream, not whatever made OpenAI's go silent. Issue and pull-request status read the same day.