Codex「Reconnecting...」が続く原因と対処｜stream disconnected before completion

Reconnecting... 2/5
Reconnecting... waiting for network
Falling back from WebSockets to HTTPS transport.
stream disconnected before completion: idle timeout waiting for SSE

「Reconnecting...」は、Codex が OpenAI のサーバーとのつながりを失い、自動でつながり直しを試している表示です。 数秒で消えて作業が続くなら、何もしなくてかまいません。続くときは、表示の形で原因の場所が分かります。Reconnecting... 2/5 のように数字が付くなら「つながった後に途中で切れた」「時間切れ」などの一時的な失敗なので最大5回まで送り直し、waiting for network なら「そもそも接続できない」ので、つながるまで待ち続けます。送り直しても失敗すると、最後のエラー（多いのは stream disconnected before completion: と理由）が表示されて止まります。

まずは OpenAI の稼働状況を確かめ、障害が出ていなければ、自分のネットワーク（VPN・社内プロキシ・証明書）と、Codex の設定に残った別の接続先を疑います。

本記事の情報について：2026年10月29日時点の openai/codex のソース（Codex CLI 0.166.0 公開後の main。再接続の処理は responses_retry.rs、エラー文は error.rs）、GitHub のリリースノート、公式の設定リファレンス、GitHub の利用者報告にもとづいています。手元の Codex CLI 0.160.0 の実行ファイルにも同じ表示文が入っていることを確かめました。エラーを意図的に起こして再現したものではありません。公式の記載・ソースから読み取れること・利用者の報告は書き分けています。

状況別の読み分け早見表

意味：Codex が自動でつながり直している表示

「Reconnecting...」は失敗ではなく、Codex がサーバーとのつながり直しを自動で試している途中の表示です。 Codex は、モデルの応答を一度に受け取るのではなく、少しずつ流れてくる形（ストリーミング）で受け取ります。この流れが途中で途切れたり、そもそも接続できなかったりすると、Codex はそのリクエストを自動で送り直し、その間ステータスの行にこの表示を出します。CLI の画面では、表示のすぐ下に切れた理由（例：stream disconnected before completion: … や Connection failed: …）が小さく添えられます。

表示は4種類あり、どれが出たかで、Codex がいまどの段階にいるかが分かります。いずれも openai/codex のソースにある文言です。

「Reconnecting...」が数回出て消え、作業が普通に続いたなら、一時的な切断が自動で直ったということです。この場合、何かを設定し直す必要はありません。

切れ方で、再接続のしかたが2通りに分かれる

Codex は、「そもそも接続できない」のか「つながった後に途中で切れた」のかで、送り直しの回数と待ち時間を変えています。 2026年10月29日時点のソース（responses_retry.rs）を読むと、流れは下の図のとおりです。

そもそも接続できない：上限なしで待ち続ける

サーバーへの接続そのものができないときは、Reconnecting... waiting for network を出し、回数の上限なしで待ち続けます。 待ち時間は5秒から始まって倍々に延び、最長で60秒ごとになります（5秒→10秒→20秒→40秒→60秒→60秒…）。回線が戻れば、そのまま作業が再開します。Wi-Fi の切り替えやパソコンのスリープ復帰のような、少し待てば戻る切断で作業を失わないための動きです。

この表示のすぐ下には、たいてい Connection failed: error sending request … のような理由が添えられます。「接続できない」の中身は、パソコンがオフラインになっている、VPN がつなぎ直している最中、社内のファイアウォールが通信先を止めている、名前の解決（DNS）に失敗している、設定ファイルに書いた接続先のプロキシが動いていない、などさまざまです。どれも Codex の側からは区別できないため、まとめて「ネットワークを待つ」扱いになります。Codex が勝手に諦めないぶん、原因を取り除くのは利用者の仕事になる、という点を覚えておくと迷いません。

この動きは unbounded_connection_retries という機能で、既定で有効です。リリースノートによると、0.148.0（2026年8月）でオン・オフを設定できるようになりました（#38601）。

