Codex CLIのプロキシ設定・承認モード・オプション一覧｜導入とアンインストール【2026年9月】

Codex CLIを社内プロキシの内側で動かすときの設定は、環境変数の HTTPS_PROXY と NO_PROXY、TLSインスペクションがある場合の CODEX_CA_CERTIFICATE の3つが基本です。この記事では、2026年9月28日に公開された Codex CLI 0.158.0 を手元に入れ、codex doctor の診断結果とソースコードで挙動を確かめた内容をもとに、プロキシ設定、承認モード、インストールとアンインストール、主要オプション、config.toml の書き方を整理します。

Codex CLIの成り立ちや料金、始め方はCodex CLIとは｜始め方・料金・コードを学習させない設定まで解説で扱っています。この記事は、入れたあとに設定で詰まった人向けのリファレンスです。

まとめ：Codex CLIの設定で押さえる要点

• 社内プロキシ：HTTPS_PROXY・HTTP_PROXY・NO_PROXY を環境変数で渡します。config.toml にはCodex本体の通信用のプロキシ項目がありません。
• 証明書エラー：TLSを復号するプロキシの内側では、社内ルートCAのPEMを CODEX_CA_CERTIFICATE で指定します。未設定なら SSL_CERT_FILE を読みます。
• PACファイル：macOSのシステムプロキシやPACを読む機能（respect_system_proxy）は0.158.0で開発中・既定オフです。PACを使う会社では、Codexの接続先に使うプロキシのアドレスを管理者に確認して環境変数に書きます。
• 確認方法：codex doctor の Connectivity 欄に、読み込んだプロキシ環境変数と接続結果が出ます。
• 承認モード：Suggest・Auto Edit・Full Auto は2025年のTypeScript版の名前です。現行は --sandbox と --ask-for-approval の組み合わせで指定し、--full-auto は0.147.0で削除、approval_policy = "untrusted" は起動エラーになります。
• インストール：公式インストーラー、npm、Homebrew、winget、Arch Linux の公式パッケージがあります。アンインストールは入れた方法と同じ経路で行い、設定とログイン情報は ~/.codex に残ります。

「codex cli proxy」が指す3つの設定と置き場所

Codex CLIで「プロキシ」と呼ばれる設定は、目的の違う3つに分かれています。検索して見つけた設定例が効かないときは、まず自分がどれを探しているのかを確認してください。

社内ネットワークで「ログインできない」「応答が返らない」場合は、まず1つ目の設定と接続状況を確認してください。2つ目はセキュリティのための制限機能で、社内プロキシを通す設定ではありません。

社内プロキシ経由の設定：HTTPS_PROXYとNO_PROXY

Codex CLIはRust製で、HTTP通信はreqwestライブラリの既定の挙動に従います（0.158.0のソース outbound_proxy.rs の ReqwestDefault）。reqwestは環境変数のプロキシ設定を読むので、起動前に次のように設定します。

# macOS / Linux（~/.zshrc や ~/.bashrc に書く）
export HTTPS_PROXY=http://proxy.example.co.jp:8080
export HTTP_PROXY=http://proxy.example.co.jp:8080
export NO_PROXY=localhost,127.0.0.1,.example.co.jp

# 認証付きプロキシの場合（記号はURLエンコードする）
export HTTPS_PROXY=http://user:p%[email protected]:8080

codex doctor が検出する変数は HTTP_PROXY・HTTPS_PROXY・ALL_PROXY・NO_PROXY と、それぞれの小文字版の8つです（doctor.rs の PROXY_ENV_VARS）。Codexの通信先はHTTPSなので、最低限 HTTPS_PROXY があれば足ります。社内のGitサーバーやローカルのOllamaへの通信までプロキシへ送らないよう、NO_PROXY も一緒に設定してください。

