Codexに何を勝手にやらせないか：承認、サンドボックス、ネットワークの扱いと、公式が書く注意を確かめる

3行でいうと

つまみは2つあります。何ができるかを決める sandbox_mode（read-only、workspace-write、danger-full-access）と、いつ人に聞くかを決める approval_policy（on-request、never）です。公式は、サンドボックスが技術的な限界を決め、承認がその限界を越えるときの止まり方を決める、と説明しています。
ローカルでは、ネットワークの接続は既定でオフと書かれています。オンにする方法と、行き先を絞る仕組みも公式にありますが、どちらも注意書きが多い所です。全部を飛ばす --dangerously-bypass-approvals-and-sandbox（別名 --yolo）は、公式が「推奨しない」と書く設定です。
「Approve for me」（Auto-review）は、人の代わりに別のエージェントが承認の可否を見る仕組みです。公式は、囲いを広げるものではなく、完全な安全の保証でもない、と書いています。

この記事は、公式ドキュメントを2026年10月22日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はCodexを入れていますが、使い心地はこの記事には書いていません。設定名、値、コマンドは公式の表記を写したもので、動作確認はしていません。セキュリティに関わる所は、公式が書いている注意を、そのまま伝えることを優先しました。助言ではありません。

先に結論

まず見るもの。 作業の途中で今どの設定かを知りたいときは、セッションの中の /status、変えたいときは /permissions です（CLIのページと「Agent approvals & security」にあります）。アプリとIDE拡張では、入力欄の下の権限のコントロールです。
迷ったときの出発点。 公式のPermission modesのページは、たいていの作業は「Ask for approval」で始めるよう勧めています。CLIの設定では、フラグなしで使えるAutoプリセットは workspace-write と on-request の組み合わせです。
やらせないために効くもの。 ①read-only のサンドボックス、②ネットワークをオフのまま使う、③danger-full-access と --yolo を使わない、④信頼していないフォルダや信頼できないリポジトリでは広げない、の4つです。これは公式の記述を僕らが並べ直したものです。

前提：用語をそろえる

サンドボックス：Codexが動かすコマンドを、決まった囲いの中に閉じ込める仕組みです。公式によると、Codexが起動する git、パッケージマネージャー、テストの実行にも同じ囲いがかかります。
承認（approval）：囲いの外に出ようとしたときに、人に聞くかどうかの決まりです。
ワークスペース：書き込みを許す範囲です。公式は、現在のフォルダと /tmp のような一時フォルダを含む、と書いています。実際の範囲は /status で見られます。
プロンプトインジェクション：読み込んだ文章の中に紛れ込ませた命令で、AIを操ろうとする攻撃です。公式は、Web検索の結果などをこれの入口として注意しています。
Auto-review：人の代わりに、別のエージェント（レビュー役）が承認の可否を判断する仕組みです。

2つのつまみ：サンドボックスと承認

サンドボックス（`sandbox_mode`、CLIでは `--sandbox` か `-s`）

値	公式の説明	確かさ
`read-only`	ファイルを見られる。承認なしには、編集もコマンド実行もできない	文書に書かれている
`workspace-write`	ワークスペースの中で、編集と通常のコマンド実行ができる。ワークスペースの外への書き込みと、ネットワークは承認が要る	文書に書かれている
`danger-full-access`	サンドボックスなし。ファイルとネットワークの囲いがなくなる	文書に書かれている

workspace-write は、ローカルの作業での「低い手間の既定のモード」と、Sandboxingのページにあります。

承認（`approval_policy`、CLIでは `--ask-for-approval` か `-a`）

値	公式の説明	確かさ
`on-request`	サンドボックスの中で作業し、外に出るとき（囲いの外のネットワークなど）に聞く	文書に書かれている
`never`	承認の確認は出ない。サンドボックスの限界の中で、できる範囲を試す	文書に書かれている
`untrusted`	廃止（retired）。選べない。残っていると、クライアントが起動できなくなりうるので、設定、プロファイル、スクリプト、管理用の既定から消すよう書かれている	文書に書かれている
granular	`approval_policy = { granular = { ... } }` の形。キーは `sandbox_approval`、`rules`、`mcp_elicitations`、`request_permissions`、`skill_approval`。選んだ種類だけ確認を出し、他は自動で断る	文書に書かれている

CLIの --ask-for-approval の値は、コマンド一覧の表では on-request と never だけが挙がっています。かつての untrusted のような、厳しめの動きがほしいときは、approval_policy を書かず、[projects."/path"] に trust_level = "untrusted" を置く、と公式は案内しています。これはプロジェクトのローカル設定も無効にする、と書かれています。

