Codex CLIの設定と使い方｜最初に決める4つと動作確認3つ

「codexと打てば動きます。ただ、これがどのファイルなのかは、正直わかっていません」。導入を終えた現場から、この言葉が出てきます。

動いているうちは困りません。困るのは、アプリを更新したあとに挙動が変わったときと、決まった時刻に走らせる仕組みから呼んだときです。手元では動くのに、そちらからは見つからない。設定ファイルをいくら読み返しても、原因はそこに書いていません。

この記事は、Codex CLIの設定と使い方を、実行ファイルの所在を確かめるところから順に組み立てます。素材は公式ドキュメント8件と、自社の検証環境です（learn.chatgpt.com、旧developers.openai.com/codex、2026-07-28閲覧時点）。

01「codex cli 設定 使い方」で調べた人は、AIエージェントの何から手をつければいいんですか？

高梨課長

高梨課長の発言

検索すると、入れる手順ばかり出てきます。入れたあとに何を決めるのかが知りたいんですが。

鈴木さん

鈴木さんの発言

合鍵を配る前に、どの部屋まで入ってよいかを決める作業に近いと思っています。鍵そのものより、どこまで開けておくかのほうが後で効いてきます。

Codex CLIは、単体のインストーラーで導入する場合があります。ChatGPTのデスクトップアプリに同梱された実行ファイルとして存在する場合もあります（出典: Codex公式ドキュメント）。同じcodexというコマンド名でも、環境によって実体のファイルが違うことがある。ここが出発点です。

このセットアップで決めることは、下表の4つです。

もう1つ、先に知っておくと迷いが減ることがあります。設定は1か所では決まりません。実行時のフラグ、プロジェクトの設定、プロファイル、ユーザー設定、システム設定、そして組み込みの既定値が、この順で重なって最終的な値になります。

プロジェクトの設定だけは、そのプロジェクトが信頼されている場合にだけ通ります。信頼されていなければ、その段は飛ばされ、ユーザー設定へ落ちます。

sandbox_modeとapproval_policyも、この重なりの結果として確定します。config.tomlに書いたのに効かないときは、上の段で別の値が勝っている可能性を先に疑います。

02設定を始める前に、AI導入の前提として何を3つ確かめるんですか？

セットアップに入る前に、3つを確認します。

1つ目は、OSとインストール方法を問わず、codexコマンドがPATH上で解決できるか、絶対パスで直接呼べる状態かです。2つ目は認証方法です。3つ目は、設定変更を許すディレクトリの範囲です。

認証は、ChatGPTアカウントでのサインインと、APIキーによる認証の両方が用意されています（出典: Codex公式ドキュメント）。

分かれ目は、画面の前に人がいるかどうかです。人がいる前提の入口を、人がいない場面へそのまま持ち込むと、確認を待ったまま止まります。

3つ目のディレクトリ範囲は、後述のsandbox_modeで決めます。ここだけは単独では決まらないので、権限の章まで持ち越します。

03codexコマンドの実体は、AIエージェントの設定でなぜ最初に確かめるんですか？

若葉さん

若葉さんの発言

同じ名前のコマンドなのに、中身が違うことがあるんですか。

鈴木さん

鈴木さんの発言

表札が同じでも、部屋が別ということがあります。うちでは、名前で呼んでいた相手が、いつのまにか入れ替わっていました。

最初の一歩は、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

ここを飛ばすと、あとの章の設定が「どこに効いているのか」を確かめられなくなります。手順書のとおりに書いたのに動かない、という相談の入口は、たいていここです。

04実体を絶対パスで固定する使い方は、AI社員の自動実行で何を守るんですか？

自社では、この絶対パスをCODEX_BINという環境変数に入れ、実行スクリプト側から明示的に参照する運用にしています。

エイリアスだけに頼ると、cronや自動実行スクリプトのように、シェル設定を経由しない場面で解決できないことがあるためです。人が打つときは動くのに、決まった時刻に動かす仕組みからは動かない。この差が生まれるのは、ここです。

# ~/.zshrc に追記する例
export CODEX_BIN="/Applications/ChatGPT.app/Contents/Resources/codex"
alias codex="$CODEX_BIN"

書くのは2行ですが、効く相手が違います。別名は人が打つ場面のための短縮で、環境変数は仕組みが呼ぶための宛先です。両方を置いておくと、どちらの経路からでも同じ実体に届きます。

05サンドボックスの3モードは、AIエージェントにどこまで触らせる設定なんですか？

Codexのサンドボックスは、read-only・workspace-write・danger-full-accessの3モードです（出典: Codex公式ドキュメント）。既定はworkspace-writeです。

3つの違いは、できることの多さというより、取り返しがつかなくなる範囲の広さです。読むだけなら、間違えても元に戻せます。制限が外れた状態では、戻す相手が残らないこともあります。

06承認方針とサンドボックスの組み合わせは、AIエージェントの使い方をどこで止めるんですか？

高梨課長

高梨課長の発言

権限は広いほうが速く終わりませんか。止まるたびに待つのは、けっこうな手間です。

鈴木さん

鈴木さんの発言

速くはなります。ただ、止まらない設定は、間違いのほうも止めません。うちは、確かめるときだけ止まらない側に寄せています。

承認のタイミングはapproval_policyで決めます。値はuntrusted・on-request・neverの3種類です（出典: Codex公式ドキュメント）。

低摩擦さと安全さのバランスを取るなら、workspace-write＋on-requestの組み合わせから始めるのが妥当です。

# ~/.codex/config.toml
model = "gpt-5.6"
sandbox_mode = "workspace-write"
approval_policy = "on-request"