Windowsでは、PowerShellで $env:HTTPS_PROXY="http://proxy.example.co.jp:8080" のように設定します。ChatGPTデスクトップアプリ側のプロキシ設定を含むWindows固有の手順はWindows版Codexの使い方｜アプリ版とCLIの違い・導入手順・プロキシ設定【2026年7月版】にまとめています。

TLSインスペクション環境の証明書：CODEX_CA_CERTIFICATE

ZscalerなどHTTPSを復号して検査するプロキシの内側では、プロキシを通せても証明書の検証で失敗します。公式ドキュメントの環境変数一覧では、CODEX_CA_CERTIFICATE を「社内のTLS傍受や独自ルート証明書がある環境向けのPEM CAバンドル」と説明し、SSL_CERT_FILE より優先されるとしています。

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

対象はHTTPS・ログイン・WebSocketの各クライアントです。ソースの custom_ca.rs によると、1つのPEMに複数の証明書を並べてよく、OpenSSL形式の TRUSTED CERTIFICATE ラベルやCRLが混ざっていても読み込めます。ファイルが読めない、形式が壊れているといった場合は、通信を始める前にエラーで止まります。

macOSのシステムプロキシ・PAC対応の既定値

「ブラウザはつながるのにCodexだけつながらない」場合に確認したいのが、会社のプロキシ設定がPACファイル（自動構成スクリプト）で配られているケースです。0.158.0では、macOSのシステムプロキシやPAC・WPADを解決する respect_system_proxy という機能がありますが、codex features list で見ると段階は under development（開発中）で既定はオフです。

そのため、PAC運用の会社では、管理者にCodexの接続先で使用するプロキシのホストとポートを確認し、環境変数に設定してください。codex doctor は、システムプロキシが設定されているのに使われていない状態を検出すると「A macOS system proxy is configured but unused.」と表示し、管理者に codex features enable respect_system_proxy を有効にしてよいか確認するよう案内します。開発中の機能なので、個人の判断で本番の作業環境に入れるのは避けたほうが無難です。

なお、起動直後の一部の通信には、再送しても安全なリクエストに限ってシステムプロキシ経由で再試行する system_proxy_fallback（stable・既定オン）があります。ソースのコメントには、通常のHTTPリクエストの経路は変えないと書かれています。モデルとのやり取りを通すには、やはり環境変数が必要です。

codex doctorでプロキシ設定を確かめる手順

設定が効いているかは codex doctor で確かめられます。0.158.0で、HTTPS_PROXY を使われていないポート（127.0.0.1:9）に向けた状態と、設定しない状態で実行し、結果を比べました（出力は抜粋）。

$ HTTPS_PROXY=http://127.0.0.1:9 codex doctor --no-color
Connectivity
  ✓ network      network-related environment looks readable
      proxy env vars present   HTTPS_PROXY
      system proxy             direct
      respect system proxy     disabled
      managed proxy            not configured
  ⚠ websocket    Responses WebSocket failed; HTTPS fallback may still work
      handshake transport error network error: Connection refused (os error 61)
  ✗ reachability desktop update and runtime CDN is unreachable
      ChatGPT inference URL    https://chatgpt.com/backend-api/<redacted> connect failed (required)

環境変数を外して実行すると、同じ欄は proxy env vars none になり、ChatGPT inference URL は reachable (HTTP 405) に変わりました。つまり、Codex CLIは HTTPS_PROXY を読み、指定されたプロキシへ接続しにいっています。社内環境で確認するときは次の順で見てください。

• proxy env vars present に設定した変数名が出ているか（出ていなければシェルの設定が読まれていません）
• ChatGPT inference URL が reachable か（connect failed ならプロキシ設定に加えてDNS・VPN・ファイアウォール・接続先の状態を確認し、407ならプロキシ認証の有無・方式・資格情報を確認）
• 証明書のエラーが出ていないか（出ていれば CODEX_CA_CERTIFICATE を設定します）

結果をIssueなどに貼るときは、codex doctor --json を使うと認証情報やURLを伏せた形式で出力されます。

