ブラウザや Copilot 拡張と違う「Codex CLI が壊れる」理由

ブラウザ版の ChatGPT は macOS／Windows のシステムプロキシを尊重しやすく、タブ内の認証フローも同じ経路に乗りがちです。一方、OpenAI Codex CLI のようにシェルから起動するツールは、親プロセスの環境変数、コンテナ／WSL／リモート SSH、CI ジョブなどコンテキストが分かれた瞬間にプロキシ設定が継承されない場面が少なくありません。ここで Clash が TUN により内核側から覆う場合と、単に mixed-port に環境変数で向けるだけの場合では、出口の一貫性がまったく違います。

Visual Studio Code の GitHub Copilot 拡張は、多くのケースで Microsoft と GitHub の名前空間へ寄ります。Codex CLI は OpenAI の認証と API、チャット UI が絡むホストまで踏むため、既存の Copilot 向けルールをそのまま流用しても片側しか通らないことがあります。症状が「ログ全体が真っ黒なタイムアウト」に見えるのは、実際には複数ホストのどれか一つが別経路で止まっているだけ、というパターンが多いです。

まず Clash のライブ接続で、失敗ウィンドウの数十秒だけ SNI と選択ポリシーを並べてください。api.openai.com だけ赤字なのか、auth.openai.com や platform.openai.com 系と交互に落ちるのか、oaistatic.com だけ遅いのかをメモすると、認証・API・CDN のどれが経路だけ割れているかがはっきりします。サービス側の恒久障害を疑う前に、この階層分けの方がコストが低いことが多く、チーム内の再現ログ共有にも向きます。

ℹ 観測のコツ：問題が出ているターミナルから短いウィンドウだけ計測し、成功している別シェルと環境変数の差分を並べます。ALL_PROXY と NO_PROXY にローカル例外が紛れていないか、企業プロキシ PAC がターミナルにだけ効いていないかも合わせて見ます。

ターミナルが踏むレイヤー：認証・API・chatgpt.com・静的 CDN

実運用でまとめやすい層は次のとおりです。(1) アカウントとトークン——ブラウザへ飛ぶ OAuth／デバイスフロー、auth.openai.com や platform.openai.com などログイン周辺の名前。バージョンやツールの実装によりホストは変わるため、自分のログを正にします。(2) モデル応答と課金まわりの API——多くが api.openai.com を軸に、プロジェクト設定により別の OpenAI 管理ホストが増えることもあります。(3) チャット UI とヘルプ——chatgpt.com や openai.com 配下の読み込みが挟まると、ブラウザと CLI で見え方が似通います。(4) 静的 CDN——oaistatic.com のようにスクリプトやアセットを配る名前空間。ここが直結やブロックリスト誤爆で遅れると、画面は中途半端に出るのに裏の API だけタイムアウトと誤解されやすいです。

「API だけタイムアウト」は層 (2) が別出口にいる典型ですが、(1)(3)(4) のどれかが先に詰まっていると、(2) に到達する前に長い待ちに見えます。逆に (2) だけ通っていても、CLI の内蔵ブラウザやコールバック URL が (1) で止まれば完了しません。ひとつの安定した出口を OpenAI 関連の束に割り当て、必要なら DOMAIN 行で絞り込むと読みやすいです。

YAML での概念的な束ね方（例）

ポリシー名は自分の構成に置き換えてください。断片は出発点であり、丸写しではありません。増えた名前はログで足し、範囲が広すぎると国内向け一般サイトまで巻き込みます。

Illustrative rules fragment — verify against your logs

rules:
  - DOMAIN-SUFFIX,openai.com,OPENAI_CLI_STABLE
  - DOMAIN-SUFFIX,chatgpt.com,OPENAI_CLI_STABLE
  - DOMAIN-SUFFIX,oaistatic.com,OPENAI_CLI_STABLE
  - DOMAIN,api.openai.com,OPENAI_CLI_STABLE
  - MATCH,YOUR_FALLBACK_POLICY

DOMAIN-SUFFIX,openai.com は範囲が広いため、開始時は DOMAIN 中心にしてから徐々に拡張する運用が安全です。リストの並べ替えと更新の型は ルール分流のベストプラクティス を参照してください。許可されていないサービスへの迂回には使わないでください。

DOMAIN-SUFFIX とルール順：MATCH より上で揃える

Clash は一行目から順に評価し、最初に当たった行で出口が決まります。広告ブロック用ルールや大きな拒否リスト、広すぎる GEOIP が OpenAI 系ホストを先に片付けていたり、CDN を誤って直結／拒否していたりすると、ブラウザだけ別プロファイルで結果だけ見えている状態になります。開発者向けブロックセットを入れているプロファイルほど、この誤遮蔽を疑う価値があります。

「昨日まで Codex CLI が動いた」なら、(a) ルールプロバイダの自動更新で順序が変わった、(b) 更新取得自体がプロキシループで詰まり古いリストのまま、(c) サブスクリプション更新後にノード品質だけが劣化——の三通りを順に見ます。購読とノード保守 と タイムアウトと TLS の読み方 をセットにすると切り分けが速くなります。

システムプロキシ／TUN／HTTPS_PROXY の取りこぼし

開発者環境では、ブラウザ用に Clash のシステムプロキシをオンにしている一方、ターミナルだけ HTTPS_PROXY を設定していなかった、WSL／Docker だけ別ブリッジにいる——といったパターンが珍しくありません。Docker／ターミナル向け記事 の構成と突き合わせ、すべてのプロセスが同じ Clash アップストリームに到達できるかを確認してください。