裏返すと、ネットワークが戻らない限り、この表示は何分でも何時間でも続きます。 対話の画面では、Esc で今のターンを止められます。スクリプトでの扱いは後の節で説明します。

つながった後に途中で切れた：最大5回、だめなら HTTPS で5回

接続はできたのに応答が途中で途切れたときは、Reconnecting... N/5 を出しながら最大5回まで送り直します。 ソースでは、応答の途中切断のほか、時間切れ（request timed out）や OpenAI 側の一時的なサーバーエラーも、こちらの「最大5回」の扱いです。上限なしで待ち続けるのは、接続の段階で失敗したと判定されたときだけです。待ち時間は 0.2秒から倍々（0.2秒→0.4秒→0.8秒→1.6秒→3.2秒、それぞれ前後10％の揺らぎあり）なので、待ち時間だけなら5回分を合わせても10秒足らずです。ただし、応答が届かないまま待つ場合は、1回ごとに打ち切りまで最長5分（後述）かかります。サーバーが「何秒後に送り直して」と指定してきた場合は、その時刻まで待ちます（0.158.0〜0.162.0 のリリースで順に対応。0.161.0 のリリースノートなど）。

OpenAI のサーバーとの通信には、既定で WebSocket という方式が使われます。WebSocket で5回送り直しても失敗すると、Codex は Falling back from WebSockets to HTTPS transport. と表示して通信方式を HTTPS に切り替え、回数を数え直して、もう一度最大5回送り直します。最初から HTTPS で通信している場合（WebSocket を使わない接続先を設定しているときなど）は、切り替えずにそこで止まります。

送り直しの上限の5回は、設定ファイルの stream_max_retries の既定値です（設定リファレンス）。ただしこれは model_providers.<名前> の中で使う項目で、ChatGPT のアカウントでサインインして使う標準の接続先（組み込みの openai）の値は変えられません。ソースでは、組み込みの接続先を上書きしようとすると「Built-in providers cannot be overridden」というエラーになります。ふつうに使っている限り、回数を増やして解決する方法はないと考えてください。

「1/5」が出ずに「2/5」から始まる理由

WebSocket で通信しているときは、1回目の送り直しの表示をわざと出さない作りになっています。 ソースのコメントには、一時的な再接続の表示がうるさくならないよう、正式版では WebSocket の最初の送り直しを表示しない、と書かれています。そのため、WebSocket で通信しているときは、画面には Reconnecting... 2/5 から出ることがあります。

逆に、Reconnecting... 1/5 から表示されるのは、HTTPS で通信しているときです。Reconnecting... 2/5 から 5/5 まで進んだあとに Falling back from WebSockets to HTTPS transport. が出て、続いて Reconnecting... 1/5 が表示されたなら、HTTPS に切り替えた後の送り直しが始まったということです。なお、この表示の出し分けは2026年10月29日時点のソースで確かめたもので、古い版やデスクトップアプリでは 1/5 から表示されている報告もあります（#23061・#46148）。

表示の流れから、どこで止まったかを読む

ここまでの仕組みを使うと、画面に出た表示の並びから、いまどの段階にいるのかを読み取れます。よくある3つの流れを並べます。

流れ1：一時的な切断が自動で直った

Reconnecting... 2/5
（表示が消え、作業がそのまま続く）

WebSocket の送り直しが1〜2回で成功した状態です。何もしなくてかまいません。

流れ2：送り直しを使い切って止まった

Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5
Falling back from WebSockets to HTTPS transport.
Reconnecting... 1/5
…
Reconnecting... 5/5
stream disconnected before completion: （理由）

WebSocket で5回、HTTPS でさらに5回送り直しても応答を最後まで受け取れなかった状態です。短い時間のうちに10回以上続けて失敗しているので、一瞬の切断ではありません。最後の行の理由を、次の節の表で読みます。OpenAI 側の障害か、途中の機器が通信を止めている可能性が高いです。