コマンドの通信を絞る設定：network_accessとnetwork_proxy

Codexが実行する npm install や curl などのコマンドは、サンドボックスの中で動きます。公式ドキュメントによると、標準の workspace-write サンドボックスではネットワークが既定で切られています。コマンドに通信を許すときは config.toml に次のように書きます。

[sandbox_workspace_write]
network_access = true

通信を許したうえで行き先のドメインを絞りたい場合は、実験的機能の network_proxy を有効にします。有効にするとCodexがローカルにHTTPプロキシ（既定 127.0.0.1:3128）とSOCKS5プロキシ（既定 127.0.0.1:8081）を立て、許可リストにないドメインへの通信を止めます。社内プロキシへのつなぎ込みは allow_upstream_proxy（既定 true）が担い、環境変数の HTTP(S)_PROXY を上流として使います。

この機能が制御するのは、Codexが実行するコマンドとその子プロセスの通信だけです。公式ドキュメントは、モデルとの通信や認証、アプリ（コネクタ）の通信はこのプロキシの対象外だと明記しています。「network_proxyを設定したのにログインできない」場合は、前の節の環境変数を見直してください。

モデル通信を中継する設定：openai_base_urlとcodex-responses-api-proxy

社内のLLMゲートウェイやデータレジデンシー対応のエンドポイントを経由させたい場合は、プロキシではなくモデルの接続先を変えます。公式ドキュメントは、組み込みのOpenAIプロバイダーの接続先を変えるだけなら、新しいプロバイダーを定義せずに openai_base_url を使うよう案内しています。

# ~/.codex/config.toml
openai_base_url = "https://llm-gateway.example.co.jp/v1"

もう1つ、公式リポジトリには codex-responses-api-proxy という小さな中継サーバーがあります。/v1/responses へのPOSTだけをOpenAI APIに転送し、APIキーをサーバー側で付け足すもので、それ以外のリクエストは403で拒否します。APIキーを利用者に見せずにCodexを使わせたいときの部品です。GitHub Releasesとnpm（@openai/codex-responses-api-proxy）で配布されており、Arch Linuxの公式パッケージにも同梱されています。

ただし、このツールのREADMEにある設定例は、旧形式の [profiles.proxy] と codex -p proxy の組み合わせです。後述のとおり、0.158.0ではこの書き方で -p を使うとエラーになります。プロファイル部分は新形式に読み替えてください。Azure OpenAIに接続する場合の書き方はAzure OpenAIとCodexの連携設定｜config.tomlの書き方と互換の限界、ローカルLLMに向ける場合はOllamaでCodexをローカルLLM実行する方法｜ollama launch codex-appの手順と対処法を参照してください。

承認モードとサンドボックスの組み合わせ

「Suggest」「Auto Edit」「Full Auto」は、2025年春に公開されたTypeScript版Codex CLIのモード名です。2025年4月30日時点のREADMEでは --approval-mode に suggest（既定）・auto-edit・full-auto を渡す仕様でした。Rust版に置き換わった現行のCodex CLIでは、「何ができるか」をサンドボックスで、「いつ確認を求めるか」を承認ポリシーで、別々に指定します。

公式ドキュメントは --sandbox workspace-write --ask-for-approval on-request を「Auto」プリセットと呼び、Gitで管理されたフォルダではこれが推奨の既定になります。0.158.0の --ask-for-approval（短縮形 -a）が受け付ける値は on-request と never の2つだけで、untrusted や on-failure を渡すと「invalid value」で止まります。

なお、workspace-write でも作業フォルダ内の .git・.agents・.codex は読み取り専用で保護されます。対話中は /permissions で切り替えられます。

–full-autoは0.147.0で削除：execの書き換え方

2026年8月7日の0.147.0のリリースノートに「非推奨だった codex exec --full-auto を削除した。代わりに --sandbox workspace-write を使う」とあります。0.158.0で実行すると、次のように引数エラーで終了コード2になります。