danger-full-access と never の組み合わせは、完全なフルアクセスです。公式は、エージェントに全権で動かせたいときだけ使うよう書いています。

アプリ・IDE拡張の「権限モード」

公式のPermission modesのページは、モード選択に4つの選択肢があると書いています。

名前	公式の説明	確かさ
Ask for approval	外部のファイルの編集とインターネットの利用は、毎回聞く。ワークスペースの中では進める	文書に書かれている
Approve for me	危険かもしれない行動だけ聞く。サンドボックスは同じ `workspace-write`。対象の依頼は自動レビュー（`auto_review`）に回る	文書に書かれている
Full access	インターネットとパソコン上のすべてのファイルに、制限なしでアクセスできる	文書に書かれている
Custom (config.toml)	`config.toml` に書いた権限を使う	文書に書かれている

切り替えは、アプリとIDE拡張では入力欄の下のコントロール、CLIでは /permissions です。
注意として、ページは、選べるモードと今有効なモードは別なので、今のチャットでどれが選ばれているか確かめるよう書いています。docsにあるモードのプレビューは、実際の権限を変えません。
選べるかどうかは、アプリのバージョン、実行環境、ローカルの設定、組織の要件で変わります。管理される環境では、組織の要件が「Ask for approval」も制限しうる、と書かれています。
「Approve for me」が出ないか選べないときの確認項目は、公式のトラブルシューティングにあります。アプリを更新する、設定に features.guardian_approval = false が無いか見る、管理下なら管理者に聞く、です。

プリセットとフラグ（CLI）

「Agent approvals & security」が挙げる組み合わせです。

名前	中身（公式の表記）
Auto（「フラグ不要」と書かれたプリセット）	`--sandbox workspace-write --ask-for-approval on-request`
安全な読み取り専用	`--sandbox read-only --ask-for-approval on-request`
CI向けの読み取り専用（非対話）	`--sandbox read-only --ask-for-approval never`
Auto-review	`--sandbox workspace-write --ask-for-approval on-request -c approvals_reviewer=auto_review`
フルアクセス	`--dangerously-bypass-approvals-and-sandbox`（別名 `--yolo`）。サンドボックスも承認もなし

同じページは、--full-auto には触れていません。僕らは、読んだ範囲では見つかりませんでした。Autoプリセットが、近い役目の組み合わせとして書かれています。
非対話の実行は、codex exec --sandbox workspace-write の形で書かれています。
--cd で作業フォルダを決め、--add-dir で書き込みを許すフォルダを足せます（--add-dir は何度も指定できる、とコマンド一覧の要約にあります）。
コマンド一覧の要約では、--yolo について、外から堅牢にした環境の中だけで使うよう注意されています。

`--approve-for-me` というフラグ（要約で読めた範囲）

コマンド一覧の要約に、--approve-for-me（別名 --not-so-yolo）という項目がありました。on-request の承認と workspace-write を組み合わせたもの、--sandbox と --yolo とは同時に使えない、対話のCLIは --ask-for-approval と一緒だと受け付けない、と書かれていました。ページが長くて、詳しい節は読めていません。使う前に、公式のコマンド一覧で確かめてください。

既定と、フォルダによる違い

公式は、Gitで管理しているフォルダにはAutoを、管理していないフォルダには read-only を勧めています。信頼するまで read-only で始まる場合がある、とも書かれています。
ネットワークの接続は、既定でオフです。
書き込みの範囲を広げたいときは、sandbox_workspace_write.writable_roots に足します。Sandboxingのページは、広げるより、別のプロジェクトやworktreeに分けることを勧めています。
ページ間で、既定の書き方がそろっていない所があります。「Agent approvals & security」はAutoを「フラグ不要」のプリセットとして載せ、Permission modesのページは既定のモードを書かず、Ask for approvalから始めるよう勧めています。画面とCLIで、見え方が違うのかもしれませんが、確認できていません。

守られる場所：書き込める範囲の中でも、触れない所

公式のAgent approvals & securityによると、書き込み可能な範囲の中でも、次の場所は読み取り専用（再帰的）に保たれます。

.git（ディレクトリでもファイルでも。gitdir: で別の場所を指す場合は、その先のGitディレクトリも）
.agents、.codex、.aws（ディレクトリとして存在するとき）

Permissionsのページは、:workspace を元にしたプロファイルでも、この4つの保護は保たれる、と書いています。一方、Sandboxingのページには、これらの記載が見つかりませんでした。

ネットワークの扱い

ローカルのCodex

