Codex のサンドボックスと承認モード：完全ガイド（2026年）
Codex は安全性を2つの独立した設定に分けています。サンドボックスモード（エージェントが何をできるか）と、承認ポリシー（実行前にいつ確認を求めるか）です。デフォルトは workspace-write ＋ on-request。使い捨て環境以外では、danger-full-access を never（や --yolo）と組み合わせて使ってはいけません。本ガイドでは、3つのサンドボックスモード、3つの承認ポリシー、CLI/config.toml での切り替え方、新しい Permission Profiles レイヤー、そして1分以内に適切な組み合わせを選べる判断表を解説します。
- Codex のサンドボックス／承認の仕組み（および新しい Permission Profiles レイヤー）は変化が速く、公式ドキュメントは現在 learn.chatgpt.com の複数のパスに分散しています。以下の内容は執筆時点（2026年8月）の公式ドキュメントと照合しましたが、依存する前に最新のドキュメントを確認してください。
サンドボックスモード対承認ポリシー - 2つの異なる問い
Codex は何かを実行する前に、完全に別々の2つの問いを自らに立てます。「自分は何をしてよいのか？」（サンドボックスモード）と、「いつ先に確認すべきか？」（承認ポリシー）です。公式の learn.chatgpt.com/codex/sandboxing ドキュメントによれば、この2つのレイヤーは独立して動作します。サンドボックスが全開でも Codex が確認をやめるわけではなく、承認ポリシーが厳しくても Codex が触れられる範囲が自動的に制限されるわけではありません。
Codex は初めてですか？この設定の詳細に入る前に、OpenAI Codex とは何かを読んでください。混乱を避けるために一言：これは Codex 自身の権限システムであり、その上に AgentKit をインストールすることとは無関係です。
3つのサンドボックスモード
サンドボックスモードは、あなたの確認を待たずに Codex がマシン上で何に触れられるかを決めます。公式の サンドボックスのドキュメント（2026年8月アクセス）によると、3つのレベルがあります。
| サンドボックスモード | Codex ができること | リスクレベル |
|---|---|---|
read-only | ファイルの読み取りのみ。ディスク上のいかなるものも書き込み／変更できず、副作用のあるコマンドも実行できません。 | 低 |
workspace-write（デフォルト） | 現在のワークスペースディレクトリ内（およびいくつかのシステム一時パス）で読み書きします。その範囲外はすべて別途の承認が必要です。 | 中 |
danger-full-access | ファイルシステムの境界なし。Codex プロセスが OS レベルで触れる権限を持つ場所ならどこでも読み書きします。 | 高 |
workspace-write は、何も指定しないときに Codex がデフォルトで選ぶモードです。マシン全体を開放することなく実際の作業に十分な広さがあるため、私も普段のコーディングのほとんどでこれを使っています。
簡単な例：すでにコーディング中のリポジトリで Codex を開き、何も変えなければ、デフォルトは workspace-write になります。リポジトリ内のファイルは自由に編集できます。しかし、その範囲外に書き込もうとすると（たとえば ~/.ssh/ や別のシステムディレクトリに触れるなど）、それはサンドボックス外の操作となります。同時に設定されている承認ポリシーに応じて、そのまま完全にブロックされるか、別途の確認ステップが発生します。
3つの承認ポリシー
承認ポリシーは、Codex が何をしてよいかとは完全に別に、いつ止まってあなたに確認すべきかを決めます。公式の エージェント承認とセキュリティのドキュメント（2026年8月アクセス）によると、3つのレベルがあります。
| 承認ポリシー | Codex が確認するタイミング |
|---|---|
untrusted | ほとんどのコマンドの前に確認します。無害に見えるものでも確認する、最も慎重な設定です。 |
on-request（バージョン管理されたフォルダのデフォルト） | Codex がどのコマンドを直接実行して安全かを自ら判断し、リスクがあると判断したときや現在のサンドボックス外のときだけ確認します。 |
never | 決して確認しません。リスクのあるコマンドを含め、設定されたサンドボックスモードに従ってそのまま実行します。 |
ほとんどのガイドが見落としている点：公式ドキュメントは on-request が「バージョン管理されたフォルダの」デフォルトだと述べており、すべてのフォルダに対する無条件のデフォルトではありません。私が確認した他のほぼすべてのガイド（両言語とも）はこの条件を飛ばしています。git 管理下でないディレクトリで Codex を実行している場合、on-request が有効だと決めつけず、実際の設定を確認してください。
モードの切り替え方 - /permissions、CLI フラグ、config.toml
サンドボックスモードと承認ポリシーを設定する一般的な方法は3つです。
- セッション内（CLI）：
/permissionsと入力してピッカーを開き、直接選びます。 - IDE/デスクトップ： コンポーザー内にある権限コントロールを使います。
- 起動フラグ：
--sandboxと--ask-for-approval。 - 永続的な設定：
~/.codex/config.toml内のsandbox_modeとapproval_policyキー。
CI パイプライン向けの実例（プロンプトに答える人が誰もいない場合）：
codex --sandbox read-only --ask-for-approval neverこの組み合わせが非対話的な実行で機能するのは、Codex が入力待ちで止まらず（never）、かつ read-only が予期しない書き込みを防ぐからです。この構成は、Codex 用に AGENTS.md を設定する方法と直接組み合わせられます。両方を1つのワークフローにまとめる方法は Codex 用 AGENTS.md ガイドを参照してください。
Permission Profiles - 新しい設定レイヤー
上記の従来型の sandbox_mode／approval_policy のペアに加えて、Codex には新しい設定レイヤーがあります。Permission Profiles です。learn.chatgpt.com/docs/permissions を直接取得して確認しました（2026年8月アクセス）。仕組みは次のとおりです。
default_permissionsキーは、組み込みまたはカスタムのプロファイルを指します。- 組み込みプロファイルは3つ：
:read-only、:workspace、:danger-full-access。上記の3つのサンドボックスモードにほぼ対応しており、名前が違うだけです。 [permissions.<name>]テーブルで独自のプロファイルを書き、どのパスが読み取り可能・書き込み可能・明示的に拒否かを宣言できます。- ネットワークアクセスは分離されています：
network.enabled（ネットワークのオン/オフ）はfeatures.network_proxy（制御されたプロキシ経由でルーティング）とは別です。
正直に言うと：この記事を調べる際に確認した検索結果では、これをほとんど誰も扱っていません。触れているのは1記事だけで、それも単独であり、sandbox_mode／approval_policy のペアと並べて比較されることは一度もありませんでした。そして公式ドキュメントが明記していないことが1つあります。default_permissions と sandbox_mode／approval_policy を同時に設定した場合の優先順位です。非公式の情報源の一部は sandbox_mode が勝つと推測していますが、それを直接裏付ける一次ドキュメントのページは見つけられませんでした。事実として扱わないでください。実務上の安全な選択は、1つのシステムを選んで一貫させることです。従来のペア一式か、Permission Profiles 一式のどちらかにし、混在させないでください。
このレイヤーの本当の価値をイメージするための概念的な例です（公式のフィールド構文として確認されたものではありません）：リポジトリ全体を読み取れるが、書き込みは logs/ ディレクトリのみに限定し、より広い読み取り範囲には本来含まれる .env や .ssh/ のような機微なパスをいくつか明示的に拒否したいとします。これは、従来の sandbox_mode／approval_policy のペア（大まかな3レベルのみ）ではできないパス単位の制御です。これはドキュメントに最近追加された部分なので、依存する前に正確なフィールド構文を最新のドキュメントで確認してください。
判断表 - どのタスクにどのモードか
これは、Codex を開くたびに考え直すのではなく、1分以内に決めるために私が実際に使っている表です。
| シナリオ | sandbox_mode | approval_policy | 理由 |
|---|---|---|---|
| 読み取り専用、計画 | read-only | on-request | 書き込むものがないので、Codex がリスクを誤判断しても安全です。 |
| ローカルリポジトリでの日常のコーディング（Codex 自身のデフォルト） | workspace-write | on-request | 実際の作業に十分なアクセスがあり、なおかつリスクのあるコマンドやサンドボックス外のコマンドでは Codex が確認します。 |
| 繰り返しの、信頼できるローカル作業 | workspace-write | untrusted | 少し直感に反しますが、繰り返し作業では untrusted（より多く確認する）を使うと、すべてを飛ばさずに一段階ずつ素早く確認できます。 |
| CI/CD、非対話的 | read-only（または範囲を狭めた workspace-write） | never | 承認をクリックする人がいないので never にするしかありません。その分、サンドボックスをできるだけ狭くして補います。 |
| 本当にシステム全体へのアクセスが必要 | danger-full-access | on-request | Codex がワークスペース外の危険なものに触れる前に、確認するレイヤーを1つ残しておきます。 |
| 使い捨てサンドボックスのみ（破棄前提のコンテナ/VM） | danger-full-access | never/--yolo | 最もリスクの高い組み合わせは、セッション後にマシン全体を破棄する場合にのみ許容されます。 |
覚えておくべき一言：使い捨て環境以外では、danger-full-access を never/--yolo と組み合わせて使ってはいけません。この表の中で、2つの安全レイヤーを同時に手放してしまう唯一の行です。
本番環境の安全性の教訓 - 実際の一発
上記の表は紙の上ではもっともらしく聞こえますが、それが存在する理由は理論的なものではありません。当サイトの /goal を効果的に使う方法の記事は「Slap #1」を伝えています。ゴールは明確に書かれていました - ステージングにのみデプロイする - しかし数回の自動コンパクトの後、エージェントはコンテキストから外れて境界を忘れ、コンパクトごとにタスクを思い出させるフックがあったにもかかわらず、本番環境に直接デプロイしてしまいました。
これこそ、この判断表が防ぐ失敗です。安全の一線は、実際の sandbox_mode／approval_policy（Codex が従わなければならない技術的な制限）に置く必要があり、プロンプトやゴールの中のメモ（十分なコンテキストのコンパクション後にエージェントが忘れうるもの）に置いてはいけません。本番環境が Codex の届く範囲のどこかにあるなら、そのスコープに対して approval_policy = never を設定してはいけません。すでにそうしないよう伝えたとどれだけ確信していてもです。
言い換えれば、上記の判断表は壁に飾るための理論的な演習ではありません。それは、Slap #1 が提起するまさにその問いへの技術的な答えです。コンテキストから外れて漂流した永続的なエージェントが、触れてはいけないものに触れるのをどう止めるか。プロンプトのリマインダーは忘れられますが、sandbox_mode／approval_policy に設定された制限は忘れられません。
AgentKit はあなたが選んだモードの内側で動く
境界についてはっきりさせておきます：AgentKit は Codex のサンドボックスや承認ポリシーに触れることも、迂回することもありません。それは現在有効なモードの内側で動くスキル／ワークフローのレイヤーにすぎません。read-only ＋ untrusted を設定すれば、AgentKit もまったく同じ制限に縛られ、独自の特権は一切ありません。Codex 用のインストール：ak kit init engineer --target codex、その後、新しい Codex セッションで $ak:cook を呼び出します。詳しいウォークスルーは Codex で AgentKit を使う方法を参照してください。
選んだサンドボックスの内側にとどまる、あらかじめ用意されたワークフロー／スキルが欲しいですか？ AgentKit Engineer Kit は Codex 用に ak:cook、ak:code-review、ak:ship を追加します。Codex の既存の権限は何も変えず、サンドボックス／承認は今までどおりあなたが完全に制御します。
よくある質問（FAQ）
Codex のデフォルトのサンドボックスモードは？
workspace-write です。Codex はシステム全体への自由なアクセスなしに、現在のワークスペースディレクトリ内で読み書きできます。バージョン管理されたフォルダでは、デフォルトの承認ポリシー on-request と組み合わさります。
on-request は毎回すべてのコマンドの前に確認しますか？
いいえ。on-request は、どのコマンドを直接実行して安全かを Codex 自身に判断させ、リスクがあると判断したときや現在のサンドボックス範囲外のときだけ確認します。ほとんどのコマンドの前に確認する untrusted とは異なります。
danger-full-access と --yolo の違いは？
danger-full-access は sandbox_mode の1つの値です（ファイルシステムの境界を取り除きます）。--yolo（両方を回避するフラグ）はさらに踏み込み、最も広いサンドボックスと never の承認ポリシーを1つのフラグにまとめるため、danger-full-access 単体よりリスクが高くなります。この領域は頻繁に変わるので、使う前にお使いのインストールでの正確なフラグ名を確認してください。
Permission Profiles と sandbox_mode を併用できますか？
技術的には両方を宣言できますが、公式ドキュメントは競合時にどちらが勝つかを明記していません。いかなる優先順位の主張も確認済みとして扱わないでください。安全なアプローチは、1つのシステム（従来型か Permission Profiles）を選んで一貫させることです。
CI/CD にはどのモードを使うべきですか？
read-only（または範囲を狭めた workspace-write）を never と組み合わせます。パイプラインではプロンプトに答える人がいないため承認は never にせざるを得ないので、それでも機能する最も狭いサンドボックスで補います。
/permissions は config.toml を恒久的に変更しますか？
これは依存する前に実際に確認すべき詳細です。セッションのみの変更なのか、実際に config.toml に書き戻されるものなのかで挙動が異なる可能性があります。最も確実な確認方法は、ピッカーで切り替えた後に config.toml を開き、保存されたかどうかを自分で確かめることです。
結論
Codex の安全性モデルは、2つの独立したレイヤーに集約されます。サンドボックスモード（何ができるか）と承認ポリシー（いつ確認すべきか）です。デフォルトの workspace-write ＋ on-request はほとんどの日常のコーディングに合います。使い捨て環境以外では、danger-full-access を never/--yolo と組み合わせて使ってはいけません。当てずっぽうにせず上記の判断表を使い、Slap #1 の教訓を思い出してください。安全の一線は、プロンプトのメモではなく設定に属します。