$ codex exec --full-auto "hello"
error: unexpected argument '--full-auto' found
$ echo $?
2

公式ドキュメントの承認ページには、2026年9月29日時点でも「古い codex exec --full-auto は非推奨の互換経路として残り、警告を表示する」と書かれています。実際のCLIは警告ではなくエラーで止まるので、CIのスクリプトに --full-auto が残っていると、更新した日からジョブが落ちます。codex exec --sandbox workspace-write に書き換えてください。codex exec は承認を求めない非対話実行で、設定ファイルやプロジェクトの信頼状態による指定がない場合、サンドボックスの既定は read-only です（0.158.0の起動表示で確認）。

approval_policy = “untrusted” は起動エラー

0.149.0（2026年8月20日）で untrusted の承認ポリシーが廃止されました（#39630）。config.toml に残したまま0.158.0を起動すると、何も始まらずに終了します。

$ cat ~/.codex/config.toml
approval_policy = "untrusted"
$ codex exec "hello"
Error: approval_policy = "untrusted" is no longer supported; remove this setting

同じ確認の厳しさを保ちたい場合は、approval_policy を書かずに、ユーザー設定の ~/.codex/config.toml でプロジェクトを信頼しない指定にするよう公式ドキュメントが案内しています。

[projects."/path/to/project"]
trust_level = "untrusted"

この指定では、実行ポリシーのルールで許可されたもの以外のコマンドに承認が必要になり、プロジェクト内の設定ファイルも読まれなくなります。一方、on-failure はソース上 on-request の別名として残っていて、config.toml に書いてもエラーにはなりません。

–approve-for-meと–yoloの違い

0.147.0で追加された --approve-for-me は、承認が必要な操作を人ではなくレビュー用のエージェントに判定させるオプションです。サンドボックスは workspace-write に固定され、--sandbox とは同時に指定できません。公式ドキュメントによると、レビューはデータの持ち出し、認証情報の探索、セキュリティ設定の恒久的な弱体化、破壊的な操作を確認し、危険度が最も高い操作は拒否します。config.toml で同じ設定にするには、approvals_reviewer = "auto_review"、approval_policy = "on-request"、sandbox_mode = "workspace-write" を指定します。

一方の --yolo は --dangerously-bypass-approvals-and-sandbox の別名で、サンドボックスも承認も外します。ヘルプの説明は「外部でサンドボックス化された環境でだけ使う」です。自動で進めたいだけなら、--yolo ではなく --approve-for-me か -a never とサンドボックスの組み合わせを選びます。

OS別のインストール方法とアップデート

2026年9月29日時点の最新版は0.158.0（GitHub Releases・npm・winget・Arch Linuxのいずれも同じ版）です。公式の案内は次のとおりです。

公式インストーラーの置き場所は、環境変数 CODEX_INSTALL_DIR で変えられます。Homebrewは --cask 付きの codex が公式READMEの表記で、旧記事にある brew install codex-cli は使いません。Macで入れる場合の注意点（Intel Macの配布物やChatGPTデスクトップアプリとの関係）はCodexをMacにインストールする方法｜ChatGPTアプリ・CLI・Intel Mac対応【2026年9月】で詳しく扱っています。

Arch Linuxは公式リポジトリのopenai-codex

Arch Linuxでは、AURではなく公式リポジトリ（extra）に openai-codex があり、2026年9月28日に0.158.0へ更新されています。依存パッケージに bubblewrap が入っていて、Linuxのサンドボックスはこれを使います。AURの openai-codex-bin も同じ版ですが、通常の導入では、ディストリビューションのパッケージ管理に統一できる公式リポジトリ版を推奨します。ほかのディストリビューションでは、公式インストーラーかnpmを使います。GitHub ReleasesのLinux向けバイナリは musl 版で、x86_64 と arm64 の2種類があります。

Windowsはwinget、Chocolateyは有志の版

