NanoClaw Codexのタイムアウト：「600000ms停止」の説明

NanoClawのCodexプロバイダーで「Turn timed out after 600000ms」と表示される場合、CodexのResponses WebSocketがイベントの送信を停止しており、Codexが最初のエラーを報告するのは、NanoClawの固定された10分間のターンタイマーがすでに発火した後だけです。Codexはアイドルストリームを5分間待ち、最初は静かに再試行し、2回目の再試行でのみ報告します。2026年10月1日、バグ報告に記載されたバージョンであるCodex 0.138.0と、NanoClawが現在固定しているバージョン0.155.1を使い、接続を受け付けた後に無反応になるローカルエンドポイントに対して再現しました。

これは、確認時点でメンテナーからの返信がなく公開中だったNanoClaw issue #3338の再現です。プロバイダーの選択肢自体については、NanoClawのAPIコストとプロバイダーを参照してください。その他の理由でTelegram上のボットが無反応な場合は、NanoClaw Telegramが応答しないを参照してください。

表示される内容

ボットにメッセージを送っても、エラーも途中の返信もなく10分間応答がなく、その後エラーになります。その間に送ったメッセージは消えたように見えます。ログでは次のようになります。

ログに現れる停止の様子

# 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 600000ms

再現で確認されたこと

ターン開始からの秒数	Codex 0.138.0	Codex 0.155.1（NanoClawの固定バージョン）
≈1–16	WebSocket経由で最初のリクエストを送信。返信なし	ウォームアップリクエスト。Codexが16秒で切断し、実際のリクエストが続く
≈300–316	最初のリクエストがタイムアウト。Codexがターンのリクエストを再送 — 通知なし	アイドルタイムアウト。再試行1を記録 — 通知なし
600	NanoClawのタイマーがターンを終了：「Turn timed out after 600000ms」
≈601–616	アイドルタイムアウト。「retrying sampling request (1/5)」を記録 — 依然として通知なし（750秒間まったくなし）	最初の`error`通知：「Reconnecting... 2/5」、「idle timeout waiting for websocket」 — 15秒遅すぎる

エンドポイントはWebSocket接続を受け付けたものの何も送信しない代替エンドポイントで、クライアントは実際のCodex app-serverバイナリでした。NanoClawが行うのと同じ呼び出しで動かし、NanoClaw自身のルール、つまりエラー通知またはターン完了で終了し、それ以外では10分のタイマーで終了するルールで判定しました。

タイミングがこれほど悪く重なる理由

CodexはResponsesストリームの次のイベントを300秒待ちます。その後ストリームが停止したと判断し、最大5回まで再試行します。これは両バージョンの組み込みOpenAIプロバイダーのデフォルト値です。
Codexは最初のWebSocket再試行を隠します。再試行コードのコメントにも、「リリースビルドでは、ノイズの多い一時的な再接続メッセージを減らすため、最初のwebsocket再試行通知を隠す」と明記されています。そのため、フロントエンドには、およそ10分後の2回目の再試行まで何の通知も届きません。
NanoClawはCodexのターンに正確に600,000 msを与え、任意のエラー通知で終了します。2回のアイドルウィンドウとCodexのウォームアップを合わせるとそれを超えるため、デフォルト設定ではタイマーが先に終了します。

無反応中に送ったメッセージは失われる

NanoClawはアクティブなターン中に届いたフォローアップをCodexのturn/steerへ送ります。実行では、Codexはそれを停止中のターンに受け入れ、上流へ新しい情報を何も送信しませんでした。タイムアウト後にスレッドを再開すると、履歴には元のプロンプトはありましたが、steerされたメッセージはありませんでした。これによりボットは完全に停止したように見えます。入力したすべての内容が、決して完了しないターンに入ってしまうからです。

復旧方法

確認済み：タイムアウト後、次のメッセージで新しいapp-server上の同じスレッドが再開されます。これはNanoClawの動作です。実行では、エンドポイントが応答すると0.16秒で完了しました。つまり、タイムアウトを待ち、無反応中に入力した内容を再送してください。次のメッセージも停止するなら、上流接続が依然として問題です。OpenAIのステータスを確認し、コンテナがプロキシ経由でOpenAIに接続している場合は、そのプロキシがWebSocketアップグレードを通過させるか確認してください（プルリクエスト#2672では、通過させないプロキシについて説明していますが、ここではテストしていません）。

待ち時間を短縮する選択肢（測定済み、未リリース）：

