1 Codex CLI が踏む典型経路
多くのチームで最初に行うのは npm install -g @openai/codex のようなグローバル導入です。ここで触れるのは公開 npm registry（代表例として registry.npmjs.org）と、その周辺に現れる tarball 配信ホストです。次に CLI の初回起動では、ブラウザを介した OpenAI アカウント連携やトークン取得のため、openai.com 配下や chatgpt.com、api.openai.com に代表される API エンドポイントへのアウトバウンドが続きます。さらに隔離実行やツールチェーン拡張を有効にすると、Docker Hub（docker.io／registry-1.docker.io など）や ghcr.io といったコンテナレジストリへ docker pull が走るケースが増えます。
つまり「ChatGPT がブラウザで開ければよい」と「Codex CLI が最後まで自律的に動く」は別レイヤの話で、前者だけを ChatGPT／OpenAI 記事でカバーしても、後者には npm registry と Docker Hub の束が抜けがちです。逆に MCP と npm／GitHub の専文だけでは、OpenAI API の長めのセッションや公式サンドボックスイメージの取得経路まで踏み込めません。本稿はその中間に位置づけます。
2 npm と @openai/codex
npm registry 向けルールは、npmjs.org と npmjs.com を広めに DOMAIN-SUFFIX で束ねるのが無難です。registry.npmjs.org だけを購読リストに書いても tarball 取得で別ホストがログに出ることがあるため、接続ログの SNI を正に足していく運用が安全です。社内で Verdaccio などのミラーを使う場合は、そのミラーホストを意図的に DIRECT に落とし、公開 registry だけをプロキシへ載せる二段構えにすると切り分けが容易です。
corepack や pnpm、企業プロキシ経由の npm では追加のホスト名が出ます。詰まったら「パッケージ名が Codex だから」ではなく、取得 URL のホストをルールに反映してください。Rule Provider に codex-dev-net.yaml のような短いファイルを切り出しておくと、CLI のバージョンアップに伴う周辺ホストの増減だけを差分レビューできます。
3 初回ログインと OpenAI 系ドメイン
初回ログインはデバイスフローやブラウザリダイレクトを含み、短時間に複数ホストへ飛びます。実務では openai.com、auth.openai.com、platform.openai.com、ブラウザ体験と重なる chatgpt.com／chat.openai.com、証明書検証や静的資産に関わる oaiusercontent.com などがログに並ぶことがあります。ここをバラバラのプロキシノードに分散させると、Cookie や TLS セッションの観点で不安定になるので、同一セレクタ（例：OPENAI_PROXY）へ寄せる設計が読みやすいです。
4 OpenAI API と長めのセッション
Codex CLI の本体動作は OpenAI API への HTTPS を長時間維持しがちです。api.openai.com を含む openai.com 系をまとめて扱い、MATCH より上かつ誤爆しやすい DOMAIN-KEYWORD より下に置くと、他ベンダーの生成 AI ルールと衝突しにくいです。ストリーミング応答では中間装置のタイムアウトが効きやすいので、企業プロキシの前段で CLI だけ別出口にする、といったセレクタ分離も検討対象です。
DNS 側で期待と異なる IP が返ると、ルール上は正しく見えても実パケットがズレます。FakeIP と DoH の組み合わせを使う場合は、ターミナル・Docker デーモン・ブラウザが同じリゾルバ経路を見ているかを先に揃えるとよいです。
5 サンドボックスイメージと Docker Hub
隔離実行を有効にすると、CLI または裏側のランタイムが Docker Hub や GitHub Container Registry（ghcr.io）からサンドボックスイメージを取得します。Docker エコシステムでは docker.io、registry-1.docker.io、認証系の auth.docker.io、CDN 周りのホスト名がログに現れます。これらを OpenAI 用ルールとは別ファイルの Rule Provider（例：container-registries.yaml）に分離しておくと、「モデル通信は落ちないのに pull だけ遅い」といった非対称な症状の切り分けが速くなります。
ローカルで Docker Desktop を動かしている場合、docker pull はホスト OS のルーティングと DNS に従います。WSL2 バックエンドなら Linux 側の resolv.conf と Windows 側の Clash が二重化しがちなので、WSL2 と Clash の記事と合わせて読むと理解が揃います。
6 MCP・追加レジストリとの棲み分け
Codex CLI から MCP サーバを追加すると、再び npm registry や github.com 系オブジェクト配信へ戻ることがあります。この層は MCP 専文の DOMAIN-SUFFIX 束とほぼ同型です。運用上は「OpenAI 束」「コンテナレジストリ束」「パッケージ／Git 束」を三つの Rule Provider に分け、rules では RULE-SET の並べ順だけを議論する方が、レビューとロールバックが楽です。
7 企業 VPN とローカル Docker の併用
企業 VPN がデフォルトルートを握る環境では、Clash の TUN と競合しやすいです。スプリットトンネルで社内 CIDR を VPN へ、開発者向けドメインを Clash 側へ、と書き分けるか、VPN クライアントの「全トラフィック代理」を見直す必要があります。詳細は 企業 VPN と Clash を参照してください。
Docker と Clash を同じマシンで動かすときは、(1) デーモンが参照する DNS、(2) HTTP(S)_PROXY をコンテナ build に渡すか、(3) 逆プロキシでレジストリをミラーするか、の三点が衝突点になります。Codex のサンドボックスが「ホストの Docker をそのまま使う」タイプなら、ホスト側の Clash 分流を先に安定させるのが近道です。
8 YAML 断片と Rule Provider
以下は Mihomo／Clash Meta 互換の rules に追記するイメージです。DEV_OPENAI は手元のプロキシグループ名に置換し、MATCH より上に配置してください。コメントは英語のみとします。
# Place ABOVE MATCH. Replace DEV_OPENAI. Extend from your live connection logs.
rules:
# npm ecosystem (global install @openai/codex)
- DOMAIN-SUFFIX,npmjs.org,DEV_OPENAI
- DOMAIN-SUFFIX,npmjs.com,DEV_OPENAI
# OpenAI auth + API + web overlap (verify hostnames in logs)
- DOMAIN-SUFFIX,openai.com,DEV_OPENAI
- DOMAIN-SUFFIX,chatgpt.com,DEV_OPENAI
- DOMAIN-SUFFIX,oaiusercontent.com,DEV_OPENAI
# Common container pulls for sandbox / isolation images
- DOMAIN-SUFFIX,docker.io,DEV_OPENAI
- DOMAIN-SUFFIX,docker.com,DEV_OPENAI
- DOMAIN-SUFFIX,ghcr.io,DEV_OPENAI
# rule-providers sketch (split files in production):
# rule-providers:
# codex-openai:
# type: http
# behavior: classical
# url: "https://example.com/rules/codex-openai.yaml"
# path: ./rules/codex-openai.yaml
# interval: 86400
# rules:
# - RULE-SET,codex-openai,DEV_OPENAI
GitHub 由来のツールや MCP を同じマシンで使うなら、github.com と objects.githubusercontent.com など既存の開発者ネット束を同じグループへ載せるか、別 RULE-SET にして順序だけ調整してください。
9 トラブルシューティング
npm install -g @openai/codexが tarball で止まる： registry 以外のホストが別ルールに滑っていないか確認。npmjs.org系の束を広げる。- ログインだけ失敗する： ブラウザと同じホスト群が CLI からも通るか。システムプロキシとターミナルの環境変数の差を疑う。
- API は通るがサンドボックス起動が遅い：
docker.io／registry-1.docker.ioが直連のまま詰まっていないか。Docker 側の DNS を確認。 - VPN 接続中だけ不安定： デフォルトルート優先とスプリット設定を見直す。
- TUN 有効時のみ再現： TUN モードの除外リストと、Docker の仮想ブリッジの干渉を確認。
10 まとめ
OpenAI Codex CLI は @openai/codex の取得から OpenAI API セッション、任意の MCP、Docker Hub などのサンドボックスイメージまでが連続するため、単一ドメインのルールでは足りません。Clash 分流では DOMAIN-SUFFIX で束ね、Rule Provider にファイル分割してチーム共有すると、再現性とレビュー性が上がります。ChatGPT 一般論と MCP 専文のあいだを埋める用途で本稿を位置づけています。
Mihomo 互換スタックは DNS とルールを一体で扱えるため、ターミナルエージェントのように長時間セッションとレジストリ取得が混ざるワークロードに向いています。ログを正にホストを足し続ける運用が、CLI のマイナーアップデートにも耐える近道です。
出口の一貫性を先に取り戻せば、Codex 側の設定トラブルとネットワーク起因の切り分けが格段に楽になります。短い YAML 断片を版管理し、セレクタ名だけチームで揃えるだけでも効果があります。
→ 無料で Clash をダウンロードし、Codex CLI の npm・OpenAI・Docker 経路を同じ分流で安定させる