wingetの OpenAI.Codex は、マニフェストの先頭に「Codexのリリースワークフローで作成」とあり、GitHub Releasesで0.158.0が公開された2026年9月28日のうちに、同じ版のマニフェストが登録されています。一方、choco install codex で入るChocolateyのパッケージは、パッケージの配布元（PackageSourceUrl）がOpenAIではなく個人のGitHubリポジトリです。2026年9月29日時点の最新は0.157.1で、公式の0.158.0より1版前でした。版の追従は有志の作業に依存するので、Windowsでは公式インストーラーかwingetを選んでください。

アップデートと更新確認の止め方

更新は codex update か、入れたときと同じ方法（npm install -g @openai/codex@latest、brew upgrade --cask codex、winget upgrade OpenAI.Codex、インストーラーの再実行）で行います。Codexは起動時に新しい版を確認します。社内で版を固定して配布している場合は、config.toml に check_for_update_on_startup = false を書くと確認を止められます。公式の説明は「更新を一元管理している場合にだけ false にする」です。

Codex CLIのアンインストール手順

アンインストールは、入れたときと同じ経路で行います。複数の方法で入れている場合は、macOS・Linuxでは which -a codex、WindowsのPowerShellでは Get-Command codex -All でPATH上の候補を確認してから消してください。

# npm
npm uninstall -g @openai/codex
# Homebrew
brew uninstall --cask codex
# winget
winget uninstall OpenAI.Codex
# Arch Linux
sudo pacman -Rns openai-codex
# 公式インストーラー（macOS・Linux）
rm ~/.local/bin/codex ~/.local/bin/codex-code-mode-host
rm -rf ~/.codex/packages/standalone

公式インストーラーにはアンインストール用のコマンドがありません。インストーラーはPATHを通すため、シェルの設定ファイル（macOSのzshなら ~/.zprofile、Linuxのbashなら ~/.bashrc）に # >>> Codex installer >>> から # <<< Codex installer <<< までのブロックを書き足しています。完全に消すときはこのブロックも削除します。

設定、ログイン情報（auth.json）、会話の履歴、ログは ~/.codex（環境変数 CODEX_HOME で変更可）に残ります。ChatGPTデスクトップアプリやIDE拡張と共用するフォルダなので、CLIだけやめる場合は残し、Codexをすべて使わなくなるときだけ削除します。

よく使うコマンドとオプション一覧

0.158.0の codex --help から、日常的に使うサブコマンドを抜き出しました。

主なオプションは次のとおりです。

codex exec には、結果を機械処理するための --json、最後の応答をファイルに書く -o、出力の形をJSONスキーマで指定する --output-schema、セッションを保存しない --ephemeral があります。対話中に使うスラッシュコマンドでは、/status がコンテキストの使用量と利用上限を、/permissions がサンドボックスと承認の切り替えを、/compact が会話の圧縮を担います。サブエージェントの定義はCodexサブエージェントとカスタムエージェントの使い方｜TOML定義・config.toml設定・並列実行【2026年7月版】で扱っています。

temperatureは設定できない：推論の強さと応答の長さで調整

公式の設定リファレンスに temperature という項目はありません。出力を変えたいときに使うのは、推論にかける手間を決める model_reasoning_effort（low・medium・high・xhigh など。使える段階はモデルによる）と、応答の詳しさを決める model_verbosity です。どちらも -c model_reasoning_effort="high" のように、その回だけ上書きできます。

ログとデバッグ出力の取り方

0.158.0のTUIは、既定では診断情報を ~/.codex 内の容量を区切った保存領域に記録し、テキストのログファイルは作りません。テキストで読みたい場合は、公式リポジトリの手順どおり log_dir を指定します。

codex -c log_dir=./.codex-log
tail -F ./.codex-log/codex-tui.log

# 詳細度はRUST_LOGで変える（codex execの既定はerror）
RUST_LOG=debug codex exec "テストを実行して"