流れ3：接続そのものができない

Reconnecting... waiting for network
（数字が増えないまま、何分も同じ表示）

サーバーに届いていない状態です。数字が出ないのは、回数を数えずに待ち続けているからです。オフライン・VPN・ファイアウォール・DNS・設定ファイルに残った接続先を疑います。

stream disconnected before completion の理由の読み方

stream disconnected before completion: の後ろには、切れた理由が英語で付きます。この理由を読めば、どこで切れたかの当たりが付きます。 ソースの説明では、このエラーは「接続の確立（ハンドシェイク）は成功したが、応答の完了の合図が届く前に流れが切れた」ときのもので、Codex は一時的なエラーとして送り直しの対象にしています。

最後の content_filter だけは、通信の問題ではありません。リリースノートによると、0.160.0 から、Codex はこの場合にモデルへ立て直し方の案内を添えて送り直すようになっています（#49119）。それでも止まるなら、指示や読み込ませた内容に、安全フィルターに触れやすいものが含まれていないかを見直します。

「5分」という待ち時間は、設定リファレンスに載っている stream_idle_timeout_ms の既定値（300000ミリ秒）です。設定リファレンスでは HTTPS（SSE）の項目として説明されていますが、ソースでは WebSocket の待ち時間にも同じ値が使われています。これも stream_max_retries と同じく接続先ごとの項目なので、組み込みの openai では変えられません。

まずやること

上から順に試します。1つ目で直ることも多いので、いきなり設定を触らないのがコツです。

1. 数十秒待つ。進まなければ Esc で止める

Reconnecting... N/5 は、待ち時間だけなら10秒足らずで結果が出ます（応答が届かないまま待つ場合は1回ごとに最長5分）。waiting for network は回線が戻れば再開します。1分待っても同じ表示のままなら、Esc でターンを止めて、次の確認に進みます。

2. OpenAI の稼働状況を確かめる

status.openai.com で、Codex や ChatGPT に障害が出ていないかを見ます。障害中なら、手元で何をしても直りません。復旧を待ってから同じ指示を送り直します。websocket closed by server before response.completed や、同じ時間帯に多くの人が同じ表示を報告している場合は、まずここを疑います。

3. ネットワークを切り替えて試す

別の回線で直るなら、原因は今のネットワークの中にあります。 VPN をいったん切る、会社の回線ならスマートフォンのテザリングで試す、Wi-Fi を有線に替える、といった切り替えで、手元側か OpenAI 側かを切り分けられます。結果の読み方は次のとおりです。テザリングでは出ないなら、会社や自宅のネットワーク（VPN・プロキシ・ファイアウォール）が原因です。テザリングでも同じように出るなら、OpenAI 側か、パソコンの中の設定（Codex の設定ファイル・セキュリティソフト）を疑います。

GitHub の報告（#13245）でも、OpenAI の担当者は「ログを見る限り基本的な接続の問題に見える。VPN やプロキシでよく見かける」と答えています。

4. Codex を最新版にする

再接続まわりは、ここ数か月のリリースで細かい修正が続いています。codex --version で版を確かめ、古ければ更新します。更新のしかたは入れ方によって違うので、Codex のインストール方法の「更新のしかた」を参照してください。ChatGPT デスクトップアプリや IDE 拡張で使っている場合は、アプリや拡張そのものを更新します。

5. codex doctor --network-only で接続まわりを診断する

Codex CLI 0.166.0（2026年10月29日 UTC 公開）からは、codex doctor --network-only で設定と接続まわりだけを調べられます（リリースノート）。codex doctor --help の説明では、調べるのは設定、ネットワーク環境、接続先への HTTP、そして WebSocket の接続です。

codex doctor --network-only

WebSocket の項目だけが失敗するなら、通信の途中で WebSocket が遮られている可能性が高く、Codex が HTTPS への切り替えを繰り返す原因になります。実行結果の見方はインストール記事の該当節にまとめています。

6. 作業の途中経過を確かめてから、もう一度送る

