Codex CLI を調べていると、説明が食い違っている記事に出くわします。
「suggest / auto-edit / full-auto の三段階で切り替えます」と書いてあるものと、「サンドボックスと承認ポリシーを組み合わせます」と書いてあるもの。どちらが正しいのか分からなくなる。
答えを先に書きます。後者が現在の形です。
以前は三段階のモードで指定していましたが、いまは「触れる範囲」と「止まって聞くタイミング」が、別々の設定になっています。この2つを組み合わせて使います。
古い記事が残っているので混乱しますが、仕組みが分かれば、むしろこちらのほうが分かりやすいです。

この記事で分かること
- 基本の頼み方
- サンドボックスと承認ポリシーの違い
- 目的別の組み合わせ
- 古い記事の三段階モードとの対応
- 止め方と、やり直し
1. 基本の使い方
1-1. 2つの動かし方があります
対話モードで起動する。
codex やり取りを続けながら作業します。長い作業には、こちらが向いています。
1回だけ実行する。
codex "このリポジトリが何をするものか説明してください" 聞いて、答えて、終了します。短い用事には、こちらが速いです。
1-2. どこで起動するかが大事です
作業したいプロジェクトのフォルダで起動してください。
Codex は、起動したフォルダとその中身を見ます。上の階層で起動すると、関係のないファイルまで読みにいって、時間もクレジットも余計に消費します。
cd ~/projects/my-app
codex 1-3. 頼み方の基本
日本語で頼めます。ただ、曖昧な言い方は通じません。
× この関数をいい感じに整理して
○ この関数を、20行以内になるように分割して。
分割した関数には、何をするかが分かる名前を付けて 「読みやすく」「適切に」といった基準は、人によって違います。 こちらの頭の中にしかない基準は、伝わりようがありません。
1-4. 一度に全部を頼まない
大きな依頼を丸ごと投げると、全体としては形になるのに、細部が雑になります。 しかも、どこがまずいのかを探すのが大変です。
まず、どう直すつもりかを説明してください。
実際の変更は、確認してからお願いします 分けて頼むほうが、結果的に早いです。方向が違っていたときに、戻る距離が短くて済みます。
2. 2つの軸を理解する
ここが、この記事の中心です。
2-1. 役割が違う2つの設定
Codex の自動化は、役割の違う2つの設定を組み合わせて作ります。
サンドボックス。 Codex が触れられる対象を決めます。ファイル、ネットワーク。
承認ポリシー。 Codex が作業を止めて確認する場面を決めます。
この2つは、独立して効きます。 ここが大事です。
たとえば「承認は要らない」と設定しても、サンドボックスが読み取り専用なら、書き込みは弾かれます。 逆に、サンドボックスを広げても、承認ポリシー次第では毎回止まります。
2-2. サンドボックスの種類
| 設定 | 触れる範囲 |
|---|---|
| 読み取り専用 | ファイルを読むだけ。書き換えない |
| ワークスペース書き込み | 作業フォルダの中なら書き換えてよい |
| 全アクセス | 制限なし(通常は使わないでください) |
普段使うのは、真ん中です。 プロジェクトのフォルダの中は自由に触れて、その外には出られない。この状態が、いちばんバランスが取れています。
codex --sandbox workspace-write 2-3. 承認ポリシーの種類
| 設定 | 止まるタイミング |
|---|---|
| 要求時に確認 | サンドボックスの範囲を超える操作のときに聞く |
| 確認しない | 止まらない。範囲外の操作はブロックされる |
「確認しない」を選んだ場合の挙動が、少し分かりにくいので補足します。
止まらないのですが、サンドボックスの外に出ようとする操作は、承認を求められるのではなく、そのまま拒否されます。 つまり「聞かずに実行する」のではなく「聞かずに止める」動きになります。
codex --sandbox workspace-write --ask-for-approval on-request これが、日常的に使いやすい組み合わせだと思います。プロジェクトの中は自由に作業でき、外に出るときだけ確認が入ります。
2-4. なぜ2つに分かれているのか
一見すると面倒ですが、組み合わせられるのが利点です。
「書き換えは自由にしていいが、外部への通信は必ず確認したい」といった調整ができます。1つのスイッチでは、こうした細かい設定はできません。
3. 目的別の組み合わせ

