Codexの「stream disconnected before completion」は何が原因？切り分けと再開手順

stream disconnected before completionは、Codexの応答が正常に完了しなかったことを示します。この文言だけでは原因を一つに絞れません。後ろに続くエラーを読み、通信方式がSSEかWebSocketかを確認したうえで、明示的な利用枠・コンテキストのエラーと、完了イベントが届く前の切断を分けて調べます。

再試行する前に、エージェントが変更したファイルと、ツールが実行した操作を確認してください。応答の切断は、それまでのコマンドが取り消されたことを意味しません。本記事はCodexの利用者と、Responses互換エンドポイントを運用する開発者向けです。2026年9月14日に確認した公式文書とソースコードに基づいており、読者の環境で発生した障害を再現したものではありません。

先頭の文言ではなく、その後のエラーで分類する

現在のCodex SSEパーサーは、未完了のストリームと、すでに記録されたより具体的なエラーを区別しています。汎用的なclosed-before-completedエラーが表示されても、利用者のインターネット接続が原因だと断定はできません。

途中まで読める回答が表示されていても、応答が完了した証拠にはなりません。ストリーミングの公式文書では、テキストのイベントと応答のライフサイクルを示すイベントが区別されています。response.output_text.doneはテキスト部分の終了であり、応答全体の完了通知の代わりにはできません。

作業を繰り返す前に、実行済みの内容を確認する

現在の差分、端末出力、開始済みの外部操作を確認します。ツールの処理が終わっていても、最後のモデル応答だけが画面に届かないことがあります。状態を変更する操作は、再実行を指示する前に、対象システムや実行記録を確かめてください。

自動再試行によって必ず一度だけ実行される、あるいは失敗に見えるリクエストは無料になる、と考えてはいけません。その保証は処理とプロバイダーによって異なります。コーディング作業を続けるときは、確認済みの結果と未確認の部分を伝え、次の試行ですべての手順を無条件にやり直さないようにします。

切り分けには、新しい会話で短い読み取り専用のタスクを使います。最初はモデルと接続経路を変えません。新しい会話では成功し、元の会話でだけ失敗するなら、履歴の長さ、コンパクション、ツールの呼び出し順を調べる価値があります。ただし、それだけで特定のクライアント不具合が証明されるわけではありません。

明示的なエラーは、それぞれの原因に沿って処理する

公式のAPIエラーガイドは、認証、アクセス権、レート制限、サーバー障害を分けています。すべてのストリーム失敗を再試行可能な通信障害として扱わず、レスポンス本文を確認してください。

モデルが存在しない、または接続先が違う場合は、model-not-foundの解説（英語）が該当します。サブスクリプションの利用枠、APIの請求残高、一定時間あたりのレート制限は別のものです。アカウントの利用期間と上限についてはCodexの使用量制限ガイドを参照してください。使用量のエラーが明示されているのに、通信のタイムアウトを増やし続けても解決にはなりません。

同様に、context_length_exceededは接続の無通信時間とは異なる制約です。クライアントが対応する機能でコンテキストを整理・削減し、重要な作業状態を保存します。空の会話を試すことは切り分けに役立ちますが、元のリクエストにどの履歴が含まれていたかを調べる代わりにはなりません。

実際の通信経路を確認する

エンドポイントのホスト名、プロキシ設定、クライアントのバージョン、通信方式を記録します。SSEとWebSocketは別々に確認してください。通常のHTTPSを処理できるプロキシでも、接続の維持時間やWebSocketの扱いが異なる場合があります。管理権限があれば、クライアント・ゲートウェイ・上流のログを比較します。

利用可能であれば、組織が許可した標準のネットワーク経路と比較します。テストを通すためにTLS検証やセキュリティ制御を無効化しないでください。証明書エラーでは、検証を回避するのではなく証明書チェーンを調べます。

イベントが来ない状態が一定時間続くと失敗するのか、特定の経路だけで起きるのか、ツールを多用するターンに限られるのかを確認します。これらの傾向は次に何を試すかの手がかりになりますが、追加の観測なしにモデル提供元、プロキシ、クライアントの責任を決めることはできません。

アイドルタイムアウトと再試行設定を区別する

現在のCodex設定リファレンスでは、カスタムプロバイダーのstream_idle_timeout_ms、stream_max_retries、request_max_retriesが分かれています。記載されている既定値は順に300,000ミリ秒、ストリーム再試行5回、リクエスト再試行4回です。これは確認日時点の文書にある値です。ストリーム設定はSSE向けに説明されており、すべてのWebSocket障害に適用されるとは限りません。

アイドルタイムアウトは、対象のストリームでイベントが届かない状態が続いた時間を測ります。タスク全体の最大実行時間ではありません。値を増やしても、別の理由でサーバーや中継機器が接続を閉じることは防げません。そのタイムアウトが原因だと示す証拠があり、上流が長い待機に対応している場合にだけ変更します。

有効になっている設定の確認には、config.tomlガイド（英語）を利用してください。使われていないプロファイルを変更しても、実行中の会話には反映されません。すべてのCodexバージョンでWebSocketを無効化できると称する未検証の設定を、そのままコピーするのは避けます。

調査に使える障害記録を残す

開始時刻と失敗時刻、OS、クライアントのバージョン、通信方式、エンドポイントのホスト名、エラー全文、リクエストIDまたはレスポンスIDを残します。新しい会話では成功するか、ツールがすでに実行されていたか、安全に再現できる最小のタスクは何かも追記します。

ログを共有する前に、シークレット、Cookie、認証ファイル、非公開リポジトリの内容を除去してください。過去のissueは比較材料になりますが、日付と状態を確認します。たとえばCodex issue 4302はクローズ済みの過去の報告です。同じ古い不具合が現在も未修正であることの証拠にはなりません。

よくある質問

このエラーは必ずネットワーク障害を意味しますか？

いいえ。この接頭辞は応答が正常に完了しなかった状況を広く表します。接続障害と明示的なリクエスト失敗を分けるには、後ろに続くメッセージ、ライフサイクルイベント、プロバイダーのエラーが必要です。

Codexにすべてやり直させても大丈夫ですか？

先に実行済みの内容を確かめてください。ストリームが切れる前に、ファイル変更や外部ツールの処理が完了している場合があります。繰り返すと作業や外部操作が重複する可能性があります。

タイムアウトを増やし続けるべきですか？

対象のアイドルタイムアウトが原因と確認できた場合だけです。クライアントの待機時間を延ばしても、無効な認証情報、利用できないモデル、利用枠の消費、上流の接続ポリシーは直りません。