社内プロキシ環境でCodex CLIを使う：PAC/WPAD・CA証明書・HTTPS_PROXY（2026年版）

ノートPCのブラウザではChatGPTが開けるのに、codex は最初のリクエストで何も起きずに止まったまま——そんなとき、ネットワークが壊れているわけでもCodexが壊れているわけでもありません。 Codex CLIはブラウザのようにPACファイルを読んだりWPADを検出したりしないため、Webは問題なく閲覧できるマシンでも codex が最初のリクエストでハングすることがあります。このガイドは、その反応しないターミナルから動くエージェントまで導き、なぜ2026年になっても手動の HTTPS_PROXY が解決策なのかを説明します。

30秒でわかる結論

作業全体は4つの動きです。PACが指し示す実際のプロキシを見つける、HTTPS_PROXY/HTTP_PROXY/NO_PROXY をエクスポートする、CODEX_CA_CERTIFICATE でCodexに社内CAを渡す、そして RUST_LOG=debug で検証する。このページの残りは、それぞれの動きの背後にある詳細と、途中でぶつかるエラーの解説です。

このセットアップ後にできること（とできないこと）

作業を終えると、Codexはブラウザと同じプロキシ経由でAPI呼び出しを送り、TLSインスペクションを行う中継装置を通過し、内部Gitサーバーやパッケージレジストリではプロキシをスキップするようになります。これで、ロックダウンされた企業ネットワークの大多数をカバーできます。

ただしCodexがブラウザになるわけではありません。CodexはPACスクリプトを解析せず、WPADのブロードキャストに応答せず、SOCKS5上でも安定してストリーミングしません。セキュリティチームがグループポリシーとPAC URL経由でしかプロキシ設定を配布しないなら、それを環境変数に翻訳するのはあなた自身の役目です。この翻訳こそが実際の作業であり、「とにかくHTTPS_PROXYを設定しろ」で終わる回答が飛ばしている部分です。

判断の枠組み：このセットアップを使うべきとき（と使うべきでないとき）

使うべきとき

• 組織がPAC/WPADやグループポリシーでプロキシ設定を配布しており、CLIツールは自分で何とかしなければならない。
• プロキシがTLSインスペクションを行っており、システムの信頼ストアに入っていないツールから証明書エラーが出る。
• 同じプロキシを使う開発者が5人以上おり、全員が推測で設定する代わりに、共有された文書化済みの設定を1つ持ちたい。

使うべきでないとき

• プロキシが一切ない自宅やカフェのネットワークにいる。HTTPS_PROXY を存在しないアドレスに設定してもCodexが壊れるだけです。設定を解除してください。
• プロキシが透過型（クライアント設定なしでネットワーク層でインターセプトする）である。この場合、設定すべきものは何もなく、手動のプロキシ変数はリクエストを二重プロキシしてしまう可能性があります。
• 変えたいのはAPIキーやエンドポイントだけである。それはプロキシのプロジェクトではなく、1行の config.toml 編集です。後述の応用セクションに進んでください。

プロキシの値そのものについては、明確な打ち切りルールがあります。curl -x http://your-proxy:port https://api.openai.com/v1/models がハングせずにHTTPステータスを返すなら、プロキシアドレスは正しく、それ以上の調整は不要です。それ以降のすべては、別々の修正方法を持つ別々の問題である、CA信頼と認証の話になります。

なぜCodexはPAC/WPADプロキシを無視するのか

Codexは、ブラウザのプロキシスタックではなくプロキシ環境変数だけを理解するHTTPクライアント上に構築されたCLIであるため、PACとWPADを無視します。この1つの設計上の事実が混乱の大半を生むので、正確に押さえておく価値があります。

PACファイル（Proxy Auto-Config）は、FindProxyForURL(url, host) 関数を持つ小さなJavaScriptプログラムです。ブラウザはリクエストごとにこの関数を実行し、PROXY proxy.corp.example.com:8080 や DIRECT といった答えを受け取ります。WPAD（Web Proxy Auto-Discovery）は、そのPACファイルの場所をブラウザに伝えるプロトコルで、通常はDHCPオプションや wpad.<yourdomain> のDNSレコードを介します。ブラウザ、Officeアプリ、Windowsのネットワークスタックはすべてこれを話します。PyPACプロジェクトのPACファイル概説 によれば、コマンドラインツールでこれを話すものはほとんどありません。

