サンドボックスと承認で、触れる範囲と止まる場所を決める

第3回で、作業の途中に確認が入る場面を見ました。あれがどういう規則で出ているのかを、この回で分解します。

規則は1つではなく2つあります。ひとつは、そもそも何が実行できるかを決める枠。もうひとつは、枠の中の操作を実行する前に人へ聞くかどうかを決める方針です。この2つを混ぜて考えると、設定を緩めたときに何が起きるかが読めなくなります。

触れる範囲を決めるのがサンドボックス

サンドボックスは、OSの側で強制される枠です。Codex が何を実行しようとしても、この枠の外には出られません。

コマンドライン版のヘルプに、選べる値がそのまま書かれています。

-s, --sandbox <SANDBOX_MODE>
        Select the sandbox policy to use when executing model-generated shell commands

        [possible values: read-only, workspace-write, danger-full-access]

3つの意味は名前のとおりです。read-only は読むだけ。workspace-write は作業フォルダとその下への書き込みまで。danger-full-access は制限なしです。

ここで押さえておきたいのは、枠は人の注意力とは関係なく効くという点です。承認の画面で「はい」を押し間違えても、read-only なら書き込みは起きません。疲れているときほど、この差は大きく効きます。

止まる場所を決めるのが承認の方針

承認の方針は、実行の前に人へ聞くかどうかです。こちらも値は2つだけです。

-a, --ask-for-approval <APPROVAL_POLICY>
        Configure when the model requires human approval before executing a command

        Possible values:
        - on-request: The model decides when to ask the user for approval
        - never:      Never ask for user approval Execution failures are immediately returned to
          the model

on-request は、聞くかどうかをモデルが判断します。never は聞きません。never の説明にある「実行の失敗はすぐにモデルへ返される」という一文が、この方針の性格をよく表しています。人に聞いて止まる代わりに、失敗をモデルが受け取って自分で次の手を考える形になります。

3つの組み合わせが既定として用意されている

2つの軸を掛け合わせると6通りありますが、公式ドキュメントが名前をつけて案内しているのは3つです。

Auto の状態では、公式の説明によれば、Codex は作業フォルダの中でファイルを読み、編集し、コマンドを実行するところまでを自動で行います。第3回で「既定のまま進めてください」と書いたのはこの状態です。

表の一番下だけ、向く場面の書き方が違うことに気づいたでしょうか。Full Access は「こういう作業に向く」ではなく「こういう環境でだけ」と書いてあります。理由は次の節です。

ネットワークは既定で切れている

意外とつまずくのがここです。

公式ドキュメントによれば、既定の workspace-write ではネットワークが切られています。設定で有効にしない限り、外へは出られません。既定は「ネットワークなし、書き込みは作業中のワークスペースに限る」と説明されています。

つまり npm install も pip install も、既定のままでは失敗します。「依頼したのにライブラリを入れてくれない」と思ったときの原因は、たいていこれです。

対処は2つあります。必要なパッケージを先に自分で入れておくか、設定でネットワークを有効にするかです。前者を勧めます。依存の追加は、何が入るかを人が決めたほうがよい種類の判断だからです。ライブラリを1つ増やすことは、そのライブラリの更新と脆弱性を引き受けることでもあります。

作業フォルダの外を触らせたいとき

作業が複数のフォルダにまたがることはあります。そのために、枠を広げずに範囲だけ足す指定があります。

--add-dir <DIR> は、書き込みを許す場所を追加します。danger-full-access にするのと比べて、広げた範囲が明示的に残るのが利点です。

--worktree は、Git の管理下に新しい作業ツリーを作ってその中で動かします。元のブランチの作業を止めずに、別の変更を並行して試せます。試した結果が気に入らなければ、その作業ツリーごと捨てられます。

どちらも、広げるのではなく、置き場所を変えるという発想です。範囲を広げると戻すのが大変になりますが、置き場所を分ければ捨てるだけで済みます。

名前に「危険」と書かれている指定

ヘルプにこう書かれた指定があります。

--dangerously-bypass-approvals-and-sandbox
        Skip all confirmation prompts and execute commands without sandboxing. EXTREMELY
        DANGEROUS. Intended solely for running in environments that are externally sandboxed

読むべきは最後の一文です。「外部でサンドボックス化された環境で動かすことだけを意図している」。使ってよいのは、外側に別の隔離があるとき、たとえば使い捨てのコンテナや仮想マシンの中だけです。

自分のパソコンで使う指定ではありません。この指定を必要だと感じたときは、たいてい別の問題が起きています。ネットワークが要るなら設定で有効にすればよく、外のフォルダが要るなら --add-dir で足せます。全部を外す必要がある場面は、手元の作業ではほとんど出てきません。

承認だけを自動化したい場合には --approve-for-me があります。承認の求めを自動の確認へ回す指定で、その確認は workspace-write のサンドボックスの中で行われます。枠は残したまま、止まる回数だけ減らす形です。

自分のコマンドを枠の中で試す

どこまで通るのかを確かめたいときは、Codex に依頼せずに枠だけを使えます。codex sandbox に続けてコマンドを書くと、そのコマンドを Codex と同じ枠の中で実行します。

codex sandbox npm test

ビルドやテストが枠の中で通るかどうかを、先に自分で確かめられます。依頼の途中で失敗するより、こちらのほうが原因の切り分けが速く済みます。

組織で使う場合には、権限の組み合わせに名前をつけて配る仕組みもあります。-P, --permission-profile <NAME> で、設定に定義された権限のプロファイルを指定します。個人で使うぶんには、既定の3つで足ります。

どこを緩めるかを決める基準

まとめると、判断の基準はひとつです。戻せるかどうか。

ファイルの書き換えは、Git があれば戻せます。だから workspace-write は既定として案内されています。外部への送信、本番のデータベースへの書き込み、デプロイは戻せません。だから、それらに届く範囲は、頼んだときだけ開けます。

第3回で書いた「戻せない操作は、依頼した覚えがなければ止める」は、設定の側から見るとこの形になります。

次の回

枠と止まり方が決まりました。第6回では、その枠の中でどう依頼するかを扱います。同じ作業でも、依頼の書き方で結果は変わります。先に計画だけ出させるプランモードも、ここで扱います。

参照した公式情報

• OpenAI「Sandbox」「Permissions」「Agent approvals & security」「Configuration Reference」（developers.openai.com/codex、2026年9月時点）
• コマンドの引数と可能な値は codex-cli 0.154.0 を執筆環境へ導入して取得