実際の場面ごとに、おすすめの設定を書きます。
3-1. まず様子を見たい
読み取り専用で起動します。
codex --sandbox read-only ファイルを一切書き換えません。 「このコードは何をしているのか」「どこを直せばいいか」を聞くだけなら、これで十分です。
初めてのプロジェクトで試すときは、まずこれから始めるのが安全です。
3-2. 普段の作業
codex --sandbox workspace-write --ask-for-approval on-request プロジェクトの中は自由に、外に出るときだけ確認。 日常的にはこれで問題ないと思います。
3-3. 止まらずに走らせたい
テストを回しながら直させる、といった繰り返し作業では、いちいち止まると煩わしいことがあります。
その場合、承認を「確認しない」にします。 ただし、サンドボックスは広げないでください。
範囲外の操作はブロックされるので、暴走はしません。 ここが大事な点です。
3-4. やってはいけない組み合わせ
codex --yolo サンドボックスも承認も、両方なしという設定です。
何が起きても止まりません。 使い捨ての環境や、壊れても困らないコンテナの中でない限り、使わないでください。
同じことが、設定ファイルでも指定できます。個人の全体設定に書かないでください。 必要なときだけ、その場で指定する形にしてください。
4. 古い記事との対応
検索すると、三段階のモードで説明している記事が出てきます。混乱しないよう、対応を書いておきます。
| 古い書き方 | いまの考え方 |
|---|---|
| suggest | 読み取り専用に近い。提案はするが、変更には承認が要る |
| auto-edit | ファイルの編集は自動、コマンド実行の前に確認 |
| full-auto | サンドボックス内なら、編集もコマンドも自動 |
書き方が変わっただけで、やりたいことは同じです。
ただ、古いフラグがそのまま使えるとは限りません。 記事に載っているコマンドがエラーになったら、世代が違う可能性を疑ってください。
手元で使える形は、これで確認できます。
codex --help この記事の内容と食い違っていたら、そちらが正しいと思ってください。
5. 途中で切り替える
起動したあとでも、設定を変えられます。
/approvals 承認まわりの設定を、その場で変更できます。
作業の性質が変わったときに使います。 調査のあいだは読み取り専用、実装に入るときに書き込みを許可する、といった切り替えです。
5-1. 更新でリセットされることがあります
注意点があります。Codex を更新すると、設定したモードが初期状態に戻ることが報告されています。
「昨日と同じはずなのに、やたら確認が出る」と感じたら、更新が入っていないか確認してください。
6. 止め方と、やり直し
6-1. 止める
動いている途中で止めたいときは、Ctrl + C です。
方向が違うと思ったら、遠慮なく止めてください。 最後まで走らせてから直すより、途中で止めて指示し直すほうが早く、クレジットの節約にもなります。
6-2. 変更を確認する
作業のあと、何が書き換わったのかは自分で確認してください。
git diff 6-3. Git を使ってください
これは強くおすすめします。
どの承認モードで使うにしても、Git のリポジトリの中で作業していれば、変更を戻せます。 これがあるかないかで、安心感がまったく違います。
まだ使っていないなら、練習用フォルダでもいいので、git init してから試してください。
git init
git add -A
git commit -m "作業前" これだけで、いつでも元に戻せる状態になります。
7. プロジェクトのルールを渡す
毎回同じ説明をしているなら、ファイルに書いておけます。
プロジェクトのルートに AGENTS.md という名前で置くと、Codex が起動時に読み込みます。
# このプロジェクトについて
- PHP 8.1 以上で動作します
- 関数は20行以内、ネストは3段まで
- 出力は表示の直前にエスケープしてください
- vendor/ と node_modules/ の中は編集しないでください 「読みやすく」ではなく、判定できる形で書くのがコツです。詳しくは第4回で扱います。
8. 最初にやってはいけないこと
大事なファイルがあるフォルダで、いきなり試さない。 まずは練習用のフォルダで慣れてください。
Git のない状態で、書き込みを許可しない。 戻せなくなります。
--yolo を試しに使ってみない。 「どうなるか見てみよう」で使うものではありません。
設定ファイルの全体設定に、強い権限を書かない。 うっかり常用することになります。
まとめ
- 動かし方は2通り。対話モードと1回だけ実行
- プロジェクトのフォルダで起動する。 上の階層だと余計に読み込む
- 自動化は2つの軸の組み合わせ。触れる範囲(サンドボックス)と止まる場面(承認ポリシー)
- この2つは独立して効く。 承認なしでも、サンドボックスが読み取り専用なら書き込めない
- 日常は「作業フォルダ内は書き込み可 + 範囲外は確認」が使いやすい
- 「確認しない」設定でも、範囲外の操作はブロックされるので暴走しない
--yoloは使わない。 壊れても困らない環境限定- 古い記事の三段階モードは、いまの2軸に置き換わっている。
codex --helpが正解 - 更新するとモードがリセットされることがある
- Git の中で作業する。 どのモードでも、戻せる状態を先に作る
設定の話が長くなりましたが、ここを一度整理しておくと、あとが楽です。 「勝手に書き換えられるのが怖い」という不安は、範囲を決めてしまえば消えます。
次回は、コマンドと起動オプションの一覧をまとめます。用途から引ける形にするので、手元に置いておく用の回になります。
※本記事の情報は2026年8月時点のものです。承認まわりの仕様は変更されることがあるため、最新の情報は codex --help および公式ドキュメントをご確認ください。