CodexのHTTPクライアントは HTTPS_PROXY、HTTP_PROXY、ALL_PROXY、NO_PROXY を尊重します。これはcurl、git、そしてほとんどの言語ランタイムが共有する標準的なUnixの慣習です。すべてのCodex HTTPクライアントに一貫してプロキシ環境変数を尊重させるオープンな要望 もありますが、Codex 0.142.x の時点では、これらの変数を自分で設定するのがサポートされた経路です。したがって、ブラウザで機能するチェーン（WPADがPACを見つけ、PACがプロキシを返し、ブラウザがそれを使う）に相当するものがCodexの内部には存在しません。HTTPS_PROXY が設定されていないと、Codexは直接接続を試み、ファイアウォールがそれを破棄し、きれいなエラーの代わりにハングが返ってきます。この黙った破棄こそ、実際には翻訳ステップが欠けているだけなのに、これがCodexのバグのように見える理由です。

2つの検出経路を並べて見ると理解しやすくなります。ブラウザは起動時に、管理者がグループポリシーで配布したPAC URLを読むか、あるいはDHCPとDNS上でWPADクエリをブロードキャストして探すかのどちらかを行います。その後、URLごとに FindProxyForURL を実行するため、ホストによって異なる答えを得られます。イントラネットは DIRECT を、公開インターネットは PROXY を返す、というように。Codexはそのどれもしません。起動時に一度、環境から4つの文字列を読み、セッション全体にそれを適用します。ホストごとのスクリプトも、自動検出のブロードキャストも、再評価もありません。だから「他のツールは動く」ことはCodexも動く証拠にはなりません。あなたの他のツールはほぼ確実に、PACファイルではなく、これから設定するのと同じ環境変数を読んでいるのです。

システム要件

プロキシ設定に手を付ける前に、基本を確認してください。プロキシは、無関係なインストールの問題を平気で覆い隠してしまうからです。

• 正しいパッケージでインストールされた Codex CLI。npm install -g @openai/codex。npm上のスコープなしの codex は別のプロジェクトであり、それをインストールすることが、後で command not found や不可解な挙動が現れる最もよくある原因です。
• npmインストール経路には Node.js 16以上（@openai/codex は engines: node >=16 を宣言しています）。古いNodeは、ネットワークにたどり着く前にインストールで失敗します。
• プロキシのエンドポイント を host:port の形で。PAC URLしかない場合は、次のステップで解決します。
• プロキシがTLSインスペクションを行う場合は、PEM形式の 社内ルートCA。プラットフォームチームに「ルートCAバンドル」を尋ねるか、システムのキーチェーンからエクスポートしてください。

ステップバイステップ：Codexを社内プロキシに向ける

これらを順番に進めてください。各ステップには、次に進む前に確認できるチェックが付いています。

ステップ1：ブラウザは動くがCodexは動かないことを確認する

ブラウザでAPIホストを開いて読み込まれるのを確認し、次にターミナルから素のリクエストを実行します。

# In a browser: https://api.openai.com/v1/models loads (401 JSON is fine)
# In the terminal, this should hang or fail fast if there's a proxy:
curl -sS --max-time 10 https://api.openai.com/v1/models ; echo "exit=$?"

ブラウザがホストに到達し、curl がタイムアウトするなら、典型的なPACのみのセットアップです。そのギャップがまさに問題の全体であり、次のステップがそれを埋めます。

ステップ2：PACファイルを解決して実際のプロキシを見つける

APIホストに対してPACが返す実際の host:port が必要です。macOSでは自動設定URLを読み、それをテストします。pactester は pacparser パッケージに付属しています。

# macOS: find the PAC URL your system is configured with
scutil --proxy | grep -i ProxyAutoConfig
# Download it and ask which proxy serves the API host
curl -s "$PAC_URL" -o wpad.dat
pactester -p wpad.dat -u https://api.openai.com
# → PROXY proxy.corp.example.com:8080; DIRECT

Windowsでは、PowerShellが同じ自動設定URLと実効のWinHTTPプロキシを読みます。

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' AutoConfigURL
netsh winhttp show proxy

リゾルバが表示する最初の PROXY host:port を採用してください。それが次にハードコードする値です。PACに複数のルールがある場合は、pactester のマニュアル にフラグの説明があります。

ステップ3：HTTPS_PROXY、HTTP_PROXY、NO_PROXY を設定する