stream disconnected before completion で止まったとき、それまでに実行したファイルの編集やコマンドの結果は残っています。 失われるのは、途中で切れた最後の応答だけです。git diff で実際の変更を確かめてから、「途中で切れたので続けてください」のように送り直すと、二重に編集させずに済みます。

会社のネットワーク（プロキシ・VPN）で出るとき

会社や特定の VPN の下でだけ出る、毎回出る、という場合は、Codex の通信が途中の機器で止められていると考えます。 確認するのは、プロキシの設定、証明書、WebSocket の扱いの3点です。

プロキシを使う会社では HTTPS_PROXY を設定する

Codex の通信は、標準では HTTPS_PROXY などの環境変数に書いたプロキシを通ります。社内プロキシを通さないと外に出られないネットワークなら、Codex を起動する前に設定します。

export HTTPS_PROXY="http://proxy.example.co.jp:8080"
codex

どのプロキシを使えばよいか分からないときは、ブラウザが使っている設定を見ます。macOS なら「システム設定」→「ネットワーク」→使っている接続の「詳細」→「プロキシ」、Windows なら「設定」→「ネットワークとインターネット」→「プロキシ」で確かめられます。「自動設定スクリプト」の欄にアドレスが入っている場合は、次の respect_system_proxy を使うか、使うべきプロキシのアドレスをネットワーク担当者に確かめます。

macOS と Windows では、OS のプロキシ設定（自動設定スクリプトの PAC や、自動検出の WPAD を含む）を Codex に使わせる試験中の機能 respect_system_proxy もあります。ソースの説明では、有効にすると OS の設定を先に見て、次に環境変数、どちらも無ければ直接つなぎます。/experimental の画面で「System proxy」を選ぶか、設定ファイルに次のように書き、Codex を起動し直します。

# ~/.codex/config.toml
[features]
respect_system_proxy = true

Windows で、プロキシが社員の Windows アカウントによる認証（Negotiate・NTLM）を求める環境は、0.164.0 から Codex が自動で応じるようになりました（リリースノート）。それより古い版で、ブラウザは通るのに Codex だけつながらないなら、まず更新します。

通信を検査するプロキシなら、社内の証明書を渡す

通信の中身を検査するために証明書を差し替えるプロキシ（TLS 検査）の下では、社内の証明書を Codex に教えないと接続に失敗します。 Codex は、環境変数 CODEX_CA_CERTIFICATE（無ければ SSL_CERT_FILE）に書いた PEM 形式の証明書ファイルを、HTTPS と WebSocket の両方の通信で使います（ソースの custom_ca.rs）。

export CODEX_CA_CERTIFICATE="$HOME/certs/company-root-ca.pem"
codex

証明書ファイルの形式が正しくないと、Codex は「CODEX_CA_CERTIFICATE か SSL_CERT_FILE を設定しているなら、CERTIFICATE ブロックを含む PEM ファイルを指しているか確かめる。そうでなければ設定を外して OS の証明書を使う」という趣旨のエラーを出して止まります。証明書ファイルは社内の情報システム部門から受け取ってください。

ネットワーク担当者に伝えること

自分で直せないときは、次の内容をそのまま伝えると話が早く進みます。

• 接続先：Codex は ChatGPT のアカウントでサインインしている場合、chatgpt.com の /backend-api/codex あてに、API キーで使っている場合は api.openai.com の /v1 あてに通信する（ソースにある組み込みの接続先）。ここへの HTTPS と WebSocket（wss://）の通信を許可してほしい
• WebSocket を途中で切らない：応答は WebSocket で少しずつ流れてくる。プロキシやセキュリティ製品が WebSocket を止めたり閉じたりすると、Codex は送り直しと HTTPS への切り替えを繰り返す
• 応答を溜めない：応答のデータが5分届かないと Codex は通信を打ち切る。プロキシで応答を最後まで溜めてから返す設定になっていないか見てほしい
• 証明書を差し替えている場合：社内のルート証明書を PEM 形式で配布してほしい（利用者側で CODEX_CA_CERTIFICATE に設定する）

