Codex CLI 承認モード&サンドボックス:安全制御の2層構造を理解する
OpenAI Codex CLI の承認ポリシーとサンドボックスの2層構造を徹底解説。on-request・never・untrusted・granular の各モード、macOS/Linux/Windows の OS 別サンドボックス実装、ネットワーク制御を 2026 年 5 月時点の公式仕様に合わせてまとめました。
この章の要点
Codex CLI の安全制御は**承認ポリシー(approval_policy)とサンドボックス(sandbox_mode)**の 2 層で独立に動きます。
- 承認ポリシー: 「いつユーザーに確認を求めるか」
- サンドボックス: 「OS レベルで何を許可するか」
2 層が独立しているため、「ワークスペース内のファイル編集は確認なしで進めるが、ネットワークアクセスは OS 側で禁止する」といった組み合わせができます。設定は ~/.codex/config.toml または起動時のフラグで指定します。
承認ポリシー(approval_policy)
config.toml のトップレベル approval_policy か、CLI フラグ --ask-for-approval(短縮 -a)で指定します。
ポリシーの種類
| ポリシー | 確認が求められるタイミング |
|---|---|
on-request(推奨デフォルト) | サンドボックスを離れる操作・ネットワークアクセス・副作用のある MCP ツール呼び出しなどで確認 |
never | 承認プロンプトを無効化(サンドボックス制限は残る) |
untrusted | 信頼済みコマンドセット外の操作で確認を求める |
granular | カテゴリごとに boolean で個別制御 |
CLI フラグでの指定
codex --sandbox workspace-write --ask-for-approval on-request
codex --sandbox read-only --ask-for-approval untrusted
codex -a never
config.toml での指定
# ~/.codex/config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
granular(細かい制御)
granular は boolean のキー集合で、それぞれのカテゴリで承認プロンプトを出すかどうかを切り替えます。
approval_policy = { granular = {
sandbox_approval = true, # サンドボックスエスカレーション
rules = true, # execpolicy ルール一致時のプロンプト
mcp_elicitations = true, # MCP サーバーからのプロンプト
request_permissions = false, # 追加権限要求のプロンプト
skill_approval = false, # スキルスクリプトの承認
} }
true で確認プロンプトを表示し、false でプロンプトを省略します(自動的に拒否またはスキップ)。各キーの厳密な真理値表は公式に明記されていないため、運用前に対象環境で挙動を確認してください。
セッション中の承認モード変更
セッション中に /permissions コマンドでモードをインタラクティブに切り替えられます。たとえばチャットや計画モードに入った時点で read-only に降格するといった運用が可能です。
# Codex セッション内
/permissions
実行すると現在の承認ポリシーとサンドボックスモードが表示され、選択肢から切り替えられます。具体的な TUI の表示文言はバージョンによって変わる場合があります。
サンドボックス(sandbox_mode)
サンドボックスは承認ポリシーから独立した OS レベルの実行制限です。承認ポリシーが never でもサンドボックスが許さない操作は実行できません。
サンドボックスモード
| モード | 制限内容 |
|---|---|
read-only | ファイル参照のみ。編集・コマンド実行は承認必須 |
workspace-write(既定の低摩擦モード) | ワークスペース内の読み書き・ローカルコマンド実行が可能 |
danger-full-access | サンドボックス制限を完全解除 |
codex --sandbox read-only
codex --sandbox workspace-write
codex --sandbox danger-full-access # ⚠️ セキュリティ制限なし
workspace-write の拡張キー
ワークスペース外への書き込みやネットワーク利用を限定的に許可したい場合は sandbox_workspace_write ブロックで上書きできます。
[sandbox_workspace_write]
writable_roots = ["/var/log/myapp"] # 追加で書込許可するルート
network_access = false # ワークスペース書込時のネット可否
exclude_slash_tmp = false # /tmp を書込対象から除外するか
exclude_tmpdir_env_var = false # TMPDIR を書込対象から除外するか
OS 別サンドボックスの実装
Codex CLI はプラットフォームごとに OS ネイティブのサンドボックス機構を使います。
macOS: Seatbelt(sandbox-exec)
macOS では追加インストールなしで Apple の Seatbelt(sandbox-exec)が使われます。
Linux/WSL2: bubblewrap
Linux と WSL2 では bwrap(bubblewrap)が必要です。AppArmor が有効な環境では追加設定が必要になることがあります。
# Ubuntu/Debian
sudo apt install bubblewrap
# Fedora/RHEL
sudo dnf install bubblewrap
# 確認
which bwrap
Windows: ネイティブ Windows Sandbox + WSL2
Windows ではネイティブ Windows Sandbox と WSL2 の双方をサポートしています。プロファイル単位で挙動を上書きする場合は profiles.<name>.windows.sandbox を指定します。
2026 年 5 月(v0.129.0)の更新で Windows サンドボックスは名前付きパイプアクセス、ConPTY 終了、PowerShell の allow ルール、worktree の
safe.directoryなどの信頼性が改善されました。Linux 側でも古いbwrap・シンボリンク保護・共有/tmpの取り回しが安定化しています。
機密ディレクトリの保護
サンドボックスはデフォルトで OS の機密領域(システムディレクトリや SSH/GPG の鍵置き場など)への書き込みをブロックします。読み取りをさらに禁止したい場合は permissions.filesystem.deny_read でパス・glob を明示的に指定できます(管理者強制設定は requirements.toml)。
# requirements.toml(管理者強制)
[permissions.filesystem]
deny_read = ["~/.ssh/**", "~/.gnupg/**"]
ネットワーク制御
サンドボックスはデフォルトでネットワークアクセスを禁止します。許可する場合は名前付きの permissions プロファイルでドメインや UNIX ソケットを列挙します。
# ~/.codex/config.toml
[permissions.default.network]
enabled = true
mode = "limited" # limited | full
[permissions.default.network.domains]
"api.github.com" = "allow"
"registry.npmjs.org" = "allow"
"*.anthropic.com" = "allow"
"*.internal.example" = "deny"
[permissions.default.network.unix_sockets]
"/tmp/my-service.sock" = "allow"
プロキシを必須化したい場合は同セクションに proxy_url / socks_url / enable_socks5 を指定します。
プロファイルによる環境別設定
作業内容ごとに複数の権限プロファイルを定義し、起動時に切り替えられます。
# ~/.codex/config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[profiles.strict]
approval_policy = "untrusted"
sandbox_mode = "read-only"
[profiles.autonomous]
approval_policy = "never"
sandbox_mode = "workspace-write"
[permissions.autonomous.network]
enabled = true
mode = "limited"
[permissions.autonomous.network.domains]
"api.github.com" = "allow"
codex --profile strict
codex --profile autonomous
管理者強制設定(requirements.toml)
組織で配布する設定では、ユーザーが選択できる値を絞り込めます。
# requirements.toml
allowed_sandbox_modes = ["read-only", "workspace-write"]
allowed_approval_policies = ["on-request", "untrusted"]
allowed_web_search_modes = ["disabled", "cached"]
[[rules.prefix_rules]]
pattern = [{ token = "rm" }, { token = "-rf" }]
decision = "forbidden"
justification = "破壊的削除を禁止"
Claude Code との安全モデル比較
| 観点 | Codex CLI | Claude Code |
|---|---|---|
| サンドボックス | OS レベル(Seatbelt / bubblewrap / Windows Sandbox) | プロセスレベル(Hooks によるブロック) |
| ネットワーク制御 | OS レベルで制限(デフォルト無効) | Hooks で制限(デフォルト有効) |
| 権限モデル | approval_policy × sandbox_mode の 2 層 | パーミッションモード × Hooks の 2 層 |
| 設定の粒度 | ドメイン・UNIX ソケット・glob 単位 | ツール名・コマンドパターン単位 |
Codex CLI は OS レベルのサンドボックスが標準のため、想定外の操作をより確実に遮断できます。Claude Code は Hooks による柔軟なカスタマイズが強みです。
注意点・セキュリティ観点
workspace-write は「何でもできる」ではない
書込許可の範囲が広がるだけで、機密ディレクトリやネットワークは引き続き制限されます。sandbox_workspace_write.network_access を明示的に true にしない限り、外部通信は通りません。
ネットワーク既定無効で npm install が失敗する
パッケージ取得が必要なタスクは事前に [permissions.default.network.domains] で registry.npmjs.org などを allow してから起動してください。
Linux/WSL2 では bwrap のインストールが必須
未導入の環境では workspace-write サンドボックスが立ち上がりません。CI イメージにも bubblewrap を追加する必要があります。
danger-full-access は最終手段
サンドボックスが完全に外れるため、悪意のあるコードや予期しない副作用が直接ホストに到達します。テスト・研究目的以外では避けてください。
granular は boolean のみ
granular のキーは true(プロンプトを出す)/false(プロンプトを出さない=自動拒否相当)の 2 値で、on-request のような文字列は受け付けません。