AI Hub

Codex

Codexのサンドボックスと承認モード｜安全設定を解説

公開: / 更新: ・読了目安8分

#サンドボックス #設定

Codexのサンドボックスと承認モード｜安全設定を解説

先に結論: Codexの安全設計は、実行範囲を決めるsandbox_modeと確認タイミングを決めるapproval_policyという独立した2層で構成されます。日常の開発作業にはworkspace-writeとon-requestの組み合わせが推奨されます。

Codexにコードの実行や編集を任せる際、「どこまで自動でやらせて安全か」を左右しているのがサンドボックスと承認モードという2つの仕組みです。この記事では両者の役割分担と、安全な組み合わせの具体例に絞って解説します。

「Codex CLIの使い方」で承認モードの3段階を紹介済みですが、ここではsandbox_modeとapproval_policyの正式な値と、config.toml・CLIフラグでの設定方法まで踏み込みます。

この記事の要点

  • Codexの安全設計は「サンドボックス(sandbox_mode)」と「承認ポリシー(approval_policy)」という独立した2層で構成されます。
  • sandbox_modeにはread-only・workspace-write(既定)・danger-full-accessの3種類があります。
  • approval_policyにはuntrusted・on-request(既定)・on-failure・neverの4種類があります。
  • 日常の開発作業にはsandbox_mode = "workspace-write"とapproval_policy = "on-request"の組み合わせが推奨されます。
  • danger-full-accessとneverの組み合わせは隔離と承認の両方を失う、もっとも危険な設定です。

前提・動作環境

この記事はCodex CLI導入済みを前提に解説します。導入手順や全体像は「Codexの使い方完全ガイド」参照。

項目名や既定値は今後変わる可能性があるため2026年8月時点の内容とし、異なる場合は公式サイト(developers.openai.com/codex)で確認してください。

サンドボックスと承認ポリシーという2層構造

サンドボックス(sandbox_mode、技術的にできる範囲)と承認ポリシー(approval_policy、確認を求めるタイミング)が独立した2層であり、両方を組み合わせて初めて安全域が決まることを示す図

Codexの安全設計は、「サンドボックス」と「承認ポリシー」という独立した2つの仕組みで成り立ち、役割は明確に分かれています。

この2つは独立したパラメータであり、どちらか一方だけを厳しくしても安全性は保たれません。サンドボックスを厳しくしても承認ポリシーをneverにすれば範囲内の操作は無警告で進みますし、逆に承認ポリシーを厳しくしてもサンドボックスをdanger-full-accessにすれば承認済み操作がシステム全体に影響します。両方を意図して組み合わせて初めて安全域が作れます。

sandbox_modeの3種類と挙動

sandbox_modeには次の3つの値があります。

いずれもOS側のファイルシステム保護・ネットワーク制御機構で隔離を実現しており、承認ポリシーが緩くてもこの範囲は技術的に強制されます。

approval_policyの4種類と挙動

approval_policyは、Codexが人間に確認を求める場面を決めます。主な値は次の4つです。

実用レシピ3つ

代表的な組み合わせを3パターン紹介します。

3つの実用レシピを階段状に示す図。初めてのリポジトリはread-only+untrusted、日常の開発作業はworkspace-write+on-requestでもっともバランスが良く、CI・自動実行はworkspace-write+neverだが隔離は維持されることを示す

1. 初めて触るリポジトリ・慎重に進めたい場合

sandbox_mode = "read-only"
approval_policy = "untrusted"

編集やコマンド実行はほぼ発生せず、調査や提案の受け取りに限定されます。挙動を把握してから次のレシピへ移行すると安全です。

2. 日常の開発作業

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

ワークスペース内の編集とローカルコマンドは自動で進み、境界を越える操作だけ確認が入ります。もっともバランスの良い既定の組み合わせで、多くの開発作業はこのまま進められます。

3. CIやバッチ処理など自動実行

sandbox_mode = "workspace-write"
approval_policy = "never"

人が張り付いて承認できない環境向けの設定です。承認プロンプトは出ませんが、サンドボックスの境界(書き込み範囲・ネットワーク遮断)は維持され、被害範囲は限定されます。

実行するコマンドやリポジトリ、認証情報があらかじめ統制されていることが前提で、未検証のスクリプトや外部入力をそのまま流し込む用途には向きません。

config.tomlでの設定例・CLIフラグでの一時変更

既定値は~/.codex/config.tomlにまとめて書けます(書式は「config.tomlの設定方法」参照)。抜粋すると先ほどのレシピ2と同じ内容です。

ワークスペース外の特定ディレクトリだけ書き込み可能にしたい場合は[sandbox_workspace_write]にwritable_roots = ["/tmp"]と追記します。

セッション単位の一時変更は、起動時のCLIフラグで上書きできます。

codex --sandbox read-only --ask-for-approval untrusted
codex --full-auto

--full-autoはworkspace-writeと緩めの承認ポリシーを組み合わせるショートカットで、日常的な自動化用途に使われます。フラグはconfig.tomlより優先されるため、普段は安全側の既定値をconfig.tomlに置き、必要なときだけフラグで緩めるのが基本です。

危険な組み合わせに注意

danger-full-accessとneverの組み合わせは、隔離と承認の両方を同時に失う、もっとも危険な設定です。承認とサンドボックスを丸ごと無効化する専用フラグでも同様の状態になり、いずれも推奨されません。無制限アクセスの状態で無警告に実行されるため、外部入力で取り返しのつかない変更が加わるリスクがあります。使うとしても、隔離した使い捨てのコンテナ環境など被害が閉じ込められる範囲に限定してください。

つまずきポイント/よくあるエラー

よくある質問

sandbox_modeとapproval_policyはどちらか一方だけ設定すれば十分ですか?

不十分です。サンドボックスは「技術的にできる範囲」、承認ポリシーは「確認を求めるタイミング」を決める別々のパラメータで、両方を組み合わせて初めて安全な運用になります。

workspace-writeでネットワークアクセスを許可すると何が変わりますか?

network_accessをtrueにすると、パッケージインストールなど外部通信を伴う操作が可能になります。意図しない通信リスクも増えるため、必要な作業のときだけ有効にするのが安全です。

承認モードとサンドボックスの設定はプロジェクトごとに変えられますか?

変えられます。config.tomlにプロファイルを複数用意し--profileで切り替えるほか、起動時のCLIフラグで一時的に上書きも可能です。書き方は「config.tomlの設定方法」で解説しています。

まとめ

Codexの安全設計は、実行範囲を決める「サンドボックス(sandbox_mode)」と、確認タイミングを決める「承認ポリシー(approval_policy)」という独立した2層で成り立っています。

read-only・workspace-write・danger-full-accessの3段階と、untrusted・on-request・on-failure・neverの4種類を用途に応じて組み合わせるのが基本です。

初めてのリポジトリはread-only、日常作業はworkspace-write+on-request、CIなど自動実行は隔離を維持したままneverにする、という3レシピを起点に調整してください。

基本操作は「Codex CLIの使い方」、設定ファイルは「config.tomlの設定方法」、全体像は「Codexの使い方完全ガイド」もあわせてご覧ください。

Claude Codeにも同様の隔離機能があり、「Claude Code Sandboxの使い方」で解説しています。