Codexのサンドボックスを徹底解説！自動承認を安全に使う設定も紹介
Codexを使い始めると、サンドボックスという言葉が設定のあちこちに登場します。よくわからないまま承認を連打したり、逆に全部オフにする方法を探したりしていないでしょうか。仕組みを知らずに設定を変えると、AIに与える権限が一気に広がり、事故の危険が高まります。
この記事では、Codexのサンドボックスの仕組みと3つのモード・自動承認を安全に実現する設定を、専門用語を最小限にして解説します。読み終えるころには、自分の使い方に合う設定を根拠を持って選べるはずです。結論から言うと、既定の設定がそのまま公式の推奨形のため、無効化ではなく組み合わせの理解が近道になります。
Codexのサンドボックスとは【仕組みを平易に理解する】
まず押さえたい基本は以下の4つです。
- サンドボックスはAIの作業範囲をOSが強制する仕組み
- 承認ポリシーとの二層で安全を作っている
- OSごとに使われる技術が違う
- MCPなどの外部ツールは壁の外側にある
サンドボックスはAIの作業範囲をOSが強制する仕組み
Codexのサンドボックスとは、AIが書き込めるフォルダと外部への接続を、OSの機能で物理的に制限する仕組みです。たとえば外部から紛れ込んだ悪意ある指示が、大事なファイルの削除や機密情報の外部送信を試みても、境界の外の操作はOSのレベルで失敗します。
AIの善意や指示の書き方に頼らず、そもそもできない状態を作る点が本質です。約束ではなく壁で守る、と考えるとイメージしやすくなります。
承認ポリシーとの二層で安全を作っている
サンドボックスとよく混同されるのが、承認ポリシーです。サンドボックスが「動ける範囲」を決める壁だとすれば、承認ポリシーは「範囲を越えるときに人へ確認するかどうか」のルールで、両者は別の層として働きます。
公式ドキュメントによると、Codexは起動時にフォルダの状態を見て設定を推奨します。バージョン管理されたフォルダでは作業フォルダ内の編集を自動で進めるAuto、管理外のフォルダでは読み取り専用が既定の提案です。この初期値の時点で、二層の守りがすでに機能しています。
OSごとに使われる技術が違う
壁の実体は、OSが持つ隔離機能です。公式ドキュメントによると、macOSではSeatbeltと呼ばれる仕組みを使い、Linuxではbubblewrapとseccompの組み合わせで動作します。Linuxでは事前にbubblewrapのインストールが必要です。
Windowsは、WSL2上ではLinuxと同じ仕組みを使い、ネイティブ実行では専用のWindowsサンドボックスが動きます。なお、WSL1はCodex 0.115以降サポート対象外になりました。細かな技術名を覚える必要はありませんが、どのOSでもOSレベルの強制である点は共通です。
MCPなどの外部ツールは壁の外側にある
サンドボックスの壁が制限するのは、Codexがこのパソコンの上で行うファイル操作とコマンド実行、外部への接続です。MCPで接続した外部サービスの操作そのものは、この壁で守れる範囲の外側にあります。
公式ドキュメントでは、MCPやアプリのツール呼び出しは承認の仕組みの側で扱う対象とされています。読み取り専用モードで使っていても、接続済みの外部サービス側のデータは操作されうるため、外部ツールの接続は必要な分だけに絞るのが安全です。壁と承認のどちらが守ってくれる操作なのかを分けて考えると、設定の判断を誤りません。
サンドボックスの3つのモードを理解する
sandbox_modeで選べるモードは以下の3つです。
- read-onlyは読み取り専用で始めるモード
- workspace-writeは作業フォルダ内だけ書けるモード
- danger-full-accessは隔離環境専用の全開放モード
read-onlyは読み取り専用で始めるモード
read-onlyでは、AIはファイルを読んで調べられますが、編集やコマンドの実行には承認が必要です。コードの調査や説明だけを頼みたい場面、初めてのプロジェクトを触らせる場面に向いています。
バージョン管理されていないフォルダで起動した場合の公式推奨もこのモードです。壊れて困るものが多い場所ほど、読み取り専用から始めるのが安全な順番になります。
workspace-writeは作業フォルダ内だけ書けるモード
workspace-writeでは、作業フォルダと一時フォルダの中に限って編集とコマンド実行が可能です。日常のローカル作業向けの標準モードと公式に位置づけられています。対象範囲は/statusコマンドでいつでも確認可能です。
このモードでも、変更履歴を壊さないよう.gitなどの管理用フォルダは読み取り専用として保護されます。さらに、外部への接続は既定でオフのため、書ける範囲とネットワークの両面で境界が保たれています。
danger-full-accessは隔離環境専用の全開放モード
danger-full-accessは、ファイルとネットワークの制限をすべて外すモードです。公式ドキュメントは「サンドボックスなし・きわめて危険」と明記しており、通常のパソコンで使う設定ではありません。
公式が認めているのは、Dockerコンテナのように外側で隔離を用意した環境の中だけです。コンテナ側で守りを固めたうえで、内側のCodexをこのモードにする使い方が案内されています。
自動承認を安全に実現する設定【公式の推奨レシピ】
承認の手間を減らす組み合わせは以下の4つです。
- 推奨はworkspace-writeとon-requestの組み合わせ
- 承認の審査をAIに任せるAuto-reviewモードが加わった
- 完全自動化はneverとモードの選択で制御する
- 廃止されたフラグと危険なフラグを見分ける
推奨はworkspace-writeとon-requestの組み合わせ
承認ポリシーon-requestは、サンドボックスの中では自動で作業し、境界を越える必要があるときだけ確認を求める設定です。workspace-writeと組み合わせると、作業フォルダ内の編集は止まらず進み、外部接続や範囲外の変更だけが確認に回ります。
公式ドキュメントもこの組み合わせをAutoプリセットとして最初に挙げています。自動承認したい人の答えは、実は既定の形そのものです。
承認の審査をAIに任せるAuto-reviewモードが加わった
公式の承認プリセットには、AutoとSafe read-onlyに加えてAuto-reviewモードが加わりました。境界を越える操作の承認要求を、人の代わりにレビュー役のAIが審査する仕組みで、設定はapprovals_reviewerをauto_reviewにしてon-requestと組み合わせる形です。
審査の対象は、コマンドの権限昇格・ブロックされた通信・書き込み範囲の外への編集・MCPなどのツール呼び出しといった承認要求の全般です。却下が連続3回、または直近50件中10回に達すると作業自体を中断する安全装置も組み込まれています。長時間の無人作業と歯止めを両立させたい人の新しい選択肢ですが、公式ドキュメントは決定論的なセキュリティ保証ではないと明記しています。あくまでサンドボックスの壁を前提にした上乗せとして使いましょう。Auto-reviewの公式説明
完全自動化はneverとモードの選択で制御する
確認を一切出したくない場合は、承認ポリシーをneverにします。重要なのは、neverはどのサンドボックスモードとも組み合わせられる点です。たとえば定期実行の調査ならread-onlyとneverで、読み取りだけを無人で回せます。
確認をなくす代わりに、動ける範囲をモードで狭める発想です。全開放にしなくても、無人運転は十分に実現できます。注意点として、Auto-reviewが働くのはon-requestの側で、neverにすると審査ごと動かなくなります。
基本の2値のほか、公式ドキュメントに追加されたのが、承認の画面の種類ごとに「確認する・自動で却下する」を細かく決めるgranular形式です。作り込みたい場合の上級向けの選択肢になります。
廃止されたフラグと危険なフラグを見分ける
古い解説に登場するon-failureとuntrustedは廃止済みで、公式は対話利用にon-request、無人実行にneverを案内しています。untrustedを設定ファイルに残すとCodexが起動しない場合があるため、見つけたら削除してください。--full-autoフラグも互換用の位置づけへ変わり、使うと警告が出る扱いです。
承認とサンドボックスを同時に外す--dangerously-bypass-approvals-and-sandbox(別名--yolo)は、外側で固めた隔離環境専用と公式が明記する最終手段です。名前の長さ自体が、気軽に使うなとの公式の意思表示だと受け取ってください。
config.tomlでのサンドボックス設定例
設定ファイルで押さえる書き方は以下の4つです。
- 基本はsandbox_modeとapproval_policyの2行で決まる
- ネットワークと書き込み範囲は個別に開ける
- プロファイルと企業向け設定で使い分ける
- 新体系のPermission Profilesはどちらか一方だけ使う
基本はsandbox_modeとapproval_policyの2行で決まる
恒久的な設定は、ホームフォルダの.codex/config.tomlに書きます。公式ドキュメントの例に沿うと、次の2行が基本形です。
approval_policy = "on-request"
sandbox_mode = "workspace-write"
起動のたびにフラグを付ける必要がなくなり、チーム内での設定共有も楽になります。まずこの2行だけで、日常利用には十分です。
ネットワークと書き込み範囲は個別に開ける
workspace-writeで外部接続が必要な場合は、[sandbox_workspace_write]セクションにnetwork_access = trueを追加します。書き込み先を増やしたい場合も、同じセクションのwritable_rootsに必要なフォルダだけを列挙する方式です。
全開放へ切り替えるのではなく、必要な穴だけを最小限に開ける考え方が公式の設計に沿っています。
プロファイルと企業向け設定で使い分ける
用途ごとに設定を切り替えたい場合は、プロファイル機能で複数の設定を保存し、起動時に選べます。調査用は読み取り専用、開発用は標準、と分けておけば事故防止に有効です。
組織で統制したい場合には、利用者が選べるモードや承認ポリシーを管理者側で制限する企業向けの仕組みも公式に用意されています。
新体系のPermission Profilesはどちらか一方だけ使う
公式ドキュメントには、サンドボックスと承認をまとめて名前付きで定義する新体系のPermission Profilesがベータとして追加されています。組み込みのプロファイルは:read-only・:workspace・:danger-full-accessの3つが用意されています。既存のプロファイルを土台に自分用の定義を重ねる書き方も可能です。
新体系の目玉は、接続先を「このドメインは許可、このドメインは拒否」とドメイン単位で決められるネットワーク制御です。サブドメインまで含める指定にも対応し、拒否の指定が優先されます。注意点は従来のsandbox_mode系の設定と合成されないことで、公式はどちらか一方だけを使うよう明記しています。移行するときは、古い2行を残したまま新体系を書き足さないでください。Permission Profilesの公式説明
Windowsとクラウド版のサンドボックス事情
環境ごとの違いは以下の2つです。
- Windowsはネイティブのサンドボックスが使えるようになった
- クラウド版はコンテナ隔離の二段階で動く
Windowsはネイティブのサンドボックスが使えるようになった
以前のCodexはWindowsでの隔離が弱点でしたが、現在はネイティブのWindowsサンドボックスが提供されています。推奨のelevatedモードは、専用の低権限ユーザーとファイアウォール規則で境界を作る方式です。管理者権限なしで動くunelevatedモードもありますが、公式はelevatedより弱いと明記しています。
公式の案内は、まずネイティブのサンドボックスを既定として使い、Linux系のツールが必要な場合にWSL2を選ぶ順番です。設定はconfig.tomlの[windows]セクションにsandbox = "elevated"のように書き、対応OSはWindows 11が推奨とされています。Windowsだからサンドボックスを諦める状況は、すでに過去のものになっています。
クラウド版はコンテナ隔離の二段階で動く
クラウド版のCodexは、OpenAIが管理する隔離コンテナの中で動きます。準備段階ではネットワークにつないで依存関係を導入し、AIが作業する段階では既定でネットワークが遮断される二段階の方式です。
設定した機密情報も準備段階だけで使われ、作業段階の前に取り除かれると公式が説明しています。ローカルとクラウドで隔離の作り方は違いますが、既定で閉じておき必要な分だけ開ける思想は共通です。
サンドボックスのつまずきは事例別に解決する
失敗して調べに来た人向けに、つまずきの型を以下の3つに整理します。
- 通信が必要なコマンドの失敗は仕様どおりの動き
- 範囲外への書き込みはwritable_rootsを最小限に開ける
- neverでの失敗は確認なしの門前払いとして理解する
通信が必要なコマンドの失敗は仕様どおりの動き
workspace-writeでも外部への接続は既定でオフのため、部品の追加インストールのような通信を伴うコマンドは失敗します。故障ではなく、壁が仕様どおりに働いた結果です。
対処は2択になります。その場だけ通したいなら、on-requestの承認で個別に許可するのが手軽です。毎回必要なら、[sandbox_workspace_write]のnetwork_access = trueで開けるか、Permission Profilesでドメイン単位に絞って開けましょう。
範囲外への書き込みはwritable_rootsを最小限に開ける
作業フォルダの外への書き込みで失敗した場合は、まず/statusで書き込み可能な範囲を確かめます。原因が範囲外への書き込みなら、writable_rootsに必要なフォルダだけを追加するのが正攻法です。
danger-full-accessへ切り替える解決だけは選ばないでください。フォルダを1つ開ければ済む問題に、全開放で答える必要はありません。
neverでの失敗は確認なしの門前払いとして理解する
承認ポリシーがneverのときは、境界を越える操作の確認が出ない代わりに、境界の外の操作はそのまま失敗します。「確認画面も出ないのに作業が失敗する」と見える現象の正体です。
無人実行で境界越えが必要な作業なら、on-requestとAuto-reviewの組み合わせへ切り替えるか、サンドボックス側の設定であらかじめ必要な範囲を開けておきます。どの境界に当たったかは、失敗時の表示と/statusの照らし合わせで特定できます。
Codexのサンドボックスに関するよくある質問
迷いやすい点への回答は以下の3つです。
- Claude Codeのサンドボックスとは何が違いますか？
- サンドボックスを無効にしても大丈夫ですか？
- サンドボックスが原因で作業が失敗したらどうしますか？
Claude Codeのサンドボックスとは何が違いますか？
技術の土台は似ています。どちらもmacOSではSeatbelt、LinuxではbubblewrapとOSの隔離機能を共有し、ネットワークを許可制にする点も共通です。
違いは位置づけです。Codexはサンドボックスが標準の前提として常に働きます。Claude Codeは許可ルールでの制御が基本で、サンドボックスは必要に応じて有効化する多層防御の一枚という設計です。両ツールを併用する場合も、考え方の共通点が多いため学習の負担は小さく済みます。
Claude Codeのセキュリティを徹底解説！安全に使う設定と企業運用も紹介
サンドボックスを無効にしても大丈夫ですか？
通常のパソコンでは推奨できません。公式ドキュメントは、danger-full-accessと承認なしの組み合わせをフルアクセスと定義しており、リスクの低い自動化の対比はworkspace-writeとon-requestです。
開発用コンテナの解説では、悪意あるプロジェクトがコンテナ内の認証情報まで持ち出せるとまで警告されています。無効化はDockerや仮想マシンで外側を固めた場合に限る、が公式の線引きです。
サンドボックスが原因で作業が失敗したらどうしますか？
まず/statusコマンドで、現在のモードと書き込み可能な範囲を確認します。範囲外への書き込みが原因なら、writable_rootsに必要なフォルダだけを追加するのが正攻法です。
サンドボックスの挙動そのものは、codex sandboxコマンドでコマンド単位のテストもできます。失敗のたびに全開放へ逃げるのではなく、どの境界に当たったかを特定して最小限だけ開けましょう。
Codexのサンドボックスは既定のまま自動承認と組み合わせましょう
Codexのサンドボックスは、AIが動ける範囲をOSの機能で強制する安全の土台です。read-only・workspace-write・danger-full-accessの3モードと、on-request・never(および細粒度のgranular)の承認ポリシーの二層を組み合わせて、自由度と安全のバランスを決めます。
自動承認の答えは全開放ではなく、公式推奨のworkspace-writeとon-requestの組み合わせで、審査まで任せたい場合はAuto-reviewが上乗せの選択肢です。まずは既定のまま使い始め、失敗したときだけ/statusで境界を確かめて、必要な範囲を最小限に開けていきましょう。Codex全体の安全設計は次の記事で解説しています。
