---
title: "Codex CLIのプロキシ設定・承認モード・オプション一覧｜導入とアンインストール【2026年9月】"
url: "https://www.issoh.co.jp/tech/details/8157/"
published: 2025-08-12
updated: 2026-09-29
categories: ["AIエージェント・MCP"]
publisher: "株式会社一創"
---

# 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とは｜始め方・料金・コードを学習させない設定まで解説](/tech/details/8457/)で扱っています。この記事は、入れたあとに設定で詰まった人向けのリファレンスです。

## まとめ：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つに分かれています。検索して見つけた設定例が効かないときは、まず自分がどれを探しているのかを確認してください。

| 目的                   | 設定する場所                             | 対象の通信                    |
| -------------------- | ---------------------------------- | ------------------------ |
| 社内プロキシを経由して外へ出る      | 環境変数 HTTPS\_PROXY ほか               | ログイン・モデルAPI・更新確認         |
| Codexが実行するコマンドの通信を絞る | config.toml の network\_proxy       | npm install・curl など子プロセス |
| モデルへの通信を中継サーバーに向ける   | config.toml の openai\_base\_url ほか | モデルAPIのみ                 |

社内ネットワークで「ログインできない」「応答が返らない」場合は、まず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%40ss@proxy.example.co.jp: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月版】](/tech/details/11247/)にまとめています。

### TLSインスペクション環境の証明書：CODEX\_CA\_CERTIFICATE

ZscalerなどHTTPSを復号して検査するプロキシの内側では、プロキシを通せても証明書の検証で失敗します。[公式ドキュメントの環境変数一覧](https://learn.chatgpt.com/docs/config-file/environment-variables)では、`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の書き方と互換の限界](/tech/details/16637/)、ローカルLLMに向ける場合は[OllamaでCodexをローカルLLM実行する方法｜ollama launch codex-appの手順と対処法](/tech/details/12264/)を参照してください。

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

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

| 旧モード名     | 現行の指定                                     | 挙動               |
| --------- | ----------------------------------------- | ---------------- |
| Suggest   | –sandbox read-only -a on-request          | 読むだけ・変更は承認制      |
| Auto Edit | –sandbox workspace-write -a on-request    | 作業フォルダ内は自動・外は承認制 |
| Full Auto | –sandbox workspace-write -a never         | 作業フォルダ内で確認なしに実行  |
| （制限なし）    | –dangerously-bypass-approvals-and-sandbox | サンドボックスも承認もなし    |

公式ドキュメントは `--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のリリースノート](https://github.com/openai/codex/releases/tag/rust-v0.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
```

[公式ドキュメントの承認ページ](https://learn.chatgpt.com/docs/agent-approvals-security)には、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日）](https://github.com/openai/codex/releases/tag/rust-v0.149.0)で `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の置き場所                                   |
| ---------------------- | ----------------------------------------------------- | -------------------------------------------- |
| 公式インストーラー（macOS・Linux） | curl -fsSL https://chatgpt.com/codex/install.sh \| sh | \~/.local/bin                                |
| 公式インストーラー（Windows）     | irm https://chatgpt.com/codex/install.ps1 \| iex      | %LOCALAPPDATA%\\Programs\\OpenAI\\Codex\\bin |
| npm                    | npm install -g @openai/codex                          | npmのグローバル領域                                  |
| Homebrew               | brew install –cask codex                              | Homebrewの管理領域                                |
| winget                 | winget install OpenAI.Codex                           | wingetの管理領域                                  |
| Arch Linux             | sudo pacman -S openai-codex                           | /usr/bin                                     |

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

### 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                | 対話画面（TUI）を起動       |
| codex exec           | 非対話で実行（CI・スクリプト向け） |
| codex review         | コードレビューを非対話で実行     |
| codex resume –last   | 直前のセッションを再開        |
| codex login / logout | サインインと認証情報の削除      |
| codex mcp            | 外部MCPサーバーの登録・管理    |
| codex doctor         | 導入・設定・認証・通信の診断     |
| codex features list  | 機能フラグの段階と有効状態の一覧   |
| codex sandbox        | コマンドをサンドボックス内で試す   |
| codex update         | 最新版へ更新             |

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

| オプション                  | 内容                                               |
| ---------------------- | ------------------------------------------------ |
| \-m, –model            | 使うモデルを指定                                         |
| \-s, –sandbox          | read-only / workspace-write / danger-full-access |
| \-a, –ask-for-approval | on-request / never                               |
| \-C, –cd               | 作業ルートのフォルダを指定                                    |
| –add-dir               | 書き込みを許すフォルダを追加                                   |
| \-c key=value          | config.tomlの値をその場で上書き                            |
| \-p, –profile          | プロファイルの設定ファイルを重ねる                                |
| –search                | ライブのWeb検索を有効化                                    |
| \-i, –image            | 画像を最初の依頼に添付                                      |
| –worktree              | 新しいGit worktreeで作業                               |

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

### 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](https://github.com/openai/codex/releases/tag/rust-v0.131.0)〜[0.134.0](https://github.com/openai/codex/releases/tag/rust-v0.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とは｜始め方・料金・コードを学習させない設定まで解説](/tech/details/8457/)で解説しています。Claude Codeとの比較は[CodexとClaude Codeの違い｜料金・使用量・設定と併用の判断【2026年版】](/tech/details/17627/)を参照してください。

## 関連記事

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

---

出典: [Codex CLIのプロキシ設定・承認モード・オプション一覧｜導入とアンインストール【2026年9月】](<https://www.issoh.co.jp/tech/details/8157/>)（株式会社一創）