HTTPSとHTTP向けにプロキシをエクスポートし、プロキシをスキップすべきすべての内部ホストを NO_PROXY に列挙します。

export HTTPS_PROXY="http://proxy.corp.example.com:8080"
export HTTP_PROXY="http://proxy.corp.example.com:8080"
export NO_PROXY="localhost,127.0.0.1,.corp.example.com,.internal"

HTTPSトラフィックを運ぶにもかかわらず、プロキシURLのスキームが http:// である点に注意してください。これは正しく、スキームはプロキシと通信する方法を表しており、プロキシが転送するものを表しているわけではありません。プロキシに認証情報が必要な場合は、インラインで記述します。

export HTTPS_PROXY="http://alice:s3cret@proxy.corp.example.com:8080"

新しいシェルがこれらを継承するように、これらの行を ~/.zshrc か ~/.bashrc に入れてください。NO_PROXY の欠落は、プロキシを入れた後に内部Gitやレジストリの呼び出しが壊れる頻出原因なので、飛ばさないでください。

ステップ4：TLSインスペクションを行うプロキシのCAを信頼する

プロキシがTLSインスペクションを行う場合、すべての証明書をプライベートルートCAで再署名します。信頼するよう伝えるまで、Codexはそれを拒否します。ログインする前に CODEX_CA_CERTIFICATE をPEMバンドルに向けてください。

export CODEX_CA_CERTIFICATE="/etc/pki/tls/certs/corporate-root-ca.pem"
# Fallback that also covers curl, git, and other tools:
export SSL_CERT_FILE="/etc/pki/tls/certs/corporate-root-ca.pem"
codex login

CODEX_CA_CERTIFICATE が優先され、影響するのはCodexだけです。未設定の場合、Codexは SSL_CERT_FILE にフォールバックします。これは多くの企業向けイメージがすでに設定しています。Codexの 高度な設定ドキュメント には、後述の応用セクションで使うモデルプロバイダーとエンドポイントのオプションが説明されています。

ステップ5：RUST_LOG=debug で検証する

変数がCodexから見えていることを確認し、プロキシのネゴシエーションを観察します。

env | grep -i proxy
RUST_LOG=debug codex exec "print the current date" 2>&1 | grep -i proxy

デバッグ出力にプロキシホストが表示され、コマンドが結果を返せば完了です。それでも失敗する場合は、エラーメッセージがどの層で壊れたかを教えてくれます。次のセクションで各メッセージを修正方法に対応づけます。

セットアップ中によくあるエラー（と修正方法）

ほとんどのプロキシ失敗は、ひと握りのメッセージのいずれかを出します。ランダムに設定を変え始める前に、自分のものをここで照合してください。

このうち2つには補足が必要です。証明書エラーはインスペクションを行うネットワークで単一で最もよくある障害要因であり、検証を無効化することではなく、CAを信頼することで修正します。「動かすため」にTLS検証をオフにすると、回線上にあるものが何であれあなたのトラフィックを渡すことになるので、絶対にやめてください。そしてSOCKS5の停止は実在します。SOCKS5は一部のCodexの経路では動作しますが、エージェントが頼るストリーミング応答では不安定なので、社内ネットワークではHTTPプロキシを優先してください。

診断フローを一目で

flowchart TD
    A[Browser reaches internet, codex hangs] --> B{Proxy env vars set?}
    B -->|No| C[Resolve PAC, set HTTPS_PROXY + NO_PROXY]
    B -->|Yes| D{SSL / certificate error?}
    C --> D
    D -->|Yes| E[Set CODEX_CA_CERTIFICATE to corporate CA]
    D -->|No| F{407 auth error?}
    E --> F
    F -->|Yes| G[Add user:pass@ or run a cntlm/px relay]
    F -->|No| H[Run RUST_LOG=debug codex exec to trace]

PACが DIRECT と言っても HTTPS_PROXY がまだ必要なとき

Codexが、PACによってプロキシ経由でルーティングされるホストに到達しなければならないときは、常に HTTPS_PROXY が必要です。ほとんどの企業ネットワークでは、それはすべての外部APIホストを意味します。PACが賢いことはCodexの役には立ちません。CodexはPACを一度も実行しないからです。これは、特に挙げるべき3つの状況で人をつまずかせます。

