· reAPI Team
stream disconnected before completion: stream closed before response.completed
Codex が完了イベントを受理しないまま応答ストリームの終端に達した状態です。再試行前にエラー全文、終端イベント、タイムアウト、エンドポイントの仕様を確認します。
「stream disconnected before completion: stream closed before response.completed」は、Codex が完了イベントを正常に受け取らないまま応答ストリームの終端に達したことを示します。 処理が止まった位置は分かりますが、原因となった機器までは特定できません。2026年10月22日に確認した Codex の SSE 実装では、このメッセージはストリーム終了時のフォールバックです。通信エラー、アイドルタイムアウト、先に届いたサーバーエラーには別の処理経路があります。[1]
設定を変える前に、エラーメッセージの末尾まで確認してください。早期終了にはイベント記録、アイドルタイムアウトには時間の記録、レート制限には制限対象の情報が必要です。reAPI を検討する場合は、まず GPT-6 Astra のリクエスト仕様を確認してください。このページが説明するのは Chat Completions です。そのリクエストが成功しても、Codex が使う Responses プロトコルとの互換性は証明されません。[2][3]
最初に確認すること
- 再試行前に、エラー全文、クライアントのバージョン、時刻、リクエスト ID を保存します。共有する報告から認証情報と非公開のプロンプトを除いてください。
- 早期終了では、受信した SSE データに有効で受理された終端イベントがあるか確認します。HTTP の成功や表示済みの文章だけでは判断できません。[1]
idle timeout waiting for SSEではイベント間隔を測ります。アイドル待機時間は、HTTP リクエストやストリームの再試行回数とは別の設定です。[2]- 一時的なレート制限では、サービスの再試行指示に従い、該当する負荷を減らします。クォータや請求の問題なら、アカウント側の対応が必要です。[4]
stream disconnected before completion: stream closed before response.completed
ソースコードから言えることは「インターネットが壊れた」より具体的で、範囲も限定されています。SSE ループはイベントを読み、JSON をデシリアライズして Responses ハンドラーに渡します。ハンドラーが完了応答を返せば、ループは正常終了します。先に入力が終わった場合は、保存済みの応答エラーを優先し、それがなければ closed-stream メッセージを返します。[1]
記録を読む際は、次の違いが役立ちます。
| 観測内容 | 確認できること | 次の確認 |
|---|---|---|
| 文章が届いた後にストリームが終了 | 一部の出力はクライアントに届いた | 終端イベントとその JSON 本体を探す |
| HTTP は成功したが完了が受理されない | HTTP 層ではリクエストが成功した | タスク完了と判断せず、イベント列を確認する |
| 完了らしいペイロードがある | 完了に似たバイト列は届いた | イベント型、必須フィールド、利用中バージョンのパーサーを確認する |
| EOF より前にサーバーの失敗が記録された | サービスがエラーを返した | 接続終了を別のネットワーク障害と決めつけず、そのエラーを調べる |
これはパーサーを読んだ結果であり、reAPI の実呼び出し結果ではありません。本文は不変のソースリビジョン c2d5ea52 を参照しています。インストール済みのクライアントと比較し、すべての Codex バージョンで同じ動作だと仮定しないためです。[1]
不正なデータは個別に確認してください。このリビジョンでは、最初の JSON デシリアライズに失敗したイベントをログに残してスキップします。一方、完了イベントと認識されても内部の応答オブジェクトが不正なら、別のエラー経路に進みます。ログに response.completed という文字列があっても、Codex が受理した証拠にはなりません。また、ストリームが閉じたという事実だけでは、サーバーが完了イベントを送らなかったとも断定できません。送信記録と受信記録を比較します。[1]
独自エンドポイントでは、再試行を増やす前に対応プロトコルを確認してください。現在の設定リファレンスは wire_api の対応値を responses とし、WebSocket 対応を別の provider 能力として扱っています。OpenAI 形式の Chat Completions JSON を受け付けることだけでは、Responses エンドポイントとして動作する証明になりません。[2]
再現確認は小さく始めます。まずテキストだけのリクエスト、次に同じ内容のストリーミング、最後に元の失敗を起こしたツール操作を試します。エンドポイント、キー、モデルを固定し、各段階の変化を記録してください。これは診断方法であり、すべてのサービスが三つのテストをサポートする保証ではありません。料金が発生する場合は、そのアカウントで許可されたテストだけを実行します。
stream disconnected before completion: transport error: network error: error decoding response body
この検索語は、通信または応答本文の読み取りに関する失敗を表します。Codex の SSE リーダーは、次の有効なイベントが届く前に、入力イベントストリームのエラーを受け取ることがあります。前節の正常な終端到達とは別の分岐です。[1]
各コンポーネントは調査対象であり、確認済みの原因ではありません。最終エンドポイントのホスト、クライアントのバージョン、分かる範囲の HTTP ステータス、経過時間、イベントを一つでも受信したかを記録します。その後、許可された別のネットワーク経路や、問題のクライアント以外からの同一エンドポイントへの接続など、一度に一つの条件だけ変えて比較してください。ブラウザーでサイトが開けても、失敗した認証付きストリームを検証したことにはなりません。
OpenAI の接続エラーガイドは、ネットワーク設定、プロキシ、SSL 証明書、ファイアウォールを確認するよう案内しています。これは確認項目であり、利用環境のエラー原因を直接特定するものではありません。[5] 証明書検証は有効のままにします。組織管理のネットワークでは、無関係な回避策を流用せず、承認済みの設定を使ってください。
ゲートウェイ運営者への報告には、機密情報を除いたリクエスト構造と、最後に受信したイベント型を添えます。「disconnected」だけの画像では、必要な区別が失われます。完全な記録は手元に保存し、共有版には認証ヘッダー、非公開の入力、ツール出力を含めないでください。
stream disconnected before completion: idle timeout waiting for sse
アイドルタイムアウトは、次の SSE イベントを待つ時間が設定値を超えたことを意味します。応答全体が長いこととは異なります。イベントを送り続ける長時間の応答と、無音のストリームでは時間のパターンが違います。[1]
2026年10月22日に確認した設定リファレンスでは、次の項目を区別しています。[2]
| Provider 設定 | 文書上の対象 |
|---|---|
stream_idle_timeout_ms | SSE イベントのアイドル待機時間。単位はミリ秒 |
stream_max_retries | SSE 中断に対する再試行回数 |
request_max_retries | provider への HTTP リクエストの再試行回数 |
アイドル間隔を延ばすと、クライアントが長く待つようになります。非互換のエンドポイントに Responses イベントを生成させたり、失われたバイトを復元したりする効果はありません。再試行回数を増やしても、最初の失敗原因は変わりません。
変更前に、応答開始、各イベントの到着、エラー報告の時刻を測定してください。クライアントのタイムアウトが実際の境界なら、サービスの仕様と照らして設定を見直します。それより早く接続が閉じるなら、その終了を調べます。一度の失敗から、すべてのモデル、ネットワーク、ゲートウェイに同じタイムアウトを当てはめないでください。
rate limit exceeded: upstream rate limit exceeded, please retry later
このメッセージはリクエスト経路のどこかで制限がかかったことを示しますが、文字列だけではアカウント、制限対象、リセット時刻は分かりません。「upstream」から特定の供給元を推測したり、チャージすれば必ず解決すると考えたりしないでください。
OpenAI の直接 API 文書は、リクエスト数、トークン数、一時的な過負荷、クォータや支出制限を区別します。レート制限のレスポンスヘッダーを示し、一時的な条件で提供される Retry-After は最短待機時間だと説明しています。アカウント対応が必要な問題は再試行では解決しません。[4] これは OpenAI の仕様です。実際には呼び出しているエンドポイントの文書とヘッダーを確認してください。
| 実際のエンドポイントから得られた情報 | 対応 |
|---|---|
| 再試行指示付きの一時的な制限 | 指定時間以上待ち、上限のある方針で再試行する |
| リクエスト数の上限に到達 | 同じ制限を共有する worker 全体のリクエスト頻度を下げる |
| トークン数の上限に到達 | リクエスト数に加えてトークン需要を見直す |
| クォータ、請求、支出上限の問題 | 負荷を再投入する前にアカウントの条件を解決する |
| 制限対象が分からない一般的なエラー | リクエスト ID を保存し、運営者に制約を確認する |
適切な待機指示がない場合、OpenAI はランダム性を加えた指数バックオフを推奨し、失敗したリクエストも制限に算入されると説明しています。アプリ側に再試行を加える前に、SDK の再試行も数に含めてください。[4] 停止条件を決め、一つの拒否されたタスクが無限の新規リクエストを生まないようにします。
エージェントのタスクでは、すでに起きた操作も確認します。中断した処理を繰り返させる前に、作業ツリーの diff とツール履歴を見てください。最後の応答の失敗は、それ以前の全ツール操作の失敗を意味しません。これは重複作業を避ける運用上の助言であり、Codex が外部操作を自動で取り消せるという意味ではありません。
Why does my Codex stream disconnect before completion and the stream closed before the response is completed?
確認した SSE 経路では、完了を正常に返せず、より具体的な保存済みエラーもない状態で入力の終端に達しています。終端イベントが欠けたのか、不正だったのか、途中で失われたのかを、受信記録とサービス側の記録で確認します。このメッセージだけでは原因を選べません。[1]
Why does Codex keep disconnecting?
再現可能な比較が必要です。バージョン、モデル、エンドポイントを固定し、エラー全文を保存して一条件ずつ変更します。まず早期終了、通信失敗、アイドルタイムアウト、サービスによる拒否を区別してください。それ以前に再試行を増やしても、新しい証拠なしで同じ失敗を繰り返すことがあります。
codex request timed out
どのコンポーネントがタイムアウトを報告したか確認します。Codex provider 設定には SSE アイドル間隔があり、API クライアントにもリクエストタイムアウトがあります。OpenAI はネットワークやサーバー側の調査項目を案内していますが、タイムアウトを単一原因の証拠とはしていません。[2][5]
resume stream unavailable
必ず応答を再開できるという意味でも、完了済みの作業をすべて失った証拠でもありません。バージョンとエラー全文を記録し、会話を保存して完了済みのツール操作を確認します。今回確認した資料には、この文字列に対する万能な復旧コマンドがないため、本文でも提示しません。
モデルやエンドポイントを切り替える場合は、GPT-6 Astra 移行ガイドでモデル検出、プロトコル変更、ツール検証を分けて確認できます。モデルページには現在の reAPI 提供内容があります。モデル名や価格表示は、Codex の一連の動作を実際に検証する代わりにはなりません。
資料確認日：2026年10月22日
- OpenAI。Codex Responses SSE 実装、リビジョン
c2d5ea52e1b7ab11ee2d71dc44ea1ef00f9c8eb3。ソースと付属テスト。 - OpenAI。Configuration Reference、provider のプロトコル、タイムアウト、再試行。設定リファレンス。
- reAPI。GPT-6 Astra リクエスト仕様。公開仕様。ローカルの実装文書を確認しており、実生成テストではありません。
- OpenAI。Rate limits、レスポンスヘッダーと再試行。API レート制限。
- OpenAI。Error codes、API 接続とタイムアウト。API エラーガイド。