„Turn timed out after 600000ms“ beim Codex-Anbieter von NanoClaw bedeutet, dass Codex' Responses-WebSocket keine Ereignisse mehr sendete und der erste von Codex gemeldete Fehler erst eintrifft, nachdem NanoClaws fester zehnminütiger Turn-Timer bereits ausgelöst wurde. Codex wartet fünf Minuten auf einen inaktiven Stream, versucht es beim ersten Mal still erneut und meldet erst den zweiten Wiederholungsversuch. Wir haben dies am 1. Oktober 2026 mit Codex 0.138.0 — der Version im Fehlerbericht — und 0.155.1, der Version, die NanoClaw derzeit pinnt, gegen einen lokalen Endpunkt reproduziert, der die Verbindung akzeptiert und anschließend still bleibt.
Dies ist die Reproduktion hinter NanoClaw issue #3338, das bei der Prüfung offen war und keine Antwort eines Maintainers hatte. Informationen zu den Anbieteroptionen selbst findest du unter NanoClaw API cost and providers; wenn der Bot aus anderen Gründen auf Telegram stumm ist, siehe NanoClaw Telegram not responding.
Was Sie sehen
Eine Nachricht an den Bot erhält keine Antwort — keinen Fehler, keine Teilantwort — zehn Minuten lang, danach kommt ein Fehler. Nachrichten, die in der Zwischenzeit gesendet wurden, scheinen zu verschwinden. In den Protokollen:
# 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 600000msWas die Reproduktion zeigte
| Sekunden nach Beginn des Turns | Codex 0.138.0 | Codex 0.155.1 (NanoClaws Pin) |
|---|---|---|
| ≈1–16 | Erste Anfrage über WebSocket gesendet; keine Antwort | Eine Aufwärmanfrage, die Codex nach 16 s schloss; die echte Anfrage folgt |
| ≈300–316 | Erste Anfrage läuft in einen Timeout; Codex sendet die Anfrage des Turns erneut — keine Benachrichtigung | Leerlauf-Timeout; Wiederholungsversuch 1 protokolliert — keine Benachrichtigung |
| 600 | NanoClaws Timer beendet den Turn: „Turn timed out after 600000ms“ | |
| ≈601–616 | Leerlauf-Timeout; „retrying sampling request (1/5)“ protokolliert — weiterhin keine Benachrichtigung (in 750 s überhaupt keine) | Erste error-Benachrichtigung: „Reconnecting... 2/5“, „idle timeout waiting for websocket“ — 15 Sekunden zu spät |
Der Endpunkt war ein Platzhalter, der den WebSocket akzeptierte und nichts sendete; der Client war das echte Codex-App-Server-Binärprogramm, gesteuert mit denselben Aufrufen wie NanoClaw und anhand NanoClaws eigener Regel bewertet — jede Fehlermeldung oder ein abgeschlossener Turn beendet ihn, andernfalls greift der zehnminütige Timer.
Warum das Timing so schlecht zusammenpasst
- Codex wartet 300 Sekunden auf das nächste Ereignis eines Responses-Streams, bevor er den Stream als beendet betrachtet, und versucht es bis zu fünfmal erneut. Das sind die Standardwerte für den integrierten OpenAI-Anbieter in beiden Versionen.
- Codex verbirgt den ersten WebSocket-Wiederholungsversuch. Sein Wiederholungscode sagt dies in einem Kommentar — „In release builds, hide the first websocket retry notification to reduce noisy transient reconnect messages“ — daher hört ein Frontend bis zum zweiten Wiederholungsversuch nichts, ungefähr zehn Minuten lang.
- NanoClaw gibt einem Codex-Turn genau 600.000 ms und beendet ihn bei jeder Fehlermeldung. Zwei Leerlaufzeitfenster plus Codex' Aufwärmphase sind länger als das, daher gewinnt bei den Standardeinstellungen der Timer.
Während der Stille gesendete Nachrichten gehen verloren
NanoClaw sendet eine während eines aktiven Turns eintreffende Folgeaktion an Codex' turn/steer. Im Lauf nahm Codex sie in den festgefahrenen Turn auf und sendete upstream nichts Neues; nach dem Timeout zeigte die Fortsetzung des Threads den ursprünglichen Prompt im Verlauf, nicht aber die gesteuerte Nachricht. Dadurch wirkt der Bot vollständig festgefahren: Alles, was du eingibst, landet in einem Turn, der niemals beendet wird.
So kommst du heraus
Verifiziert: Nach dem Timeout setzt die nächste Nachricht denselben Thread auf einem frischen App-Server fort — so arbeitet NanoClaw — und im Lauf wurde sie in 0,16 Sekunden abgeschlossen, sobald der Endpunkt antwortete. Also: Warte auf den Timeout und sende danach alles erneut, was du während der Stille eingegeben hast. Wenn auch die nächste Nachricht hängen bleibt, ist die Upstream-Verbindung weiterhin das Problem — prüfe den Status von OpenAI und, falls der Container OpenAI über einen Proxy erreicht, ob dieser Proxy WebSocket-Upgrades durchlässt (Pull Request #2672 beschreibt Proxys, die dies nicht tun; hier nicht getestet).
Optionen, die die Wartezeit verkürzen, gemessen, aber nicht ausgeliefert:
| Änderung | Erster von NanoClaw gesehener Fehler | Abfangen |
|---|---|---|
| Codex über HTTP/SSE statt über WebSockets — PR #3851, offen, nicht zusammengeführt | 300 s: „Reconnecting... 1/5“ | Die Benachrichtigung sagt, dass Codex es erneut versuchen wird, und das tat er auch, aber NanoClaw beendet den Turn daraufhin — ein fünfminütiger statt ein zehnminütiger Fehler |
Codex stream_idle_timeout_ms = 60.000 bei WebSockets | 136 s | NanoClaw schreibt Codex' config.toml selbst, daher ist dies eine Codeänderung und keine Einstellung, die du hinzufügen kannst |
Beide beenden den Turn weiterhin als Fehler. Die Messungen deuten auf NanoClaws Seite als Ansatzpunkt hin — einen sich wiederholenden Fehler als Fortschritt statt als Ende zu behandeln oder ein Turn-Budget ab dem letzten echten Ereignis zu messen — aber das ist eine Schlussfolgerung aus diesen Läufen und keine von den Maintainers bestätigte Korrektur.
Häufig gestellte Fragen
Warum verstummt der Codex-Agent von NanoClaw zehn Minuten lang und läuft dann in einen Timeout?
Weil das erste Anzeichen eines Problems, das Codex zu melden bereit ist, erst eintrifft, nachdem NanoClaw bereits aufgegeben hat. Wenn der Responses-WebSocket keine Ereignisse mehr sendet, wartet Codex einen Leerlauf-Timeout von 300 Sekunden ab und versucht es erneut — in Release-Builds unterdrückt er den ersten WebSocket-Wiederholungsversuch absichtlich. Die erste Fehlermeldung kommt erst nach einem zweiten Zeitfenster von 300 Sekunden, also nach NanoClaws festem Turn-Timer von 600.000 ms. Wir haben dies am 1. Oktober 2026 reproduziert: Codex 0.138.0 sendete in 750 Sekunden überhaupt keine Benachrichtigung, und 0.155.1 — NanoClaws aktueller Pin — sendete die erste nach 615,7 Sekunden; NanoClaws Regel beendete den Turn nach 600.
Was passiert mit Nachrichten, die ich sende, während der Bot feststeckt?
Sie werden in den feststeckenden Turn geleitet und gingen in unserem Lauf verloren. NanoClaw leitet eine während eines aktiven Turns eintreffende Folgeaktion an Codex' turn/steer weiter; Codex nahm sie in denselben festgefahrenen Turn auf, sendete upstream nichts Neues, und nach dem Timeout und einer Fortsetzung war der gesteuerte Text nicht im Verlauf des Threads. Sende alles, was du während der Stille eingegeben hast, erneut, sobald der Bot wieder antwortet.
Wie erhole ich mich von einem NanoClaw-Codex-Turn-Timeout?
Sende die nächste Nachricht. NanoClaw startet einen frischen App-Server und setzt denselben Thread fort; in unserem Lauf wurde der fortgesetzte Turn in 0,16 Sekunden abgeschlossen, sobald der Endpunkt antwortete, wobei der ursprüngliche Prompt weiterhin im Verlauf war. Wenn der Upstream weiterhin hängt, hängt auch der neue Turn auf dieselbe Weise, also prüfe zuerst den Status von OpenAI oder deinen Netzwerkpfad — und sende alle verschluckten Folgenachrichten erneut.
Behebt es das Problem, Codex statt über WebSockets über HTTP zu schalten?
Es verkürzt die Stille, ist aber nicht integriert. Pull Request #3851 (offen, vom Melder des Problems) fügt NANOCLAW_CODEX_TRANSPORT=http hinzu, das Codex über HTTP/SSE leitet. In unserem Lauf mit dieser Form kam die erste Fehlermeldung nach 300 Sekunden statt erst nach dem Timer — sie enthielt jedoch willRetry true, während Codex bereits erneut sendete, und NanoClaw beendet einen Turn bei jeder Fehlermeldung; der Turn würde daher nach fünf Minuten fehlschlagen, statt sich zu erholen.
Handelt es sich um einen allgemeinen Codex-Timeout?
Nein. Codex selbst versucht es weiterhin erneut; die zehnminütige Stille entsteht dadurch, wie NanoClaws Turn-Timer mit Codex' verborgenem ersten Wiederholungsversuch zusammenfällt. Bei 0.155.1 meldete der App-Server „Reconnecting... 2/5“ nach etwa 616 Sekunden — ein Client mit einem längeren Turn-Budget würde es sehen; NanoClaw nie. NanoClaws Standardanbieter ist das Claude Agent SDK, das hier nicht beteiligt ist.
Am 1. Oktober 2026 reproduziert mit den nativen Codex-App-Server-Binärdateien aus npm (@openai/codex 0.138.0 und 0.155.1, darwin-arm64), über stdio gesteuert mit den Parametern initialize, thread/start, turn/start und turn/steer aus NanoClaws Providers-Branch (Commit 3959d1f055), gegen einen lokalen Responses-Platzhalter über WebSocket und HTTP/SSE. Codex-Standards und der verborgene erste Wiederholungsversuch wurden aus codex-rs bei den Tags rust-v0.138.0 und rust-v0.155.1 gelesen. Nicht ausgeführt: NanoClaws Orchestrator und Container, OneCLI, Telegram oder OpenAIs echter Endpunkt — der Platzhalter reproduziert einen stillen Stream, nicht das, was OpenAIs Stream zum Verstummen gebracht haben könnte. Status von Issue und Pull Request am selben Tag geprüft.