オンにする。 [sandbox_workspace_write] の network_access = true です。
行き先を絞る。 features.network_proxy は、オンになったネットワークを、ドメインのルールで絞る仕組みです。これ自体は、接続を許すものではありません。公式の整理は次のとおりです。

ネットワーク	プロキシ	結果（公式の説明）
オフ	オン	オフのまま
オン	オフ	制限なしの直接接続
オン	オン	ドメインのルールに従う

ドメインのルールは、許可を基本に書きます。*.example.com はサブドメインだけ、**.example.com は本体とサブドメインの両方、* はすべての許可です。deny（拒否）が常に勝ちます。
既定で、ローカルやプライベートのアドレスへの接続は止められます（allow_local_binding = false）。
Permissionsのページ（Betaと明記）では、network.enabled が既定でオフです。ネットワークをオンにしても、プロキシは自動では始まらず、ドメインのルールもそのままでは効かない、と書かれています。
プロキシは、Web検索、コネクタ、MCPサーバー、ブラウザやComputer Use、Codexのサービス通信、Codex Cloudの通信を管理しません。それぞれ別の制御があります。

Web検索

Web検索の設定 web_search の値は、"cached"（既定）、"live"、"disabled"、"indexed" です。cached はOpenAIが保っている索引を使い、公式は、リスクを下げるがなくしはしない、と書いています。フルアクセス（--yolo など）のときの既定は live です。公式は、Web検索の結果は信頼できない入力として扱うよう書いています。

Codex Cloud

クラウドの環境には、別の設定があります。クラウドの案内ページの例の画面には、プリセットが「Package managers」、追加ドメインが「No additional domains」と出ていますが、既定だとは書かれていません。環境の設定ページには、「Allow Codex to access internet」のスイッチ、プリセット（Package managers、Custom domains only、All (unrestricted)）、追加ドメインが書かれています。既定がどうなっているかは、どちらのページにも書かれていませんでした。実際の画面で確かめてください。

Auto-review（Approve for me）

公式のAuto-reviewのページの要点です。

変わるのは、承認する人だけです。サンドボックスも、ネットワークとファイルの制限も、同じです。公式は、権限を足すものではなく、承認する人の入れ替えだ、と書いています。
対象は、囲いを越える依頼です。権限を上げるシェルのコマンド、止められたネットワーク要求、書き込み範囲の外へのファイル編集、承認が要るMCPやアプリの呼び出しなどです。囲いの中で許される行動は見ません。
設定は、approvals_reviewer = "auto_review" と、on-request のような対話の承認ポリシーの組み合わせです。承認ポリシーだけでは、レビュー役は切り替わりません。approval_policy = "never" のときは、見るべき依頼がそもそも出ないことがあります。
設計上、止めるもの：秘密や認証情報を信頼できない相手に送ること、認証情報やトークンを探ること、広い・継続的なセキュリティの弱体化、取り返しのつかない破壊的な行動。
3回続けて拒否されるか、直近50回のレビューで10回拒否されると、そのターンが中断されます。
レビューは追加のモデル呼び出しを使うので、使用量に加わります。
公式の限界の書き方：判断を誤ることがある、とくに敵対的な状況や普通でない状況で。決まった安全の保証ではなく、サンドボックスの設計、監視、組織の方針と組み合わせるものだ、と。
approval_policy = "never"、:danger-full-access、--yolo は、レビューに必要な承認の依頼そのものを作らないことがある、と注意されています。

プロファイルとルール：どちらも「変わることがある」と書かれている

Permissions（Profiles）。 ページは「Beta」と書き、開発が活発で変わることがあると警告しています。組み込みのプロファイルは :read-only、:workspace、:danger-full-access で、default_permissions で選びます。昔の sandbox_mode と同時には使えません（どちらかを使う）。:danger-full-access を元にしたプロファイルは作れません。
Rules。 どのコマンドをサンドボックスの外で動かしてよいかを決めるものです。ページは「experimental（実験的）で、変わることがある」と書いています。prefix_rule の決定は allow、prompt、forbidden で、複数が一致したら、いちばん厳しいものが勝ちます。公式の注意は、git add を許しても git add . && rm -rf / は許したことにならず、各コマンドは別々に評価される、ということです。リダイレクトや変数などを含むスクリプトは分割されず、bash -lc の呼び出し全体が1つのコマンドとして評価される、とも書かれています。
「feature maturity」のページは、段階の意味（Under development、Experimental、Beta、Stable、Deprecated）を説明していますが、個々の機能にどの段階が付くかは、そのページには書かれていませんでした。

OSごとの仕組み

