Codex をチームで使い始めると、最初に迷うのはモデル性能ではありません。どこまで自動で実行させ、どこから人間の承認に戻すかです。
毎回すべて承認すると開発速度は出ません。逆に full access で放置すると、ファイル変更、ネットワークアクセス、秘密情報、ローカルサービスへの接続が一気に危なくなります。この記事では、2026年5月29日時点の OpenAI 公式 docs と security 記事を前提に、Codex の sandbox / approvals / Auto-review / permissions profile をどう組み合わせるかを実務向けに整理します。
Codex の background task や automation の使い分けを先に見たい場合は Codex Automations 実践ガイド、組織ルール全体の雛形は AIコーディングツールの社内ガイドライン を合わせて読むと位置づけがつかみやすいです。
先に結論: まず workspace-write + on-request を標準にする
個人の検証でも、チーム導入でも、最初の標準はかなり保守的で構いません。
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"この組み合わせでは、Codex は作業ディレクトリ内のファイルを編集し、通常のローカルコマンドを実行できます。一方で、workspace の外を触る、ネットワークへ出る、より危険な操作をする場合は承認に戻ります。
重要なのは、approval_policy だけで安全性を作ろうとしないことです。approval は「境界を越えるときに止める仕組み」であって、境界そのものではありません。境界は sandbox と permissions profile で作ります。
私は次の順で決めます。
| 判断 | 推奨 |
|---|---|
| 読むだけの調査 | read-only + on-request |
| 通常の実装・修正 | workspace-write + on-request |
| 長い作業で承認待ちを減らしたい | workspace-write + on-request + Auto-review |
| CI や監査の非対話実行 | read-only + never か、明示 profile |
| 一時的な強い操作 | 人間が見ている短時間だけ例外扱い |
| 常時 full access | 原則やらない |
sandbox と approval は別物として扱う
OpenAI の Codex docs では、sandbox は Codex が実行するコマンドの技術的な境界、approval はその境界を越えるときの確認フローとして整理されています。ここを混ぜると設計を誤ります。
たとえば、次の2つは同じではありません。
workspace-writeで workspace 内だけを書けるapproval_policy = "never"で止まらずに進む
前者は実行範囲を狭める設定です。後者は承認プロンプトを出さない設定です。never を使っても sandbox が残っていれば、その中でできる範囲に制限されます。ただし、danger-full-access と never を組み合わせると、sandbox も承認も外れます。これは便利なモードではなく、明示的に危険を引き受けるモードです。
実務では「承認を減らしたい」から full access に寄せるのではなく、よく使う安全な範囲を sandbox 側へ寄せる方が安定します。
permissions profile は「チーム用の最小権限」に向いている
Codex の新しい permissions profile は、filesystem と network のルールをまとめた named profile です。まだ beta 扱いですが、チームで使うなら考え方はかなり実用的です。
ここで一つ注意があります。permissions profile は、この記事の前半で使った旧 sandbox 設定とそのまま併用できません。default_permissions に切り替えるなら、active config から sandbox_mode と sandbox_workspace_write を外し、approval の方だけを別に残します。つまり workspace-write + on-request は最初の標準例、permissions profile はそこから境界定義を移し替える次の段階です。
たとえば、通常開発用へ移行するなら次のように切れます。
default_permissions = "project-edit"
approval_policy = "on-request"
approvals_reviewer = "user"
[permissions.project-edit]
description = "Project editing with limited network access."
extends = ":workspace"
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"
[permissions.project-edit.network]
enabled = true
[permissions.project-edit.network.domains]
"api.openai.com" = "allow"
"*.github.com" = "allow"
"objects.githubusercontent.com" = "allow"
"tracking.example.com" = "deny"この profile の意図は単純です。
- workspace は編集できる
.envは読ませない.devcontainerは読むだけにする- network は必要な宛先だけにする
- deny は allow より強くする
ここで *.github.com のような allowlist を雑に広げすぎると、network 境界の意味が薄れます。最初は build、package install、GitHub API、社内 artifact registry のように「本当に必要な宛先」だけを足すべきです。
Auto-review は権限緩和ではない
Auto-review は、承認待ちを別の reviewer agent に回す仕組みです。主 agent の sandbox、network、filesystem の境界は変わりません。
つまり Auto-review は次の用途に向きます。
- 長い修正中に、低リスクな境界越えで毎回人間を止めたくない
- approval の判断理由をログとして残したい
- 人間の集中を高リスクな判断に寄せたい
一方で、次の用途には向きません。
- sandbox を広げる代わりに使う
- network allowlist を雑にする
- 秘密情報の読み取りや送信を任せる
- 破壊的操作を自動承認させる
私なら、Auto-review を入れる前にまず workspace-write + on-request で1週間ほど使い、何が頻繁に承認待ちになるかを見ます。そこで pnpm run test や gh pr view のように明らかに安全で反復するものだけ、rules や permissions profile に寄せます。Auto-review の policy を広げるのは最後です。
network は「必要になったら都度開ける」では遅い
Codex の事故は、ファイル編集だけでは起きません。外部ページ、package registry、GitHub、MCP server、社内 API、ローカル dev server への接続でも起きます。
特に危ないのは次のパターンです。
- 外部ページの手順を読ませ、そのまま shell に反映させる
curl | shを便利コマンドとして許すlocalhostや private network を広く開ける- Docker socket や Unix socket を安易に許可する
*allow で public network を全部通す
OpenAI docs でも、local / private network には DNS rebinding を意識した guard があり、localhost や 127.0.0.1 は明示的に allowlist する設計になっています。これは面倒だからではなく、ローカルサービスが実質的な高権限 API になるからです。
Codex に web 調査も任せるなら、MCP prompt injection 対策ガイド と同じ発想で、外部テキストは「命令」ではなく「未信頼の入力」として扱います。記事、issue、README、Stack Overflow、package README の内容を読ませることと、それを実行させることは別です。
App Server や automation では approval を UI/ログから消さない
Codex App Server を自社 UI に埋め込む場合も、approval を例外処理にしてはいけません。approval は Codex の作業ループの一部です。
Codex App Server ガイド でも書いた通り、App Server の価値は thread、event stream、approval request をクライアント側で扱える点にあります。ここで「最終結果だけ表示する」実装にすると、何を承認し、何を拒否し、どの network access が発生したのかが見えなくなります。
automation でも同じです。background で動かすほど、次を残すべきです。
- 実行した prompt
- 触った branch / worktree
- approval request と判断理由
- network allow / deny
- MCP server や app tool の呼び出し
- 最終 diff と検証結果
Codex の価値は「人間が見なくてよい」ことではありません。人間が見るべき差分と判断だけを前に戻すことです。
実務用の初期設定チェックリスト
チーム導入時は、次の順に決めると破綻しにくいです。
- 標準モードを
workspace-write + on-requestにする - secrets と
.envを deny する - network は allowlist から始める
localhostと private network は用途別に明示許可する- Docker socket / Unix socket は原則閉じる
- full access を常用禁止にする
- Auto-review は approval volume を見てから入れる
- 承認、tool 実行、network policy のログを見る担当を決める
- 例外申請の単位を「人」ではなく「作業種別」にする
- 月1回、denied / approved の傾向を見直す
このチェックリストは、AIコーディングツールの社内ルールにそのまま入れられます。個人の善意に任せるより、作業種別ごとの標準 profile を用意した方が運用は安定します。
まとめ
Codex の sandbox / approvals 設計で大事なのは、開発者を止めすぎないことではありません。止めるべき場所で確実に止まり、それ以外は安全な境界内で進めることです。
最初は workspace-write + on-request で十分です。そこから、よく使う安全な操作を permissions profile や rules に寄せ、承認待ちが多い場合だけ Auto-review を入れます。network は broad allow ではなく、目的ごとの allowlist で始めます。
Codex を安全に使うとは、Codex を信用しないという意味ではありません。Codex が強く動ける範囲を、先に人間が設計するという意味です。