ガイド一覧へ戻る
トラブルシューティング·2026年9月23日·読了6分

Codexの「stream disconnected before completion」—ストリームを終了させたものと、Codexが自動的に再試行するもの

CodexはResponsesストリームを読み取っていた、または開こうとしていましたが、response.completedイベントが到着する前に終了しました。接続が閉じた、無通信状態になった、ネットワークレベルで切断された、またはサーバーが失敗を報告した可能性があります。Codexはデフォルトで5回、自動的に再試行します。コロンの後に表示される理由からどれが起きたかが分かり、調査すべき場所が決まります。

最終確認日:。

CodexはResponsesストリームを読み取っていた、または開こうとしていましたが、response.completedイベントが到着する前に終了しました。接続が閉じた、無通信状態になった、ネットワークレベルで切断された、またはサーバーが失敗を報告した可能性があります。Codexはデフォルトで5回、自動的に再試行します。コロンの後に表示される理由からどれが起きたかが分かり、調査すべき場所が決まります。

エラー

Codex output (layout varies by client)
# Codex CLI, once its retries are spent
■ stream disconnected before completion: stream closed before response.completed

# While it retries (VS Code extension, an early-2026 build)
Reconnecting... 1/5
stream disconnected before completion: error sending request for url (https://…/responses)

# The reason after the colon varies, and it is the diagnosis:
#   stream closed before response.completed
#   idle timeout waiting for SSE
#   error sending request            (Codex before 0.156 adds: for url (…))
#   An error occurred while processing your request. You can retry your request, …
#   Incomplete response returned, reason: max_output_tokens

原因と対処法の概要

原因対処法
VPN、プロキシ、ファイアウォール、またはTLS検査を行う中間ボックスが接続を閉じました別のネットワークから再試行してください。エラーが止まる場合は、そのプロキシまたは検査からAPIホストを除外します。
サーバーが応答途中で失敗しました — 理由はサーバー自身のメッセージですローカルで変更することはありません。Codexに再試行させ、プロバイダーのステータスを確認し、後でもう一度試してください。
stream_idle_timeout_ms(デフォルトでは300,000ミリ秒)の間、何も到着しませんでした上流の停止、またはバッファリングするプロキシです。正当な無通信状態に限ってタイムアウトを延長してください。
response.completedなしでストリームを終了するカスタムプロバイダーcurl -Nで実行してください。成功するすべてのレスポンスは、そのイベントで終了する必要があります。
レスポンスは意図的に終了しました — 「Incomplete response returned」トークン上限、コンテンツフィルター、または別の停止理由が示されています。再試行しても通常は同じ結果になるため、リクエストを変更してください。

コロンの後にある理由を読む

Codexは、より具体的な診断なしに早期終了したストリームに対してこの1つのエラーを使用し、理由を追加します。ソースでは、単に終了したストリームには「stream closed before response.completed」と表示されます。stream_idle_timeout_msを超えて無通信だった場合は「idle timeout waiting for SSE」と表示されます(組み込みOpenAIプロバイダーが使用するWebSocketトランスポートでは「idle timeout waiting for websocket」)。通信上で壊れたリクエストにはHTTPクライアントの文言「error sending request」が維持されます(0.156より前のビルドではURLも追加されます)。一般的なresponse.failedイベントでは、コロンの後にサーバーのメッセージが置かれます。Codex 0.148以降、そもそも接続を開けない場合(DNS、TLS、拒否されたポート)は別のエラー「Connection failed」として報告されます。現在のビルドでは、ネットワークを待機しながら再試行が継続されます。

what each reason means
stream closed before response.completed  the connection ended with no terminal event:
                                         network path, server, or a provider that
                                         never sends response.completed
idle timeout waiting for SSE             no event for stream_idle_timeout_ms
error sending request                    the request broke on the wire: a reset, a
                                         proxy or a middlebox (before 0.148, also
                                         a connection that never opened)
…error decoding response body            the body broke mid-read: network or middlebox
An error occurred while processing…      the server's own response.failed message
Incomplete response returned, reason: …  the server stopped it: a token cap, a content
                                         filter, or whatever the reason names

Codexがすでに再試行する対象を把握し、プロバイダーごとに調整する

適用される再試行予算は2つあります。request_max_retries(デフォルト4)はストリームが存在する前のHTTPリクエストを対象とし、Codexはそこで5xxレスポンスとトランスポートエラーを再試行しますが、429は再試行しません。stream_max_retries(デフォルト5)はこのページのすべてを対象とします。各再試行ではターンが再送信されます。これは「Reconnecting... 1/5」が数えているものです。予算を使い切ると、エラーが画面に残り、ターンは停止します。どちらも最大100に制限され、[model_providers.<id>]ブロック内にあります。組み込みのopenaiプロバイダーIDは予約されており再定義できないため、これらはカスタムプロバイダー用の設定です。

~/.codex/config.toml
model = "gpt-5-6-sol"
model_provider = "kunavo"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"
# wire_api defaults to "responses", the only supported value
stream_max_retries = 10          # dropped or failed streams (default 5, max 100)
request_max_retries = 4          # 5xx and network errors before streaming (default 4, max 100)
stream_idle_timeout_ms = 300000  # silence before giving up (default 300000)

Codexなしでストリームを再現する

Responsesストリームは1つの終端イベントで終了し、Codexはそれがresponse.completedであることを必要とします。同じ種類のリクエストを同じマシンからcurlで送信してください。Codexが切断され続ける一方で毎回完了するなら、Codexのビルドと未解決の問題を確認します。curlも失敗するなら、プロバイダーを疑う前に別のネットワークから繰り返してください。失敗の発生時点を記録します。毎回同じ経過時間で切断されるなら、ネットワークの不安定さではなく、経路上のどこかのタイマーを示しています。

reproduce.sh
curl -sN https://api.kunavo.com/v1/responses \
  -H "Authorization: Bearer $KUNAVO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-5-6-sol","stream":true,
       "input":"Write a 600-word story about a lighthouse keeper."}' \
  | grep -oE '"type": ?"response\.(completed|failed|incomplete)"'