1つ目は分割ルーティングです。PACは内部ホストには DIRECT を、公開インターネットには PROXY を返します。内部のものはすべて変数なしでターミナルから動くので、ネットワークが開いていると思い込み、その後最初の外部API呼び出しがハングします。修正は、外部ホスト向けに HTTPS_PROXY を設定し、内部のものを NO_PROXY に列挙して直接接続のままにすることです。

2つ目はスプリットトンネリングのVPNです。VPN上では、PACが社内トラフィックをプロキシ経由に、その他をすべて直接に送る場合もあれば、その逆の場合もあります。接続または切断すると実効プロキシが変わりますが、エクスポートした変数は変わりません。VPNを切り替えた直後にCodexが失敗し始めたら、PACを再解決して HTTPS_PROXY を更新してください。

3つ目は透過プロキシの思い込みです。一部のネットワークはクライアント設定なしにルーターでトラフィックをインターセプトするため、ブラウザには何も要りません。あなたの環境がそうなら、HTTPS_PROXY は一切不要かもしれず、存在しないホストに設定してもCodexが壊れるだけです。判断の枠組みで示した curl テストが、あなたがどちらの世界にいるかを教えてくれます。素の curl でAPIホストに到達できるなら、透過型なので変数は未設定のままにすべきです。

要するに、APIホストがプロキシされているときは HTTPS_PROXY を設定し、ネットワークが透過的にプロキシするときは未設定にする。CodexがあなたのためにPACを読んでくれる中間地点はありません。

チーム／複数開発者向けの設定

1台のマシンが動いたら、目標は次の開発者があなたの午後を繰り返さないことです。スケールするパターンは、共有される非機密の設定を、ユーザーごとの機密から分離することです。

プロキシとCAの値を、チームがシェルのrcファイルからsourceするバージョン管理されたプロファイル断片に保持してください。

# proxy.env — committed to the team dotfiles repo (no secrets here)
export HTTPS_PROXY="http://proxy.corp.example.com:8080"
export HTTP_PROXY="$HTTPS_PROXY"
export NO_PROXY="localhost,127.0.0.1,.corp.example.com,.internal"
export CODEX_CA_CERTIFICATE="/etc/pki/tls/certs/corporate-root-ca.pem"

すべてのAPIキーは、そのファイルの外、各開発者が一度だけ設定するユーザーごとの変数に保持してください。認証情報が必要なプロキシでは、誰かのパスワードを HTTPS_PROXY にコミットしないこと。各人がローカルで自分の user:pass@ を追加するか、共有設定に認証情報が一切残らないようローカル認証リレーを実行してもらってください。

NTLMやKerberosのプロキシでは、Codexがそのハンドシェイクを扱えないため、チーム全体がローカルリレーを必要とします。cntlm や px のようなマシンごとのリレーを実行し、全員の HTTPS_PROXY をそれに向けてください。

# px handles enterprise NTLM auth; Codex talks plain HTTP to localhost
px --proxy=proxy.corp.example.com:8080 --port=3128 &
export HTTPS_PROXY="http://localhost:3128"

展開時の細部が毎回チームをつまずかせます。ログインシェルではなくIDEのターミナルやランチャーからCodexを実行する開発者です。macOSとWindowsのGUIアプリは ~/.zshrc で設定した変数を継承しないため、Terminalでは動くのとまったく同じセットアップがエディタ内では失敗します。これをオンボーディングノートに記載してください。macOSでは変数を launchd のユーザーエージェントかアプリ自身の環境に設定し、Windowsではシステム環境変数のダイアログを使って、新しいシェルだけでなくすべてのプロセスがそれを継承するようにしてください。設定が完了したと誰かに伝える前に、まっさらな新しいターミナルを開いて RUST_LOG=debug codex exec "print ok" を実行し、新規チェックアウトが動くことを検証してください。

応用：カスタム base_url とマルチプロバイダールーティング

プロキシとCAが整うと、Codexは api.openai.com だけでなく、その同じ社内エグレス経由で任意のOpenAI互換エンドポイントに到達できるようになります。ここで config.toml の カスタムモデルプロバイダー が真価を発揮します。

OpenAI互換ゲートウェイを指すプロバイダーブロックを定義します。各キーは 設定リファレンス に記載されています。

# ~/.codex/config.toml
model_provider = "ofox"
model = "openai/gpt-5.4"

[model_providers.ofox]
name = "ofox OpenAI-compatible gateway"
base_url = "https://api.ofox.ai/v1"
env_key = "OFOX_API_KEY"

