目次
短いプロンプトでも再接続する場合は、まず問題を接続経路に絞る
本稿では、Codex App または CLI で簡単なプロンプトを送信した後、画面に Reconnecting 1/5 から 5/5 まで順に表示され、最後に stream disconnected before completion となるケースを扱います。OpenAI の公式 issue #23061 にも同じエラー経路が記録されており、原因が必ずしもプロンプト、リポジトリのサイズ、コンテキスト長にあるわけではないことが分かります。
Codex の通常の HTTPS リクエストが成功しても、ストリーミング応答が安定するとは限りません。OpenAI のネットワークドキュメントによると、Codex は wss://chatgpt.com/ への安全な WebSocket 接続も確立します。アプリケーションのプロキシ接続、Clash のルール、ノードの出口、長時間接続ポリシーのどこか一つでも、応答が中断される可能性があります。
まず比較結果に応じて分類する
| 症状 | 可能性の高い切断箇所 | 次に確認すること |
|---|---|---|
| OpenAI のステータスページでも同時に障害が報告されている | サーバー側のインシデント | 復旧を待ってから再テストする |
| App は失敗するが、同じネットワークの CLI は利用できる | 二つのインターフェースでプロキシへの接続方法が異なる | バージョンと起動方法を比較する |
| 短い応答は成功するが、長い応答では途中で再接続する | WebSocket またはプロキシの長時間接続が早期に閉じられている | 443、TLS、タイムアウトを確認する |
| App と CLI のどちらも Clash の接続ページに表示されない | リクエストが現在のプロキシ入口へ入っていない | システムプロキシ、TUN、ポートを確認する |
- Codex App または CLIログイン、HTTPS、ストリーミングの各リクエストを送信する
- システムプロキシ、環境変数、TUN のいずれかリクエストが Clash へ入るかを決める
- Clash のルールとノードchatgpt.com に実際の出口を割り当てる
- OpenAI WebSocketポート 443 でモデルのストリーミング接続を維持する
短いリクエストは成功する一方、応答の途中で再接続を繰り返す場合、切断箇所はプロンプト自体ではなく、アプリケーションからプロキシへの接続、ルールに基づく送信、WebSocket の長時間接続のいずれかにあることが一般的です。
ステータスページと別のネットワークで、共通障害を切り分ける
まず status.openai.com で、対応中の ChatGPT または Codex のインシデントがないか確認します。ステータスページに明確な障害がある場合は、エラーの発生時刻を記録して復旧を待ってください。この段階で多数のノードを切り替えたり、ルールを書き換えたりすると、元の比較条件が崩れます。
ステータスページが正常な場合は、同じ短いプロンプトとアカウントに固定し、現在の Clash ノード、動作確認済みの別ノード、モバイルホットスポット、または企業ゲートウェイを通らないネットワークでそれぞれテストします。ネットワークを変えるとすぐに復旧するなら、Codex のタスクを削除するのではなく、ローカルプロキシまたは社内ネットワークの確認を続けてください。
再現可能な三つの比較条件を用意する
正確なエラーを記録する
Reconnecting の回数、失敗した URL、発生時刻、Codex App と CLI のバージョンを保存します。タスクの内容やトークンは公開しないでください。
最小限のリクエストに固定する
新しいタスクで同じ短いプロンプトを送信し、長いコンテキスト、ツール呼び出し、リポジトリのスキャンがネットワークの判断に影響しないようにします。
出口は一度に一つだけ変更する
まず動作確認済みの Clash ノードに一つ切り替え、次にモバイルホットスポットへ切り替えます。そのたびに同じエラーが表示されるか確認してください。
元のノードへ戻す
比較が終わったら元のポリシーグループへ戻し、後の結果が未記録の新しい出口によるものにならないようにします。
Clash の接続ページで、Codex の通信が実際にプロキシへ入っていることを確認する
Clash Verge Rev の接続ページを開いて以前のフィルターを消去し、Codex から新しいプロンプトを一度送信します。chatgpt.com と関連する OpenAI ドメインを重点的に探し、一致したルール、ポリシーグループ、実際のノードを記録してください。ブラウザのトラフィックだけが見えても、Codex App または CLI が同じ経路を使用した証拠にはなりません。
通常は引き続き Rule モードを使用してください。ルール漏れの有無を判断するため、一時的に Global へ切り替え、同じノードに固定して再テストできます。Global では復旧し、Rule では失敗する場合、リクエストは Clash に入っており、問題はルールまたはポリシーの選択にあります。Codex の変更を続ける必要はありません。テスト後は直ちに元のモードへ戻してください。
Codex のリクエストが表示され、想定したノードを通っている
プロキシ入口には接続できています。WebSocket、TLS 検査、長時間接続のタイムアウトを続けて確認してください。
リクエストは表示されるが DIRECT に一致する
一時的に Global で比較してから、接続記録に基づいて説明可能なルールを追加する
Codex の新しい接続がまったく表示されない
システムプロキシがこのプロセスで読み込まれていないか、CLI が現在のターミナルのプロキシ環境変数を継承していない可能性があります。
すべてのドメインで継続して timeout になる
まずノードまたはネットワークを変更し、上流全体の障害を Codex 固有の問題として扱わないでください。
App と CLI を個別にテストし、同一プロセスとして扱わない
Codex の公式トラブルシューティングでは、デスクトップ App と CLI に異なるバージョンが含まれる可能性があると説明されています。まず両方のバージョンを記録し、同じネットワークとノードで同じ短いプロンプトを送信してください。App は成功して CLI が失敗する場合も、その逆の場合も、アカウントと OpenAI のサービスだけが変数ではないことを示します。
codex --version
/Applications/Codex.app/Contents/Resources/codex --versionバージョンと結果の読み取り方
| 比較条件 | 判定内容 | 次の手順 |
|---|---|---|
| App と CLI のバージョンが異なる | 先に古いほうを更新してから再テストする | ノードとプロンプトを変えない |
| CLI は利用できるが、App は再接続を繰り返す | App がターミナルの環境変数を引き継いでいない可能性がある | TUN またはシステムプロキシで個別に比較する |
| App は利用できるが、CLI は再接続を繰り返す | 現在の shell のプロキシ環境変数または起動環境に異常がある | 環境変数と実際の HTTP ポートを確認する |
| 両方とも同じ段階で失敗する | 共通するノード、ルール、WebSocket の問題である可能性が高い | ネットワーク制御の確認を続ける |
Codex の WebSocket がポート 443 で接続を維持できるようにする
OpenAI の公式ネットワーク推奨事項では、プロキシ、ファイアウォール、セキュリティゲートウェイで、chatgpt.com が TCP 443 上の標準的な Upgrade: websocket ハンドシェイクを完了できるようにする必要があります。Web ページとログインは利用できるのに、応答が生成途中で常に切断される場合は、ネットワーク管理者に WebSocket のアイドルタイムアウト、最大メッセージサイズ、長時間接続を早期に閉じていないかを確認してもらってください。
企業ネットワークで TLS 検査が有効な場合は、不正な証明書への置き換え、ハンドシェイクの書き換え、通常の HTTPS だけを許可する制限がないことも確認します。最も有効な比較方法は、同じアカウントと同じ Codex バージョンをモバイルホットスポットで使用することです。ホットスポットでは安定し、社内ネットワークで失敗することを確認してから、ネットワークポリシーの担当者へ問題を渡してください。
管理者へ依頼する最小限の確認項目
- chatgpt.com の TCP 443 と WebSocket Upgrade を許可する
- 長時間接続が短すぎる idle timeout によって早期に閉じられない
- TLS 検査の信頼チェーンが HTTPS、ログイン、安全な WebSocket で一貫している
- 公式に列挙された ChatGPT、OpenAI、静的リソースのドメインが書き換えられていない
- モバイルホットスポットとの比較により、アカウント、プロンプト、ローカルのバージョンに起因する問題を除外できている
現在のターミナルだけで Clash の HTTP プロキシ入口をテストする
OpenAI Codex issue #20844 は、現在も未解決のユーザー報告です。同じプロキシスタックで SOCKS5 を使用すると stream disconnected が発生し、明示的な HTTP_PROXY と HTTPS_PROXY に変更すると復旧したと報告されています。これは公式に保証された汎用的な修正ではありませんが、SOCKS 経路と HTTP 経路で動作が異なるかを判断する材料になります。
まず Clash Verge Rev の設定で HTTP または Mixed ポートを確認します。以下の 7897 は例にすぎないため、ローカルで実際に使用しているポートへ置き換えてください。環境変数は現在のターミナルだけに設定し、最初から shell の設定やシステム環境へ追加しないでください。
export HTTP_PROXY=http://127.0.0.1:7897
export HTTPS_PROXY=http://127.0.0.1:7897
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
unset ALL_PROXY all_proxy
codex$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:HTTPS_PROXY="http://127.0.0.1:7897"
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
codexCLI がすぐに安定し、接続ページに chatgpt.com が表示される
そのターミナルを一時的な作業経路として残し、App の通信を TUN で処理する必要があるか、引き続き確認します。
HTTP は利用できるが、SOCKS5 ではストリームが引き続き切断される
検証済みの HTTP または Mixed 入口を優先し、該当する公式 issue の今後の修正を確認してください。
どちらのプロキシも失敗するが、モバイルホットスポットでは正常に動作する
Clash のノード、ルール、WebSocket の転送を確認し、環境変数をシステムへ恒久的に書き込まないでください。
新しいプロセスも接続ページに表示されない
ポートが誤っているか、コマンドを同じターミナルから起動していない可能性があります。プロセスを終了し、設定を確認してから再試行してください。
一時的な環境変数を解除し、最後に四項目のストリーミング検証を行う
テストで効果がなかった場合や、システムプロキシへ戻す場合は、まず今回起動した Codex を終了し、現在のターミナルを閉じれば一時的な環境変数を解除できます。環境変数を shell の設定または Windows のユーザー環境へ書き込んだ場合は、今回追加した項目を削除して新しいターミナルを開いてください。古い SOCKS、HTTP、TUN という三つの不明な経路を同時に残さないでください。
App が TUN 使用時だけ安定する場合は、まずロールバック可能な一時的接続方法として使い、TUN を無効にすればシステムプロキシへ戻せる基準状態を残します。今後 Codex または Clash Verge Rev を更新した際に、同じチェックリストで再テストしてから、TUN を維持するか判断してください。
最終確認リスト
- App と CLI から短いプロンプトを一度ずつ送信しても、Reconnecting のカウントに入らない
- やや長い応答を最後まで生成しても、stream disconnected before completion が表示されない
- Clash の接続ページで、chatgpt.com が想定したルールと固定ノードに一致している
- Codex を終了して一時プロキシを無効にすると、システムネットワークが元の状態へ戻る