# a healthy run prints exactly one line: "type":"response.completed"

ネットワーク経路を切り分けてから、プロバイダーを確認する

結論を出す前に、2つ目のネットワークからテストしてください。OpenAIのフォーラムでは、あるユーザーの職場マシンで発生していたエラーが、会社のZscalerを無効にした瞬間に止まりました。GPT-5.6のスレッドでは、あるユーザーのエラーはVPNまたはスマートフォンのホットスポットで解消しましたが、別のユーザーのエラーはネットワークを切り替えても続きました。別のネットワークで直るなら、タイムアウトを延長するのではなく、プロキシまたはTLS検査からAPIホストを除外してください。カスタムプロバイダーでは、codex doctorが設定の読み込み状況と、プロバイダーのキー変数が存在するかを報告します。プロバイダーはResponses APIを提供する必要があります。wire_apiには他の値がなく、Responses WebSocketトランスポートを実行する場合を除き、supports_websocketsは未設定のままにしてください。curlが正常に完了し、Codexだけが失敗する場合は、openai/codexの問題 #41340または#41989に再現結果を追加してください。これらは、Codex外では正常にストリーミングするカスタムResponsesプロバイダーに対してこのエラーを報告しており、2026年9月23日時点で未解決でした。

Kunavo経由で呼び出している場合

Kunavo経由では、GPTモデルの/v1/responsesストリームは上流自身のイベントストリームであり、フレームごとに中継されます。書き換えられるのはモデルIDだけで、Kunavoはキープアライブイベントを追加しません。最初の出力イベントが到着するまで、最大30秒間ストリームは保留されます。そのため、その段階で上流がエラー、タイムアウト、または切断した場合、設定されていればモデルの次のチャネルで再試行できます。どのチャネルも処理しなければ、CodexはストリームではなくHTTPエラーを受け取ります。上流がエラーを返した、応答しなかった、またはKunavo自身のキーを拒否した場合は502となり、原因はJSONのcodeに入り、upstream_524やupstream_403などになります(他の上流4xxは独自のステータスを保持します)。Codexはこれをこのメッセージではなく「unexpected status 502 Bad Gateway: Upstream provider error」と表示し、同様に再試行します。最初の出力イベント後は、出力を重複させずに再試行できません。上流のresponse.failedは送信済みとしてそのまま通過するため、CodexはOpenAIから直接受け取った場合と同様に処理します(一般的な失敗ではコロンの後にメッセージを表示します)。上流接続が回答途中で切断すると、Kunavoのストリームは終端イベントなしで終了し、Codexはstream closed before response.completedと報告します。いずれの場合も、その後はCodex自身の再試行が引き継ぎます。Kunavo側で、流れ続けるストリームに上限を設けるものはありません。240秒の制限は上流ヘッダーを待つ時間だけを対象とします。ただし無通信は終了させます。Kunavoは300秒間何も送信しない上流の読み取りを停止します。これはCodexのアイドルデフォルトと同じです。また、600秒間バイトを送らない接続はエッジが閉じます。これらの各失敗は、費用ゼロとして記録されます。 上で調整したプロバイダーブロックは、次の場所に設定されています Codex CLI統合ページ.

よくある質問

「stream closed before response.completed」とはどういう意味ですか?

HTTPレスポンスは開始しましたが、その後、Codexが待機しているresponse.completedイベントなしに接続が終了しました。プロキシやファイアウォール、サーバー、またはそのイベントを送信しないカスタムエンドポイントのいずれかが、接続を早期に閉じました。

Codexは「stream disconnected before completion」を自動的に再試行しますか?

はい。Codexはstream_max_retries回(デフォルト5回、最大100回)までターンを再送信し、その間「Reconnecting... 1/5」と表示します。予算を使い切ると、エラーが画面に残ってターンが停止します。別のメッセージを送ると新しいリクエストが開始されます。

stream_idle_timeout_msを増やすべきですか?

理由が「idle timeout waiting for SSE」で、無通信が正当な場合に限って増やしてください。「stream closed before response.completed」では接続が閉じており、無通信になったわけではないため何も変わりません。Kunavo経由では、ストリーム開始後に300000を超える値を設定しても意味がありません。Kunavoは300秒間何も送信しない上流の読み取りを停止し、ストリームを終了します。

Codexが「Incomplete response returned, reason: max_output_tokens」と表示するのはなぜですか?

サーバーがトークン上限でレスポンスを停止し、response.incompleteイベントでそのことを伝えました。Codexは同じエラーの下でこれを報告し、再試行します。同じターンを再試行しても通常は同じ上限に達するため、タスクを分割するか、より大きな出力上限を持つモデルを使用してください。Kunavo経由では、Claudeモデルの最大トークンによる停止も同じ方法でCodexに届きます。

再試行にも課金されますか?

再試行はそれぞれ新しいリクエストです。Kunavo経由では、上流で失敗したGPT呼び出し(ストリーミング前のエラー、response.failed、接続切断)は費用ゼロとして記録されます。上流が処理を続けている間にCodexが諦めた試行については、上流が生成したと報告する分が課金されます。その作業は実行済みだからです。

関連ガイド

エラーの詳しい意味はエラーリファレンスをご覧ください。キーは新規登録と認証ガイドから1分で取得できます。