OS	公式の説明
macOS	組み込みのSeatbelt。そのまま動く
Linux・WSL2	`bubblewrap`（`bwrap`）と `seccomp`。`bwrap` が見つからないか、必要なユーザー名前空間が作れないと、起動時に警告が出る
Windows（PowerShell）	ネイティブのWindowsサンドボックス。`windows.sandbox` の値は `mxc`（互換のある環境で推奨）、`elevated`、`unelevated`（古い代替）

Ubuntu 24.04では、bwrap-userns-restrict のAppArmorプロファイルを読み込む必要があるかもしれません。公式は、まず bwrap のAppArmorプロファイルを読み込み、制限をグローバルに無効にしないよう勧めています。そのプロファイルが使えないか、解決しないときの代わりとして、制限を無効にするコマンドが載っています（「最後の手段」という言葉は読めていません）。
Windowsの unelevated は、ネットワークの隔離が弱く、読み取り拒否のパスを扱えません。フルアクセスは、プロジェクトのフォルダに限られず、データを失うことがある、と注意されています。
DockerなどのコンテナはCodexが必要とする名前空間や bwrap、seccomp を止めることがある、devcontainerは全部の攻撃を防がず、コンテナ内のフルアクセスでは、悪意あるプロジェクトが認証情報を持ち出せる、信頼するリポジトリだけで使う、と公式は書いています。
codex sandbox macos|linux|windows で、サンドボックスの中でコマンドを試せる、と書かれています。

公式が書いている注意（まとめ）

「Agent approvals & security」などで、公式が書いていた注意を、そのまま並べます。

フルアクセスは「推奨しない」「リスクが高い」と書かれ、使うときは注意するよう促されています。
ネットワークとWeb検索は、プロンプトインジェクションの入口になりうる。信頼できない指示を取り込んで従うことがある。
*（すべて許可）は広い許可。範囲を絞ったルールのほうがよい。許可したからといって、行き先が信頼できる証拠にはならない。
DNSの確認は、最善の努力。敵対的なDNSを想定するなら、下の層で外向きの通信も制御する。
dangerously_allow_non_loopback_proxy、dangerously_allow_all_unix_sockets は信頼の境界を広げる。厳しく管理された環境だけで使う。
書き込みの許可は、あとから残る変更を作る。スクリプト、ビルドのフック、シェルの起動ファイル、共有フォルダは、サンドボックスの外で後から実行されうるので、とくに敏感な場所。
管理者が決めたコマンドの許可リストは、承認されたフルエスカレーションで迂回されうる。普通のコマンドとエスカレーションしたコマンドの両方を試す。
安全監視の仕組みが、タスクを止めることがある。ただし、それはサンドボックスや結果の確認の代わりにならない。
テレメトリ（利用の記録）では、log_user_prompt を false のままにする。プロンプトにソースコードが含まれうる。
認証情報の入った auth.json は、パスワードと同じに扱う（01の記事の認証の所を参照）。

僕らの見立て：最初の設定の例

ここからは僕らの見立てです。公式の記載から組み立てたもので、公式の推奨そのものではありません。

練習の間は、Gitで管理している小さなフォルダで、「Ask for approval」（CLIならAuto）のまま使う。
初めて見るリポジトリでは、read-only で中身を読ませるところから始める。
ネットワークは、必要になるまでオフのままにする。必要になったら、* ではなく、行き先を絞る。
承認の画面は、中身を読んでから通す。
--yolo と danger-full-access は、使う理由を言葉にできるまで使わない。

気をつけること

この記事は、実際に使って確かめた記録ではありません。運営者はCodexを入れていますが、使い心地はこの記事には書いていません。設定名、値、コマンドは、公式ページに書かれていたものを写しています。
取得したのは、ページの要約です。コマンド一覧のページは長く、後ろの部分を読み切れていません。codex login の細部、--full-auto の扱い、--approve-for-me の詳しい挙動は、確認できていません。
ページ同士で、書き方がそろっていない所があります（既定のモード、動作環境の要件。クラウドの既定のネットワークは、どのページにも書かれていませんでした）。どれが新しいか、ページに日付が見つからず、判断できていません。
公式ドキュメントの置き場所が、developers.openai.com から learn.chatgpt.com に変わっています。画面の名前や構成は、手元の版と違うことがあります。バージョンつきの記載（例：WSL1は0.115から非対応）は、10月22日に表示されていたものです。
管理された環境（会社のパソコンなど）では、組織の要件が、ここに書いた設定を上書きします。
取得したページの中には、モデルの名前や、一部の地域・プランだけの機能への言及もありました。ここでは扱っていません。
この記事は、セキュリティや法律の助言ではありません。