Codex CLIの設定と使い方は、いま動いている実行ファイルの所在を確認するところから始まります。本記事は実行ファイルの特定から権限設定、AGENTS.mdの読み込み順、つまずきやすい落とし穴までを、公式ドキュメント8件と自社の検証環境（learn.chatgpt.com、旧developers.openai.com/codex、2026-07-28閲覧時点）から整理します。
01結論：Codex CLIのセットアップは、設定と使い方を実行ファイルの所在確認から始める
Codex CLIは、単体のインストーラーで導入する場合があります。ChatGPTのデスクトップアプリに同梱された実行ファイルとして存在する場合もあります（出典: Codex公式ドキュメント）。同じcodexというコマンド名でも、環境によって実体のファイルが違うことがある、という前提から始めます。
このセットアップで決めることは、下表の4つです。
| 観点 | 決めること | 効き方 |
|---|---|---|
| 実行ファイル | どのcodexが動いているかを特定する | 実体が変わるとバージョンも動作も変わる |
| 権限 | sandbox_modeとapproval_policyの組み合わせ | ツール実行の直前に自動で適用される |
| プロジェクト連携 | AGENTS.mdの読み込みと信頼設定 | フォルダ単位で有効・無効が切り替わる |
| MCP接続 | 外部ツールの追加 | config.tomlのmcp_serversに登録して使う |
02セットアップ前に確認する3つの前提｜環境・認証・権限
セットアップに入る前に、3つを確認します。1つ目はOSとインストール方法を問わず、codexコマンドがPATH上で解決できるか、絶対パスで直接呼べる状態かです。2つ目は認証方法、3つ目は設定変更を許すディレクトリ範囲です。
認証は、ChatGPTアカウントでのサインインと、APIキーによる認証の両方が用意されています（出典: Codex公式ドキュメント）。
| 認証方法 | 向く用途 | 備考 |
|---|---|---|
| ChatGPTサインイン | 対話的な利用 | 初回起動時に選択する |
| APIキー | 対話しない自動実行・CI等 | 非対話環境ではこちらが一般的とされる |
3つ目のディレクトリ範囲は、後述のsandbox_modeで決めます。
03実行ファイルの所在確認：セットアップの最初の一歩として行うこと
最初の一歩は、PATHで解決されるcodexの実体を確認することです。
# PATHで解決されるcodexの実体を確認する
which codex
ls -la "$(which codex)"自社の検証環境（macOS）では、この実体は単体インストーラーの配置先ではありませんでした。実際のパスは/Applications/ChatGPT.app/Contents/Resources/codexでした（2026-07-28確認）。以前は別の場所にあったコマンドが見つからなくなった経緯があり、以後はこの同梱パスを実体として扱っています。
# ChatGPT.app同梱の実行ファイルを直接確認する
ls -la "/Applications/ChatGPT.app/Contents/Resources/codex"
"/Applications/ChatGPT.app/Contents/Resources/codex" --version自社では、この絶対パスをCODEX_BINという環境変数に入れ、実行スクリプト側から明示的に参照する運用にしています。エイリアスだけに頼ると、cronや自動実行スクリプトのようにシェル設定を経由しない場面で解決できないことがあるためです。
# ~/.zshrc に追記する例
export CODEX_BIN="/Applications/ChatGPT.app/Contents/Resources/codex"
alias codex="$CODEX_BIN"04権限とサンドボックスのセットアップ｜3モードの使い分け
Codexのサンドボックスは、read-only・workspace-write・danger-full-accessの3モードです（出典: Codex公式ドキュメント）。既定はworkspace-writeです。
| sandbox_mode | できること | ネットワーク | ファイル書き込み |
|---|---|---|---|
| read-only | ファイルの検査のみ。編集・実行は承認が要る | 制限あり | 不可 |
| workspace-write（既定） | ワークスペース内で読み書き・ルーチン実行 | 承認時に許可 | ワークスペース内に限定 |
| danger-full-access | サンドボックス制限なしで動作 | 無制限 | システム全体 |
承認のタイミングはapproval_policyで決めます。値はuntrusted・on-request・neverの3種類です（出典: Codex公式ドキュメント）。
| approval_policy | 承認を求めるタイミング |
|---|---|
| untrusted | 状態を変えるコマンドの実行時 |
| on-request | サンドボックス外の編集、またはネットワークアクセス時 |
| never | 求めない（非対話実行向け） |
低摩擦さと安全さのバランスを取るなら、workspace-write＋on-requestの組み合わせから始めるのが妥当です。
# ~/.codex/config.toml
model = "gpt-5.6"
sandbox_mode = "workspace-write"
approval_policy = "on-request"danger-full-accessとneverを組み合わせると、承認なしでシステム全体に書き込める状態になります。公式ドキュメントも、この組み合わせは高信頼な自動化向けだと注記しています（出典: Codex公式ドキュメント）。
05プロジェクトごとのセットアップでAGENTS.mdと信頼設定を効かせる
プロジェクト直下の.codex/config.tomlは、そのプロジェクトが信頼されている場合だけ読み込まれます。プロジェクトローカルのhooksも同じ扱いです（出典: Codex公式ドキュメント）。信頼されていないプロジェクトでは、ユーザー設定（~/.codex/config.toml）だけが有効になります。
# プロジェクト直下 .codex/config.toml（信頼されたプロジェクトのみ有効）
sandbox_mode = "workspace-write"
approval_policy = "on-request"AGENTS.mdの読み込みには順序があります。グローバルの~/.codexディレクトリでAGENTS.override.mdがあればそちらを優先し、なければAGENTS.mdを読みます。プロジェクト側はGitルートから作業ディレクトリへ下りながら各階層を確認し、ルートから現在地へ向かう順で連結します（出典: Codex公式ドキュメント）。下位のファイルが上位の指示を上書きする構造です。
読み込むバイト数には上限があり、既定はproject_doc_max_bytesの32KiBです（出典: Codex公式ドキュメント）。プロジェクトの指示が長くなるほど、この上限に近づきます。
MCPサーバーはconfig.tomlのmcp_serversセクションに書くか、CLIから追加します。
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]codex mcp add context7 -- npx -y @upstash/context7-mcpセクション名はmcp_serversとアンダースコア区切りで、綴りを誤ると設定が反映されません（詳細は次章のつまずきポイント2）。
06Codex CLIのセットアップでつまずきやすい4つの落とし穴
- バージョンが更新されているのに古いまま動く：実体がChatGPT.app同梱の場合、アプリ更新でファイルの中身が変わります。シェル側がコマンドの場所をキャッシュしていると、更新後も古い実体を呼び続けます。
hash -r（zshはrehash）で解決します。 - MCPサーバーを登録したのに一覧に出ない：
config.tomlのセクション名をmcp-serversのようにハイフンで書くと、キーが一致せず設定は静かに無視されます。mcp_serversとアンダースコアで書き直し、保存後に再起動して確認します。 - プロジェクト側の設定が反映されない：プロジェクトが信頼されていないと、
.codex/config.tomlの内容は読み込まれません（出典: Codex公式ドキュメント）。初回起動時の信頼確認に答えているかを確認します。 --full-autoが非推奨だと知らずに使う：codex execのこのフラグは非推奨です。公式ドキュメントは--sandbox workspace-writeへの置き換えを勧めています（出典: Codex公式ドキュメント）。古い社内メモや記事に残っていた例をそのままコピーすると起こります。
07動作確認｜Codex CLIのセットアップが終わったら、設定と使い方を3ステップで確かめる
合格の基準は3つです。①バージョン確認、②非対話実行の確認、③信頼プロンプトの確認です。
# ①期待したバージョン文字列が返るか
codex --version
# ②承認プロンプトで止まらず、終了コード0で返るか
codex exec "echo setup-check" --sandbox read-only --ask-for-approval never --json
echo "exit code: $?"③は、まだ一度もCodexを実行していない新しいプロジェクトフォルダでcodexを起動し、信頼するかどうかの確認が一度は表示されることを見ます。3つとも満たせば、実行ファイルの所在・権限設定・プロジェクト連携が揃った状態です。
08FAQ
Codex CLIとClaude Codeを両方使う場合、設定ファイルは分ける必要がありますか
はい。方式が別です。CodexはTOML形式の~/.codex/config.toml、Claude CodeはJSON形式のsettings.jsonで、キー体系も異なります。AGENTS.mdとCLAUDE.mdも別ファイルとして両方用意します。
sandbox_modeとapproval_policyは、どちらを先に決めるべきですか
sandbox_modeを先に決めます。実行できる範囲の上限を決めてから、その範囲内でどこまで自動承認するかを決める順番のほうが、想定外の書き込みを防げます。
認証はAPIキーとChatGPTサインインのどちらを使うべきですか
上の認証方法の表のとおり、用途で分けます。両方式とも公式ドキュメントに記載があります。
config.tomlを直接編集せず、CLIだけで設定を変えられますか
一部は可能です。--sandboxや--ask-for-approvalのようなグローバルフラグは実行時に上書きでき、MCPサーバーはcodex mcp addで追加できます。信頼設定や恒久的な既定値の変更は、config.tomlを直接編集するほうが確実です。
