Codex CLI の approval mode と sandbox 設定の違い:安全に自動実行させる組み合わせ
Codex CLI の承認ポリシー(approval)とサンドボックス(sandbox)の違いと組み合わせを解説します。各選択肢の意味、--full-auto の中身、config.toml での固定方法、ネットワーク制限の設定を紹介します。
目次
Codex CLI の安全性は、承認ポリシー(approval) と サンドボックス(sandbox) の 2 つの独立した設定で決まります。この 2 つを混同すると、「確認なしにしたのにコマンドが失敗する」「確認しているのにファイルが書き換わっていた」といった混乱が起きます。
この記事では、それぞれの選択肢の意味、組み合わせたときの挙動、用途別の推奨設定を整理します。
KEY POINT
この記事で分かること
- 承認ポリシーとサンドボックスの役割の違い
- 各選択肢の意味と、
--full-autoの中身 - 用途別(調査・日常開発・CI)の推奨設定と config.toml への書き方
2 つの設定の役割
| 設定 | 決めること | 効く場所 |
|---|---|---|
| approval(承認ポリシー) | 操作の前にユーザーへ確認するかどうか | Codex の判断・対話フロー |
| sandbox(サンドボックス) | 実行されるコマンドが OS レベルで何をできるか | macOS の Seatbelt、Linux の Landlock/seccomp などの OS 機構 |
承認は「聞くかどうか」、サンドボックスは「できるかどうか」です。承認を全部省略しても、サンドボックスが読み取り専用なら書き込みは物理的にできません。逆に、サンドボックスを全開放しても、承認が毎回入れば実行前に止められます。
承認ポリシーの選択肢
--ask-for-approval(短縮形 -a)または config.toml の approval_policy で指定します。
| 値 | 意味 |
|---|---|
untrusted | 安全と判断された読み取り系コマンド以外は毎回確認する。もっとも保守的 |
on-request | Codex が必要と判断したときだけ確認する(既定に近い挙動) |
on-failure | サンドボックス内で実行し、失敗したときだけ「サンドボックス外で再実行してよいか」を確認する |
never | 一切確認しない。失敗しても聞かずに進む。CI 向け |
用語解説
サンドボックス外での再実行: on-failure では、サンドボックスの制限(ネットワーク不可など)でコマンドが失敗した場合に、制限を外して再実行する許可を求めます。「npm install がネットワークで失敗した」ような場面で使われます。
サンドボックスの選択肢
--sandbox または config.toml の sandbox_mode で指定します。
| 値 | ファイル読み取り | ファイル書き込み | ネットワーク |
|---|---|---|---|
read-only | 可 | 不可 | 不可 |
workspace-write | 可 | ワークスペース(カレントディレクトリ配下)と一時領域のみ | 既定で不可(設定で許可可能) |
danger-full-access | 可 | どこでも | 可 |
workspace-write でも、.git ディレクトリへの直接書き込みは制限されることがあります。Git 操作は Codex が通常のコマンドとして実行するため、通常は問題になりません。
--full-auto の中身
--full-auto は、サンドボックスを workspace-write にし、承認を減らして自律的に進める省略形です。ワークスペースの外には書き込めず、ネットワークも既定では無効なので、「ワークスペース内なら自由にやってよい」という設定と理解してください。
codex --full-auto "テストが通るようにリファクタリングして"danger-full-access は隔離環境だけで使う
--sandbox danger-full-access と -a never の組み合わせは、任意のコマンドが確認なしに実行されます。ホスト環境では使わず、使い捨てのコンテナや CI ランナーに限定してください。--dangerously-bypass-approvals-and-sandbox も同様です。
用途別の推奨設定
| 用途 | approval | sandbox | 補足 |
|---|---|---|---|
| コードの調査・質問 | on-request | read-only | 誤って変更されない |
| 日常の開発 | on-request | workspace-write | 既定に近い。外部影響のある操作は確認される |
| 長い自律タスク(ローカル) | on-failure | workspace-write | 失敗時だけ判断する |
| CI・コンテナ内 | never | workspace-write または danger-full-access | 環境が使い捨てであることが前提 |
config.toml で固定する
毎回オプションを付けるのは面倒なので、~/.codex/config.toml に書きます。
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
# npm install などでネットワークが必要な場合に true にする
network_access = false用途ごとにプロファイルを分けておくと、--profile で切り替えられます。
[profiles.readonly]
approval_policy = "on-request"
sandbox_mode = "read-only"
[profiles.auto]
approval_policy = "on-failure"
sandbox_mode = "workspace-write"codex --profile readonly "この関数の呼び出し元を洗い出して"
codex --profile auto "lint エラーを全部直して"プロファイルの詳細は config.toml でモデルとプロファイルを切り替える を参照してください。
対話中に切り替える
セッション中は /approvals コマンドで承認モードを切り替えられます。調査だけのつもりで始めて、途中から実装に移るときに使います。
Claude Code との対応関係
Claude Code には OS レベルのサンドボックスの代わりに、ツール単位の permissions(allow / deny / ask)があります。「危険なコマンドを禁止する」という目的は同じですが、Codex は OS 機構で物理的に制限し、Claude Code はルールで制御する、という違いがあります。両者の比較は Codex と Claude Code の違いと使い分け で扱っています。
まとめ
- approval は「確認するか」、sandbox は「OS レベルで何ができるか」。独立した 2 つの設定
- 日常開発は
on-request+workspace-write、調査はread-only、CI はnever --full-autoはworkspace-writeで自律的に進める省略形。ワークスペース外やネットワークは制限されるdanger-full-accessとneverの組み合わせは隔離環境専用
よくある質問
- approval と sandbox はどう違いますか?
- approval は「実行前にユーザーへ確認するか」、sandbox は「実行時に OS レベルで何を許可するか」です。approval を never にしても、sandbox が read-only ならファイルは変更されません。
- --full-auto は危険ですか?
- --full-auto はワークスペース内の書き込みを許可し、確認を減らす設定です。ワークスペース外への書き込みやネットワークはサンドボックスで制限されるため、全許可(danger-full-access)よりは安全です。
- サンドボックス内でネットワークは使えますか?
- workspace-write では既定でネットワークが無効です。config.toml の sandbox_workspace_write.network_access で有効にできます。
参考にした一次情報
この記事は公式ドキュメントを基に AI が下書きを作成し、運営者が内容を確認して公開しています。誤りを見つけた場合はお問い合わせからお知らせください。