診断の結果を担当者に渡すときは、codex doctor --network-only --json を使うと、機密を伏せた形式で出力できます（codex doctor --help の説明）。画面の写真よりも、どの項目で失敗しているかが正確に伝わります。

設定に残った別の接続先を確かめる

以前ほかのツールで試したプロキシや「ルーター」の設定が Codex の設定ファイルに残っていると、そこへ通信しようとして再接続を繰り返します。 ~/.codex/config.toml を開き、次の項目が意図せず残っていないかを確かめます。

Reconnecting... waiting for network が続くという GitHub の報告（#46148）でも、Codex の設定に残っていた別のプロキシの設定を消したら直った、という人や、以前入れたルーター系ツールの設定ごと .codex フォルダを消し、環境変数 CODEX_CA_CERTIFICATE・SSL_CERT_FILE も外したら直った、という人がいます。使っていない証明書の環境変数が残っていないかも、あわせて確かめてください。これらは個別の報告で公式の案内ではありませんが、設定を見直すだけで確かめられるので、早めに試す価値があります。設定ファイルの場所と読み込みの順番は、Codex の config.toml の書き方で詳しく説明しています。

なお、公式の高度な設定の説明によると、プロジェクトの中に置いた .codex/config.toml では openai_base_url や model_provider は無視されます。見るべきなのは、ホームフォルダの ~/.codex/config.toml です。

codex exec や CI で止まらないようにする

「そもそも接続できない」ときの待ち続ける動きは、人がいない自動実行では、終わらないジョブになりかねません。 codex exec を夜間のスクリプトや GitHub Actions で回している場合は、次の2つを入れておくと安心です。

1. ジョブそのものに時間の上限を付ける（GitHub Actions なら timeout-minutes）
2. 接続できないときにすぐ失敗させたいなら、待ち続ける機能を切る

# ~/.codex/config.toml（自動実行用の環境だけ）
[features]
unbounded_connection_retries = false

ソースを読むと、この機能を切った場合、接続できない失敗も Reconnecting... N/5 と同じ「最大5回」の扱いになり、使い切ると止まります。対話で使うパソコンでは、Wi-Fi の切り替えなどで作業を失わないよう、既定のまま（有効）にしておくのが無難です。GitHub Actions で Codex を動かす具体的な組み方は、Codex CLI と GitHub Actions の自動化で解説しています。

CLI・IDE 拡張・デスクトップアプリでの違い

同じ表示は、CLI だけでなく ChatGPT デスクトップアプリでも報告されています（#46148・#23061）。VS Code などの IDE 拡張での出方は公式の資料では確かめられていませんが、対処の考え方は同じです。使える道具が少し違います。

デスクトップアプリで出る場合、ブラウザの chatgpt.com では普通に使えるかを確かめると切り分けになります。ブラウザでも同じなら OpenAI 側かネットワーク側、ブラウザでは動くならアプリの版か、アプリが使う設定を疑います。

再接続が続くときに、やらないほうがいいこと

焦って次のような操作をすると、かえって状況が悪くなることがあります。

• ログアウトしてサインインし直す：ネットワークが原因のままだと、サインインのための通信も通らず、入り直せなくなります（下の利用者の報告を参照）。サインインの問題を疑うのは、ネットワークが正常だと確かめてからです
• 同じ指示を何度も送り直す：途中までのファイル編集は残っているので、確かめずに同じ指示を送ると、同じ変更を二重に加えさせることがあります。先に git diff で状態を確かめます
• 設定ファイルを丸ごと消す：原因と関係のない設定（承認の方法やサンドボックスの設定など）まで失います。疑わしい項目（openai_base_url・model_provider など）だけを外して試し、直ったらその項目を見直します
• Codex を何個も入れ直す：入れ方を変えて入れ直すと、PATH 上に古い codex が残って、更新したはずの版が使われないことがあります。入れ直す前に、上の手順で原因がネットワーク側かどうかを切り分けます