TUN はPOSIX 環境への注入漏れを減らす一方、企業 VPN やホスト側の複数 NIC と競合することがあります。TUN の深掘り を読み、「システムプロキシに切り替えるとだけ直る」のか、「TUN が必要なのか」を短時間で A/B します。両方を同時に誤って二重に載せないよう注意してください。

DNS・fake-ip が原因の「名前は返るが止まる」

fake-ip を使っていると、アプリには合成アドレスが返り実解決は後段になります。このとき DOMAIN 規則と DNS の順序理解が食い違うと、名前解決は一瞬でも TCP が進まず API タイムアウト にしか見えません。CLI はブラウザよりキャッシュ層が薄く、結果としてログに残るほうが素直です。

社内ネットワークで分割 DNS を使っていると、公開向けとは別のアドレスに誘導され、認証だけ失敗することがあります。IT の案内がある場合は順守しつつ、「家のクリーンな回線では再現しない」事実だけでも切り分け材料になります。一般的な確認は FAQ も参照してください。

ChatGPT のブラウザ向け記事 は UI 読み込み中心ですが、本稿はターミナルで動く Codex CLI と認証連鎖に焦点を当てます。GitHub Copilot／Microsoft 名前空間の記事 は IDE 拡張の典型経路であり、OpenAI ホスト束とはルール設計が一致しません。Cursor のログイン記事 のように「開発者ツールのタイムアウト」でも、ベンダーごとに並ぶホストが違うため、単純な丸写しは通用しません。Gemini CLI の CDN 分流記事 と考え方は似ていますが、Google と OpenAI で名前空間が別です。自分が触っているスタックに合った記事だけを精読し、他は辞書程度の参照にとどめると安全です。

⚠ コンプライアンス：サービス規約や法的制限、アクセス許可されていない環境での利用を前提にした迂回は説明対象ではありません。職場のセキュリティ方針に従ってください。

許可環境でのチェックリスト

  1. この CLI と Clash で OpenAI に接続することが契約およびポリシー上許されているか確認した。
  2. 失敗ウィンドウの接続ログから、認証・api・chatgpt・oaistatic に分類してホスト名を列挙した。
  3. それらが広域ブロックリストより上の行へ載っていることを確認した。
  4. ブラウザとターミナルで HTTPS_PROXY／TUN／システムプロキシの差を A/B した。
  5. fake-ip 利用時は nameserver と DOMAIN 規則の整合を読み直した。
  6. 購読とルール更新がループせず成功することをログで確認した。
  7. 問題が残るときだけノード総入れ替えやベンダーダウン確認に進んだ。

メモだけで済ませず、設定ファイルの変更点を短文で残すと数日後の自分が助かります。チームで展開する場合も同様で、レビュアが「どのサフィックスをいつ足したか」を追えると再現切り分けが速くなります。

よくある質問

簡単な質疑を並べました。FAQPage の構造化データは <head> にあります。

ブラウザの ChatGPT は動くのに OpenAI Codex CLI だけ止まりますがなぜですか。

ブラウザはシステムプロキシを尊重しやすく、CLI は環境変数やカーネル捕捉に依存しがちです。api.openai.com と chatgpt.com および oaistatic.com など静的 CDN が別出口に割れると、片方だけタイムアウトに見えます。

GitHub Copilot 拡張の記事と何が違いますか。

Copilot は Microsoft／GitHub の名前空間中心のことが多く、Codex CLI は OpenAI の認証と API、チャット UI が絡むホストまで踏みます。ホストの束ね方は別設計にします。

oaistatic.com は DIRECT の方が速いですか。

地域や ISP で差があります。静的ホストだけ止まるなら API と同じ出口へ寄せ、DNS と証明書の整合を優先すると再現しにくいことが多いです。

api.openai.com だけを DOMAIN で書き分けたいです。

ログに基づき DOMAIN から始め、増えたサフィックスを徐々に DOMAIN-SUFFIX へ拡張するのが安全です。openai.com 全体を広く巻き込むと無関係なページまで同じポリシーになります。

まとめ

OpenAI Codex CLI は単一ホストとの会話というより、認証・API・チャット UI・静的 CDN の短い連鎖です。MATCH まで届いているか、認証と API と CDN が同じ出口か、DNS がルール設計と同じ視点か——この三通りを押さえると、ノード性能やベンダ障害を疑うより先に体感が変わることがあります。2026 年もエンドポイントは増減するため、黒箱の単一プリセットよりログを読んで増分更新するモデルのほうが持続します。

一部の単一チャネル VPN やブランド固定クライアントは、どの名前が増えたか観測しづらく、開発者がターミナルで待たされる原因を特定しにくい面があります。Clash はドメインベースでルールプロバイダを差し替えやすく、上流リストが不透明でも自分で順序と例外を足せます。この透明性があるからこそ、許可環境でのセルフサービスにも向きます。

Clash V.CORE はその設計語彙に沿って UI とログを並べやすく、「CLI のどのフェーズが詰まっているか」を短いセッションで切り分けやすいです。黒箱より出口とログが追える構成に寄せると、同僚との再現議論も早くなります。Clash を無料ダウンロードし、自分のワークステーションだけで検証するところから始めてください。認証だけ別経路だった、という発見はすぐログに現れます。