組み込みのOpenAIプロバイダーを別のエンドポイントに移すだけでよいなら、プロバイダーブロック全体を書く代わりに openai_base_url を設定してください。いずれにせよ、リクエストは設定した HTTPS_PROXY を通じてマシンから出ていき、設定したCAを信頼し続けるので、プロキシの作業はそのまま引き継がれます。

チームがロックダウンされたネットワークでこれに手を伸ばす理由は集約です。ファイアウォールチームに複数のベンダーAPIホストを許可リストに入れてもらい、複数のキーを維持してもらう代わりに、Codexを1つの OpenAI互換ゲートウェイ に向け、文字列を変えるだけでモデルを切り替えます。ofox ではそれが、openai/gpt-5.4 に加えてClaude、Gemini、その他をカバーする1つのエンドポイントと1つのキーを意味し、プロキシの許可リストを短く保てます。まず特定のモデルを試したい場合は、openai/gpt-5.4 のモデルページ に現時点の詳細があります。トラフィックは引き続き社内プロキシを流れ、ここで何かがそれをバイパスすることはありません。

FAQ

Codex CLIはPACやWPADによるプロキシ自動設定に対応していますか？ いいえ。Codexは HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY を読みますが、PACファイルを評価したりWPAD経由でプロキシを検出したりはしません。PACは自分で解決し、その結果を HTTPS_PROXY に入れます。

ブラウザはインターネットに接続できるのに、なぜCodexはハングするのですか？ ブラウザはWPAD経由のPACファイルからプロキシを取得しますが、Codexはそれをしません。プロキシ変数が設定されていないと、Codexはファイアウォールが破棄する直接接続を開くため、リクエストはタイムアウトするまでハングします。

Codex CLIでプロキシを設定するにはどうすればよいですか？ プロキシのホストとポートを指す HTTPS_PROXY と HTTP_PROXY をエクスポートし、内部ホスト用に NO_PROXY を設定します。config.toml にプロキシ用キーはないため、環境変数が経路です。

プロキシ配下のCodexでSSL証明書エラーを解決するには？ TLSインスペクションを行うプロキシは、Codexが信頼しないプライベートルートCAで署名された証明書を提示します。codex login の前に CODEX_CA_CERTIFICATE を社内ルートCAのPEMに向けてください。未設定の場合、Codexは SSL_CERT_FILE にフォールバックします。

Codex CLIはSOCKS5プロキシに対応していますか？ 部分的に対応しています。SOCKS5は一部の経路では動作しますが、Codexが多用するストリーミングやWebSocketトラフィックでは不安定です。社内ネットワークでは HTTPS_PROXY 経由のHTTPプロキシの方が信頼できます。

チーム全体でCodexのプロキシを設定するには？ プロキシとCAの変数を共有された非機密のプロファイル断片に置き、config.toml のプロバイダーブロックをdotfilesリポジトリにチェックインします。APIキーとプロキシの認証情報はユーザーごとに保持し、決してコミットしないでください。

CodexにおけるHTTP_PROXYとHTTPS_PROXYの違いは何ですか？ HTTP_PROXY は通常の http:// リクエストに、HTTPS_PROXY は https:// リクエストに適用されます。CodexのAPIトラフィックはすべてHTTPSなので、重要なのは HTTPS_PROXY ですが、両方を同じ値に設定してください。

NTLMやKerberosのプロキシを介してCodexで認証するには？ CodexはNTLMやKerberosの認証を直接扱えません。cntlm や px のようなローカルリレーを実行し、HTTPS_PROXY を http://localhost:<relay-port> に向けてください。

参考リンク

社内プロキシの問題は、Codexが壊れていることではまずありません。Codexが、誰も設定してくれなかった唯一のプロキシ方言——つまり素の環境変数——を話すことに正直なだけです。上記のすべては、2026-07-05にこれらのソースと照合しています。

• OpenAI Codex advanced configuration and config reference: https://developers.openai.com/codex/config-advanced
• OpenAI Codex proxy environment variable issue: https://github.com/openai/codex/issues/4242
• PyPAC “About PAC files” on PAC/WPAD behavior: https://pypac.readthedocs.io/en/latest/about_pac.html
• pactester manual page: https://manpages.ubuntu.com/manpages/focal/man1/pactester.1.html
• ofox model catalog and docs snapshot: https://ofox.io/models