変更	NanoClawが確認する最初のエラー	影響
WebSocketの代わりにHTTP/SSE経由でCodex — PR #3851、公開中、未マージ	300秒：「Reconnecting... 1/5」	通知はCodexが再試行すると示し、実際に再試行しました。しかしNanoClawはそこでターンを終了するため、10分ではなく5分で失敗します。
WebSocket上でCodex `stream_idle_timeout_ms` = 60,000	136秒	NanoClawはCodexのconfig.tomlを自体で書き出すため、これは追加できる設定ではなくコード変更です。

どちらも依然としてターンを失敗として終了します。測定結果が示しているのはNanoClaw側の問題です。つまり、再試行中のエラーを終了ではなく進行として扱うか、最後の実際のイベントからターン予算を測定する必要があります。ただし、これはこれらの実行からの推測であり、メンテナーが確認した修正ではありません。

よくある質問

NanoClawのCodexエージェントが10分間無反応になった後、タイムアウトするのはなぜですか？

Codexが報告しようとする最初の問題の兆候が、NanoClawがすでに諦めた後に届くためです。Responses WebSocketがイベントの送信を停止すると、Codexは300秒のアイドルタイムアウトを待って再試行します。リリースビルドでは、最初のWebSocket再試行を意図的に隠します。最初のエラー通知は、2回目の300秒ウィンドウの後、NanoClawの固定された600,000 msのターンタイマーを過ぎてから届きます。2026年10月1日に再現したところ、Codex 0.138.0は750秒間まったく通知を送らず、NanoClawが現在固定している0.155.1は615.7秒で最初の通知を送りました。NanoClawのルールは600秒でターンを終了しました。

ボットが停止している間に送ったメッセージはどうなりますか？

停止中のターンに取り込まれ、私たちの実行では失われました。NanoClawはアクティブなターン中に届いたフォローアップをCodexのturn/steerへ送ります。Codexはそれを同じ停止中のターンに受け入れ、上流には新しい情報を何も送らず、タイムアウト後に再開しても、steerされたテキストはスレッド履歴にありませんでした。ボットが再び応答したら、無反応中に入力した内容をすべて再送してください。

NanoClawのCodexターンタイムアウトから復旧するにはどうすればよいですか？

次のメッセージを送ってください。NanoClawは新しいapp-serverを起動し、同じスレッドを再開します。私たちの実行では、エンドポイントが応答すると、再開したターンは0.16秒で完了し、元のプロンプトも履歴に残っていました。上流がまだ停止している場合は、新しいターンも同じように停止するため、まずOpenAIのステータスまたはネットワーク経路を確認し、取り込まれたフォローアップを再送してください。

CodexをWebSocketではなくHTTPに切り替えると直りますか？

無反応の時間は短くなりますが、まだマージされていません。プルリクエスト#3851（未クローズで、issueの報告者によるもの）はNANOCLAW_CODEX_TRANSPORT=httpを追加し、CodexをHTTP/SSE経由でルーティングします。その形で実行したところ、最初のエラー通知はタイマーの後ではなく300秒で届きました。しかし、Codexがすでに再送中なのにwillRetry trueが含まれており、NanoClawはどのエラー通知でもターンを終了するため、復旧するのではなく5分で失敗することになります。

これは一般的なCodexのタイムアウトですか？

いいえ。Codex自体は再試行を続けています。10分間の無反応は、NanoClawのターンタイマーとCodexが隠している最初の再試行のタイミングが重なることで発生します。0.155.1では、app-serverが約616秒で「Reconnecting... 2/5」を報告しました。ターン予算が長いクライアントならこれを確認できますが、NanoClawでは確認できません。NanoClawのデフォルトプロバイダーはClaude Agent SDKであり、これは関与していません。

2026年10月1日、npmのネイティブcodex app-serverバイナリ（@openai/codex 0.138.0および0.155.1、darwin-arm64）を使い、NanoClawのprovidersブランチ（コミット3959d1f055）のinitialize、thread/start、turn/start、turn/steerパラメーターと同じ呼び出しをstdio経由で実行し、WebSocketおよびHTTP/SSE上のローカルResponses代替エンドポイントに対して再現しました。Codexのデフォルト値と隠された最初の再試行は、タグrust-v0.138.0およびrust-v0.155.1のcodex-rsから確認しました。未実施：NanoClawのオーケストレーターとコンテナ、OneCLI、Telegram、OpenAIの実際のエンドポイント。代替エンドポイントが再現するのは無言のストリームであり、OpenAIを無反応にした原因そのものではありません。issueとプルリクエストの状態は同日に確認しました。

NanoClaw Codexのタイムアウト：停止したターンが10分待機する理由、再現結果