毎回出るときの確認チェックリスト

数日にわたって何度も出る場合は、次の項目を上から確かめると、抜けなく原因を絞り込めます。

• status.openai.com に、同じ時間帯の障害が出ていない
• 別の回線（テザリングなど）では出ない、または同じように出るかを確かめた
• codex --version で最新版を使っている（デスクトップアプリ・IDE 拡張も更新した）
• codex doctor --network-only で、WebSocket を含めて失敗している項目が無い
• 社内プロキシが必要なネットワークで、HTTPS_PROXY か respect_system_proxy を設定した
• 通信を検査するプロキシの下で、CODEX_CA_CERTIFICATE に社内の証明書を設定した
• ~/.codex/config.toml に、使っていないプロキシやルーターの openai_base_url・model_provider が残っていない
• 自動実行のジョブには時間の上限を付けた

ここまで確かめても直らなければ、Codex の不具合や OpenAI 側の問題の可能性があります。/feedback でログを送り、同じ症状の issue が GitHub に無いかを探します。

公式には未確認の報告

GitHub には、次のような利用者の報告もあります。公式ドキュメントやソースで確認できた内容ではないので、参考として扱ってください。

• モデルを変えたら動いた：同じ環境で、特定のモデルだけ stream disconnected before completion が続き、別のモデルに替えたら動いたという声が複数あります（#13245。しばらくしか効かなかったという声もあります）。ネットワークを一通り確かめても直らないときは、/model で別のモデルを選んで試す価値があります
• ログアウトし直すと、かえって入れなくなった：接続の問題が残ったままログアウトしたため、Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token) が出てサインインし直せなくなった、という報告があります（#13245）。ネットワークが原因のうちは、ログアウトしないほうが安全です
• Tailscale などの VPN を使っていると、1時間に1回ほど出る：常時接続の VPN で、ときどき切れるという報告です（#13245）

自分の環境を一通り確かめても直らず、別の回線でも同じなら、Codex CLI の /feedback でログを OpenAI に送れます。GitHub の issue でも、担当者は送られたログを見て原因を判断しています。

似ているが別のエラー

文言が違う場合は、ネットワークではない原因のことが多いです。いずれも openai/codex のソースにある文言で、送り直しの扱いもソースで確かめました。

見分けるポイントは、止まったときの最後の文言です。使用量・支払い・会話の長さの文言なら、送り直さずにすぐ止まるのでネットワークの問題ではありません。request timed out や high demand は「Reconnecting...」の後に出ることがあり、ネットワークか OpenAI 側の一時的な問題として、稼働状況と回線を確かめます。

よくある質問

まとめ

• 「Reconnecting...」は、Codex が OpenAI のサーバーとのつながり直しを自動で試している表示。数秒で消えれば対処は要らない
• Reconnecting... N/5 は「つながった後に途中で切れた」。最大5回送り直し、WebSocket ならさらに HTTPS に切り替えて最大5回。使い切ると最後のエラー（多いのは stream disconnected before completion: と理由）を出して止まる
• Reconnecting... waiting for network は「そもそも接続できない」。5秒〜60秒の間隔で、上限なく待ち続ける。自動実行では時間の上限を付けるか、unbounded_connection_retries を切る
• 対処の順番は、稼働状況の確認 → 別の回線で試す → 最新版に更新 → codex doctor --network-only → プロキシ・証明書・残った接続先の設定の確認
• 回数は組み込みの接続先では変えられない。ネットワーク側と設定側の原因を取り除くのが近道

参考：

• https://github.com/openai/codex/blob/main/codex-rs/core/src/responses_retry.rs
• https://github.com/openai/codex/blob/main/codex-rs/protocol/src/error.rs
• https://github.com/openai/codex/releases
• https://learn.chatgpt.com/docs/config-file/config-reference
• https://learn.chatgpt.com/docs/config-file/config-advanced
• https://status.openai.com