danger-full-accessとneverを組み合わせると、承認なしでシステム全体に書き込める状態になります。公式ドキュメントも、この組み合わせは高信頼な自動化向けだと注記しています（出典: Codex公式ドキュメント）。

2つは別々の軸です。サンドボックスは技術的にできる範囲を決め、承認方針はどの場面で人に聞くかを決めます。片方だけを絞っても、もう片方が開いていれば、狙った場所では止まりません。

もう一方のエンジンと並べて考えたいときは、Claude Code側の権限の配分に別の軸の整理があります。

07プロジェクトごとの設定と信頼は、エージェントの使い方をどう変えるんですか？

プロジェクト直下の.codex/config.tomlは、そのプロジェクトが信頼されている場合だけ読み込まれます。プロジェクトローカルのhooksも同じ扱いです（出典: Codex公式ドキュメント）。信頼されていないプロジェクトでは、ユーザー設定（~/.codex/config.toml）だけが有効になります。

# プロジェクト直下 .codex/config.toml（信頼されたプロジェクトのみ有効）
sandbox_mode = "workspace-write"
approval_policy = "on-request"

厄介なのは、読み込まれなくてもエラーにならないことです。書いた側は反映されたつもりでいて、動きだけが違う。書いたのに効かないと感じたら、まず信頼の状態から疑います。

08AGENTS.mdの読み込み順の設定は、AIエージェントへの指示のどれが最後に効くんですか？

若葉さん

若葉さんの発言

指示書が何枚もあるとき、どれが最後に効くんですか。

鈴木さん

鈴木さんの発言

近いところに置いたものが後に効きます。廊下の張り紙より、その部屋の張り紙のほうが強い、という順番です。

AGENTS.mdの読み込みには順序があります。グローバルの~/.codexディレクトリでAGENTS.override.mdがあればそちらを優先し、なければAGENTS.mdを読みます。プロジェクト側はGitルートから作業ディレクトリへ下りながら各階層を確認し、ルートから現在地へ向かう順で連結します（出典: Codex公式ドキュメント）。下位のファイルが上位の指示を上書きする構造です。

順番が分かると、置き場の決め方も変わります。全体に効かせたい約束は上へ、その場かぎりの断り書きは下へ。同じ内容を両方に書くと、あとから読んだほうだけが残ります。

読み込むバイト数には上限があり、既定はproject_doc_max_bytesの32KiBです（出典: Codex公式ドキュメント）。プロジェクトの指示が長くなるほど、この上限に近づきます。

09MCPを足す使い方は、AIエージェントに外部ツールをどう触らせるんですか？

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とアンダースコア区切りです。綴りを誤ると設定が反映されません。しかも、エラーで止まるのではなく、静かに無視される形になります（この落とし穴は次章で扱います）。

接続そのものの考え方をもう一段見たいときは、MCPサーバーの接続設定にまとめてあります。

10設定が効かないとき、AI活用が止まるのはどの4か所ですか？

1. バージョンが更新されているのに古いまま動く：実体がChatGPT.app同梱の場合、アプリ更新でファイルの中身が変わります。シェル側がコマンドの場所をキャッシュしていると、更新後も古い実体を呼び続けます。hash -r（zshはrehash）で解決します。
2. MCPサーバーを登録したのに一覧に出ない：config.tomlのセクション名をmcp-serversのようにハイフンで書くと、キーが一致せず設定は静かに無視されます。mcp_serversとアンダースコアで書き直し、保存後に再起動して確認します。
3. プロジェクト側の設定が反映されない：プロジェクトが信頼されていないと、.codex/config.tomlの内容は読み込まれません（出典: Codex公式ドキュメント）。初回起動時の信頼確認に答えているかを確認します。
4. --full-autoが非推奨だと知らずに使う：codex execのこのフラグは非推奨です。公式ドキュメントは--sandbox workspace-writeへの置き換えを勧めています（出典: Codex公式ドキュメント）。古い社内メモや記事に残っていた例を、そのままコピーすると起こります。

4つに共通しているのは、どれも大きな音を立てないことです。画面は静かなまま、意図とは違う設定で動き続けます。だから、思い出そうとするのではなく、見にいく場所を先に決めておきます。

11検索語の「codex cli 設定 使い方」は、AI社員に任せる前のどの動作確認に置き換わるんですか？

高梨課長

高梨課長の発言

どこまでやれば「設定が終わった」と言えるんでしょう。

鈴木さん

鈴木さんの発言

3つ返ってくれば、いったん終わりにしています。名乗るか、止まらずに終わるか、はじめての場所でちゃんと聞いてくるか。

合格の基準は3つです。①バージョン確認、②非対話実行の確認、③信頼プロンプトの確認です。

# ①期待したバージョン文字列が返るか
codex --version

# ②承認プロンプトで止まらず、終了コード0で返るか
codex exec "echo setup-check" --sandbox read-only --ask-for-approval never --json
echo "exit code: $?"

③は、まだ一度もCodexを実行していない新しいプロジェクトフォルダでcodexを起動し、信頼するかどうかの確認が一度は表示されることを見ます。

3つとも満たせば、実行ファイルの所在・権限設定・プロジェクト連携が揃った状態です。②で読むだけの設定と止まらない設定を組み合わせているのは、確かめる行為そのものが何かを書き換えないようにするためです。

検索語のままでは、現場では使えません。「設定と使い方を調べる」は、この3つが返るかどうかに翻訳できます。返らなければ、設定ではなく前提のほうを疑います。

12よくある質問

13まとめ｜今日やる3つのこと

Codex CLIの設定と使い方は、いま動いている実行ファイルの所在から始まり、触らせる範囲と止まる場所の組み合わせで決まります。書いたのに効かないときは、たいてい上の段で別の値が勝っているか、静かに無視されています。