CodexのSandboxとApprovalは、AIがファイル、コマンド、ネットワークへどこまでアクセスできるかを制御する安全設定です。AGENTS.mdに「危険な操作をしない」と書くだけではなく、OSレベルの制限と承認ポリシーで実行そのものを止められます。
Sandboxは「技術的に許可する範囲」、Approvalは「どの場面で人間へ確認するか」を決めます。2つは別の設定です。たとえば承認ポリシーをneverにしても、Sandbox外の操作が自動許可されるわけではなく、許可されていない操作は失敗します。
この記事では、read-only、workspace-write、danger-full-accessの違い、untrusted、on-request、neverの使い分け、CLIとconfig.tomlの設定、Webアプリ開発での安全なプリセットを解説します。
情報確認日：2026年7月11日（日本時間）
結論：通常開発はworkspace-write＋on-request、調査はread-onlyから始める
この記事の結論
- コード調査は
read-onlyを基本にする - 通常のローカル開発は
workspace-writeとon-requestを候補にする - ネットワークは必要なタスクだけ有効にする
danger-full-accessや承認・Sandboxの完全回避を通常環境で使わない- 本番資格情報、デプロイ、DB変更、課金操作はCodexの外側でも制限する
SandboxとApprovalの違い
| 設定 | 決めること | 例 |
|---|---|---|
| Sandbox mode | OS上で技術的に許可する操作範囲 | 読み取りのみ、作業領域へ書き込み、制限なし |
| Approval policy | 操作を実行する前に人間へ確認する条件 | 信頼できない操作で確認、必要時に確認、確認しない |
Approvalで「許可」を押しても、Sandboxが実行を許さない場合は、より広い権限へ昇格する承認が必要になります。逆にSandboxで書き込み可能でも、Approvalポリシーによって確認が表示される場合があります。
Sandbox modeの3種類
read-only
ファイルの読み取りやコード探索を中心にし、作業領域への書き込みを許可しません。レビュー、影響範囲調査、設計相談、ログ分析に向いています。
- Pull Requestの読み取りレビュー
- 認証フローやデータフローの調査
- 依存関係や設定の確認
- 既存テストの一覧化
workspace-write
指定された作業領域へ書き込みを許可します。通常の機能追加、バグ修正、テスト作成に向きます。作業領域外やネットワークは別の制限を受けます。
- リポジトリ内のファイル編集
- テストやビルドによる生成物
- 作業用キャッシュ
- 承認されたコマンド実行
danger-full-access
Sandboxによる制限を大幅に外します。ホスト環境の広い範囲へアクセスできるため、通常のPCや秘密情報を持つ環境では避けます。
名前のとおり危険な設定です。どうしても必要な場合も、短命なコンテナや使い捨てVM、秘密情報なし、最小OS権限、外部ネットワーク制限という環境で使い、終了後に破棄します。
Approval policyの使い分け
untrusted
信頼できると判定された安全な読み取り操作などは進め、その他は承認を求めるポリシーです。Codexがどの操作を信頼扱いにするかを理解し、初期導入では承認内容をよく確認します。
on-request
Sandbox内で通常作業を進め、Sandbox外の操作や追加権限が必要な場面で承認を求めます。通常開発のバランスを取りやすい設定です。
never
人間への承認要求を行いません。これは「何でも自動で許可する」という意味ではありません。Sandbox外の操作は失敗し、Codexは許可範囲内で別の方法を試すか、失敗を報告します。
CIや非対話実行ではneverが必要になる場合がありますが、その場合はSandbox、OS権限、ネットワーク、トークンの権限を厳しく制限します。
用途別の組み合わせ
| 用途 | Sandbox | Approval | 補足 |
|---|---|---|---|
| コードレビュー | read-only |
neverまたはon-request |
外部ツールが不要ならネットワークも無効 |
| 通常の機能追加 | workspace-write |
on-request |
依存追加・ネットワーク・領域外操作で確認 |
| ローカルの自動テスト | workspace-write |
never |
コンテナ内でコマンドとネットワークを固定 |
| 未知のリポジトリ調査 | read-only |
never |
スクリプトを実行せず、別コンテナで読む |
| 本番運用 | 専用の限定環境 | 操作ごとに設計 | 通常のローカルCodex設定だけに任せない |
CLIで一時的に設定する
Codex CLIの起動時に、SandboxとApprovalを指定できます。
codex \
--sandbox workspace-write \
--ask-for-approval on-request読み取り専用でレビューする例です。
codex \
--sandbox read-only \
--ask-for-approval never
CLIオプション名や利用可能な値はバージョンによって変わる可能性があります。codex --helpと公式ドキュメントを確認してください。
config.tomlへ保存する
~/.codex/config.tomlまたはプロジェクト設定に記述します。
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = falseこの例では、リポジトリ内の通常編集は許可しつつ、ネットワークは無効にしています。パッケージ取得や外部ドキュメント確認が必要な場合は、毎回有効にするのではなく、別の明示的なタスクへ分けます。
調査用プロファイルを作る
調査と実装で設定を切り替えたい場合は、Codexのプロファイル機能を使えるバージョンでは用途別に保存します。概念例です。
[profiles.review]
sandbox_mode = "read-only"
approval_policy = "never"
[profiles.implementation]
sandbox_mode = "workspace-write"
approval_policy = "on-request"
[profiles.ci]
sandbox_mode = "workspace-write"
approval_policy = "never"CIプロファイルは、専用コンテナ、読み取り専用トークン、ネットワーク許可先、実行コマンドを別途固定する前提です。
workspace-writeで書き込める範囲を確認する
「workspace」という言葉だけで、自分が想定した1フォルダだけとは限りません。起動したディレクトリ、Gitルート、追加の書き込み可能領域、一時ディレクトリを確認します。
作業前にCodexへ確認する例です。
現在のSandbox mode、書き込み可能なルート、
ネットワーク可否、承認が必要になる操作を説明してください。
まだファイル変更やコマンド実行はしないでください。シンボリックリンクを通じて作業領域外へ到達できないか、秘密ファイルがリポジトリ内に置かれていないかも確認します。
ネットワークアクセスを分ける
通常のコード編集で外部ネットワークが必要な場面は限られます。ネットワークを常時許可すると、未知のスクリプト実行、データ送信、依存取得、外部命令の取得などの範囲が広がります。
ネットワークなしでできること
- 既存コードの読み取り・編集
- インストール済み依存でのテスト
- ローカルGit差分の確認
- 既存ドキュメントの参照
ネットワークが必要になりやすいこと
- 新しいパッケージの取得
- 公式ドキュメントやWeb検索
- リモートGit操作
- 外部APIやMCPサーバー
調査だけならDocs MCPなど許可した接続先へ限定し、一般インターネット全体を許可しない構成を検討します。
依存パッケージ追加を安全にする
npm installは、外部ネットワーク、任意のパッケージコード、install script、lockfile変更を伴います。通常の編集とは分けて承認します。
- 既存依存で実現できない理由を説明させる
- 候補パッケージ、保守状況、ライセンス、サイズを確認する
- 追加する正確な名前とバージョンを人間が確認する
- 隔離環境でインストールする
- lockfileと実行されたscriptを確認する
- テストと脆弱性確認を行う
AGENTS.mdへ「依存追加は承認を求める」と書き、Sandbox／Approvalでネットワーク操作を確認対象にします。
Git操作を制御する
コード編集と、履歴・リモートを変更するGit操作は分けます。
| 比較的安全な読み取り | 明示的な確認が必要な操作 |
|---|---|
git status |
git push |
git diff |
git reset --hard |
git log |
git clean -fd |
git show |
force push、タグ変更、リモート変更 |
重要な変更はWorktreeや専用ブランチで行い、pushとPull Request作成は別の承認ステップにします。
データベースとデプロイをCodexの外側でも止める
Codexがコマンドを実行できなくても、渡した資格情報が強すぎると、MCPや外部ツールから本番変更できる場合があります。
- 開発用DBだけを渡す
- 本番資格情報をローカル環境へ常置しない
- 読み取り専用の短期トークンを使う
- デプロイは保護されたCIジョブだけで行う
- 本番マイグレーションは人間の承認とバックアップを要求する
- クラウドIAMでも最小権限にする
MCPと外部ツールの承認
MCPツールには、読み取りだけでなく、チケット作成、メッセージ送信、ファイル更新、公開、課金などの副作用があります。ローカルSandboxだけでは外部サービス側の変更を止められません。
ツールを次のように分けます。
search_*、get_*：読み取り専用create_draft：下書き作成publish、send、delete：明示承認charge、grant_access：追加本人確認とサーバー側ポリシー
MCPサーバー側でも利用者、対象リソース、権限を検証し、モデルの引数を信用しないでください。
CIでneverを使う場合
GitHub Actionsなどの非対話環境では、人間へ承認を求められないためneverを使うことがあります。次の条件を整えます。
- 一時ランナーまたはコンテナ
- Pull Requestでは読み取り専用トークン
- 外部ネットワークの許可先を限定
- 本番秘密を渡さない
- 書き込み先を成果物やコメント下書きに限定
- タイムアウトと利用上限
- 生成した差分を自動mergeしない
ForkからのPull Requestへ秘密を渡さないなど、CIプラットフォーム側のセキュリティも必要です。
完全回避オプションを使わない
Codexには、承認とSandboxを完全に回避する危険なオプションが用意される場合があります。名称にdangerouslyやyoloを含むものは、通常の開発PCや共有サーバーで使わないでください。
自動化で必要に見えても、先に次を検討します。
workspace-write + neverで足りないか- 必要な1コマンドを専用ツールにできないか
- コンテナ内だけで権限を広げられないか
- ネットワークや秘密を外せないか
- Codexではなく通常のCIスクリプトで実行すべきではないか
Webアプリ開発のおすすめプリセット
調査
sandbox_mode = "read-only"
approval_policy = "never"目的：影響範囲、既存テスト、データフローの確認。外部ネットワークなし。
通常実装
sandbox_mode = "workspace-write"
approval_policy = "on-request"
[sandbox_workspace_write]
network_access = false目的：既存依存だけで編集・テスト。パッケージ追加や外部確認は別途承認。
CIレビュー
sandbox_mode = "read-only"
approval_policy = "never"目的：差分レビューと既存ファイルの確認。コメント投稿は別の最小権限ステップへ分ける。
設定を確認するチェックリスト
- 現在の作業ディレクトリは正しいか
- 書き込み可能なルートはどこか
- ネットワークは本当に必要か
- ホームディレクトリや秘密ファイルが見えていないか
- 利用できるMCPツールに副作用がないか
- 承認なしで実行されるコマンドは何か
- APIキーやクラウド資格情報の権限は最小か
- 作業をGitで戻せるか
- タイムアウトと利用上限があるか
よくあるトラブル
ファイルを編集できない
read-onlyになっていないか、作業対象が書き込み可能ルート内か確認します。
npm installが失敗する
ネットワークが無効か、Sandbox外のキャッシュへ書こうとしている可能性があります。依存追加を別の承認済みステップにします。
neverなのに操作が失敗する
neverは自動許可ではありません。Sandboxが許可しない操作は確認を出さずに失敗します。
承認が頻繁に表示される
作業領域、ネットワーク、コマンド、外部ツールが現在のSandboxを越えていないか確認し、必要な範囲だけ設定を調整します。
読み取り専用なのに外部サービスが変更された
ローカルSandboxとは別に、MCPやAPIツールが外部へ書き込んだ可能性があります。外部ツールの権限と副作用承認を見直します。
あわせて読みたい記事
よくある質問
workspace-writeならリポジトリ外も編集できますか？
通常は許可された作業領域へ限定されます。実際の書き込み可能ルートと追加設定を確認してください。
approval_policy=neverは危険ですか？
Sandboxが狭く、秘密やネットワークがなく、非対話ジョブである場合は有用です。広いSandboxや強い外部資格情報と組み合わせると危険になります。
AGENTS.mdの禁止事項とSandboxはどちらが優先ですか？
役割が異なります。AGENTS.mdはモデルへの指示、Sandboxは技術的な実行制限です。両方を使い、重要な禁止事項はSandboxや外部権限でも止めます。
Codexにインターネットを許可してもよいですか？
必要なタスクだけに限定してください。公式ドキュメント確認は専用MCP、依存取得は人間が確認した別ステップなど、接続先と目的を小さくします。
danger-full-accessを安全に使う方法はありますか？
通常環境では避けます。必要なら、秘密情報のない使い捨てコンテナやVM、非特権ユーザー、制限ネットワーク、短時間実行、終了後破棄を前提にします。
まとめ
CodexのSandboxは技術的な操作範囲、Approvalは人間へ確認する条件を決めます。調査はread-only、通常実装はworkspace-write + on-requestを基準にし、ネットワークは必要な処理だけへ限定すると扱いやすくなります。
neverは何でも許可する設定ではなく、承認なしでSandbox内だけを実行する設定です。本番資格情報、デプロイ、DB更新、MCPの副作用は、Codexのローカル設定だけに頼らず、IAM、CI、短期トークン、サーバー側の権限でも制限してください。