config.tomlの場所と書き方

設定ファイルは ~/.codex/config.toml です。場所は環境変数 CODEX_HOME で変えられ、公式ドキュメントによると指定するフォルダはあらかじめ作っておく必要があります。信頼したプロジェクトでは、プロジェクト内の .codex/config.toml も読まれます。よく使う項目を並べると次のようになります。モデル名は入れ替わりが速いので、対話中の /model で選べるものを確認してから書きます。

model = "gpt-6-sol"
model_reasoning_effort = "medium"
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

書いた項目が今の版で有効かどうかは、--strict-config を付けて起動すると確かめられます。この版が知らない項目があるとエラーで止まるので、古い記事から写した設定が残っていないかを点検できます。

プロファイルは別ファイルへ：旧[profiles]は-pでエラー

2026年5月の0.131.0〜0.134.0で、プロファイルの仕組みが変わりました。以前は config.toml の中に [profiles.fast] のような表を書いていましたが、現行は ~/.codex/fast.config.toml という別ファイルを作り、codex -p fast でそれを基本の設定に重ねます。0.158.0で旧形式のまま -p を使うと、次のエラーで止まりました。

Error loading config.toml: --profile `fast` cannot be used while
~/.codex/config.toml contains legacy `profile = "fast"` or `[profiles.fast]` config;
move those settings into ~/.codex/fast.config.toml and remove the legacy profile selector/table.

メッセージのとおり、[profiles.fast] の中身を fast.config.toml へ移し、config.toml 側の表と profile = "fast" の行を消せば直ります。

よくある質問

Codex CLIはAPIキーでも使えますか？

使えます。対話で使う場合は printenv OPENAI_API_KEY | codex login --with-api-key で登録します。codex exec をCIで動かす場合は、環境変数 CODEX_API_KEY で渡せます。公式ドキュメントは、リポジトリ内のコードを実行するジョブでは、ジョブ全体ではなくそのコマンドにだけ渡すよう勧めています。

Codexに自動でコミットさせられますか？

標準の workspace-write サンドボックスでは .git が読み取り専用で保護されるため、git commit はサンドボックスの外の操作として承認を求められます。承認すればコミットできます。人の確認を省きたい場合は、サンドボックスを維持したまま --approve-for-me で承認要求を自動レビューに回す選択肢があります。ただし、レビューで拒否される操作もあるため、コミットの成功を保証するものではありません。

Codex CLIが対応しているOSは？

0.158.0のGitHub Releasesには、macOS（Apple silicon・Intel）、Linux（x86_64・arm64）、Windows（x64・arm64）向けのバイナリがあります。WindowsはWSLを使わずにネイティブで動きます。

codex cli の「goal」とは何ですか？

対話中に /goal で設定する、Codexが継続して目指す目標です。公式のスラッシュコマンド一覧では「Codexが取り組み続ける永続的な目標を設定する」と説明されています。0.158.0の codex features list では goals が stable・有効です。

Codex CLIの基本や料金はどこで確認できますか？

Codex CLIの概要、ChatGPTプランとAPIの料金の違い、コードを学習に使わせない設定はCodex CLIとは｜始め方・料金・コードを学習させない設定まで解説で解説しています。Claude Codeとの比較はCodexとClaude Codeの違い｜料金・使用量・設定と併用の判断【2026年版】を参照してください。

関連記事

• Codex CLIとは｜始め方・料金・コードを学習させない設定まで解説
• Windows版Codexの使い方｜アプリ版とCLIの違い・導入手順・プロキシ設定【2026年7月版】
• CodexをMacにインストールする方法｜ChatGPTアプリ・CLI・Intel Mac対応【2026年9月】
• Codexサブエージェントとカスタムエージェントの使い方｜TOML定義・config.toml設定・並列実行【2026年7月版】
• Azure OpenAIとCodexの連携設定｜config.tomlの書き方と互換の限界