はじめに
Codexにテストを実行してほしいのに、依存パッケージの取得や書き込みで止まることがあります。そこで権限を広げると、今度はどこまで実行できるのかを説明しにくくなります。確認画面の多さだけを見て設定すると、必要な権限も分かりにくいままです。
権限プロファイルでは、ローカルのコマンドが触れるファイルや通信先をまとめます。Rulesでは、コマンドの引数列から許可・確認・禁止の判断を決めます。Claude Codeの権限設定と比べると、「どの操作を許すか」と「どの範囲なら任せるか」を分けて考える意味が見えてきます。この記事では、その設計の違いを押さえてから、テストが止まった場所と直す設定を順に確認します。
権限プロファイルはBeta、Rulesはexperimentalとして提供されています。組織の管理設定がある環境では、その制限も適用されます。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
何ができるかと、誰が確認するか
権限を考えるときは、次の区別が役立ちます。
| 設定 | 決めること | 例 |
|---|---|---|
| サンドボックス・権限プロファイル | コマンドが触れるファイルや通信先 | 作業場所だけ書き込み可能にする |
| 承認ポリシー | 追加の許可が必要なときの扱い | ユーザーへ確認する、確認せず失敗を返す |
| Rules | 対象コマンドの実行判断 | 特定のコマンドを許可、確認、禁止する |
| AGENTS.md | Codexに守ってほしい進め方 | 公開前に成果物を示す |
承認を求めなくなっても、実行できることが増えるとは限りません。approval_policy = "never" は、確認のために止まらない設定です。アクセスできないファイルや通信先まで、自動的に開放されるわけではありません。
ここを取り違えると、無人実行が止まったときに原因を見失います。確認相手がいないことと、必要な操作が可能なことは別です。まず失敗した操作を特定し、書き込み、通信、承認のどこで止まったかを確かめます。
Claude Codeとの違いは、許可を考える単位に表れる
Claude Codeから移る場面を考えます。「いつものコマンドを、確認なしで動かすにはどう書くか」が最初の疑問だとします。Claude Codeの permissions では、Bash(npm run test) や Edit など、ツールとその操作を対象に allow・ask・deny を設定します。編集を自動承認する acceptEdits のように、許可の扱いを選ぶモードもあります。
Codexの権限プロファイルで先に記述するのは、ローカルコマンドが読める場所、書ける場所、通信できる相手です。その範囲と、範囲外で実行するコマンドのRulesを組み合わせます。設定を読む入口が、操作の種類から実行環境の範囲へ移ります。
| 比較する問い | Codexで対応する設定 | Claude Codeで対応する設定 |
|---|---|---|
| どう仕事を進めてほしいか | AGENTS.md |
CLAUDE.md、.claude/rules/ |
| どの操作を許可・確認・禁止するか | サンドボックス外のコマンドを扱うRules | ツールを扱う permissions |
| 実行したプロセスが何に触れられるか | 権限プロファイル・サンドボックス | サンドボックスのファイル・通信設定 |
この対応で見ると、名前が同じRulesよりも、何を判定する機能かが重要になります。Codexの .rules に近い比較相手は、Claude CodeのMarkdownのルールではなく、permissions にあるBashの許可ルールです。ただし、扱う範囲まで同じではありません。
ここからは仕様を踏まえた読み方です。Claude Codeの permissions は、「このツールで、この操作をしてよいか」という判断を組み立てやすい。Codexの権限プロファイルは、「この仕事に必要なアクセスを、どこまで渡すか」という判断を組み立てやすい。思想の違いを語るなら、この許可の単位に注目したいです。開発元の意図や、モデルの性格を断定する話ではありません。
ただし、両者とも実行環境の制限を持っている
ここで「Claude Codeは毎回人に聞き、Codexは環境を制限して自走する」と分けると、実際の機能を取りこぼします。Claude CodeにもOSがファイルと通信の範囲を制限するサンドボックスがあります。制限はそこで動くコマンドの子プロセスにも及びます。
さらにClaude Codeのサンドボックスには、範囲内のコマンドを自動承認するauto-allowがあります。明示的な禁止や一部の確認は残りますが、人が1つずつ承認しなくても進められます。この仕組みは、操作を判定する auto モードとは別です。
つまり、両者とも実行前に操作を判断し、実行中にはアクセスを制限できます。違うのは機能の有無だけでなく、設定上どこから任せ方を組み立てるかです。Claude Codeでもサンドボックスを中心に運用できますし、Codexでも細かく承認を残せます。確認画面の回数から、製品の思想や安全性を直接読み取ることはできません。
テストの許可は、テストコードへの信頼も含む
たとえば、エージェントへ「失敗しているテストを直して、実行してほしい」と頼む場面を考えます。npm run test の実行を許す判断には、分かりやすさがあります。依頼した仕事と、許可するコマンドの名前が対応するからです。
ただし、その名前だけでは、実行される処理の範囲は決まりません。テストスクリプトやテストコードが変われば、同じコマンドからファイルを書き換えたり、外部へ通信したりする処理も実行できます。これはエージェントが悪意を持つかどうかに関係しません。既存のテストが外部サービスへ接続するだけでも起こります。
コマンドを許すルールは、実行するコードの内容を保証しません。そこで、作業ディレクトリへの書き込みは許し、不要なファイルへのアクセスや通信は制限する、という別の判断が必要になります。Codexなら権限プロファイル、Claude Codeならサンドボックスの設定で考える部分です。どちらも、サンドボックス外で実行する例外を認めれば、その実行には同じ制限を期待できません。
一方、通信先を絞れば仕事の目的まで制限できるわけでもありません。たとえば api.github.com への接続を許しても、参照だけに限定したことにはなりません。同じホストで更新操作も扱うため、使う認証情報の権限や、呼び出す操作の確認が別に必要です。ファイルの読み取り専用設定も、外部サービスの読み取り専用を意味しません。
この例から考えると、エージェントを信頼するとは、すべての操作を許すことではありません。試行錯誤してよい場所と、人が判断を引き受ける操作を決めることです。テストの修正と再実行を任せ、公開やマージの前に差分と結果を見る。そう区切れば、途中の操作を全部追い続けなくても、任せた仕事の結果を評価できます。
古いサンドボックス設定とは混ぜない
これまでの設定には、sandbox_mode と sandbox_workspace_write があります。権限プロファイルでは、default_permissions と [permissions] を使います。両方の方式を重ねて、制限が足し合わされると考えてはいけません。
通常、読み込まれた設定のどこかに sandbox_mode があると、そちらの方式が使われます。起動時の --sandbox や、選択した設定プロファイルに残った値も関係します。組織が権限プロファイルを強制しているなら、別の扱いがあります。
たとえば、次の権限プロファイルを書いても、別の設定ファイルへ以前の sandbox_mode が残っていれば、想定どおり使われない原因になります。移行する際は、1つのファイルだけを読むのでは足りません。
既存のサンドボックス設定で必要な動作が明確なら、すべてを移す必要もありません。複数のファイル範囲や通信先を、用途の分かる名前で管理したいときが、プロファイルを検討する場面です。
既定のプロファイルから、必要な差分を足す
組み込みの権限プロファイルには、:read-only、:workspace、:danger-full-access があります。独自のプロファイルを作るときは、既存の保護を引き継げる extends が使えます。
たとえば、編集は作業ディレクトリで行い、コマンドからの外部通信を使わない仕事なら、次のように書けます。古いサンドボックス設定と併用しない前提の例です。
default_permissions = "local-edit" approval_policy = "on-request" [permissions.local-edit] description = "作業場所のファイルを編集し、コマンドの外部通信は使わない" extends = ":workspace" [permissions.local-edit.network] enabled = false
:workspace を引き継ぐと、作業領域への書き込みと、一部の設定ディレクトリなどに対する保護を出発点にできます。全部のパスを自分で列挙するより、何を変えたか読み取りやすくなります。
ただし、これは仕事によっては足りません。まだ依存パッケージが入っていない環境なら、テストの前に通信が必要になることもあります。その時は、コードを直す前の環境準備として扱うか、必要な通信を許すかを決めます。
「テストが動かないから全部開ける」まで飛ばず、どの準備が不足しているかを言える状態にしたいです。
通信先を書くなら、プロキシも確認する
権限プロファイルには、コマンドの通信先を制限する設定があります。注意したいのは、network.enabled = true だけでは、ドメインのルールを適用するプロキシが起動しないことです。
次は、ローカルのコマンドからGitHub APIを読む用途に絞った例です。依存パッケージの取得やGitのすべての操作を通す設定ではありません。
default_permissions = "github-inspect" approval_policy = "on-request" [features] network_proxy = true [permissions.github-inspect] description = "ローカルの確認とGitHub APIの参照" extends = ":read-only" [permissions.github-inspect.network] enabled = true [permissions.github-inspect.network.domains] "api.github.com" = "allow"
この例では、通信を許すことと、プロキシで行き先を絞ることの両方を設定しています。プロキシが有効でなければ、ドメインの一覧を書いただけでは直接通信を制限できません。
ドメイン指定は文字列を含むかではなく、ホスト名のルールとして照合されます。api.github.com はそのホストだけ、*.example.com はサブドメインだけに一致します。必要な接続先を確認せずに * を置くと、許可の範囲を説明できなくなります。
また、許可したホストから別のホストへリダイレクトされる時は、その接続が必要かを別に確かめます。最初から * で全体を開けると、何のために一覧を書いたのかが曖昧になります。
この通信設定が適用されない経路もある
ここまでの話は、サンドボックス内のローカルコマンドが中心です。Codexが使うすべての通信へ、同じ一覧が適用されるわけではありません。
| 操作の経路 | 主に確認する設定 |
|---|---|
| シェルで実行するコマンド | 権限プロファイルとネットワークプロキシ |
| 組み込みのWeb検索 | web_search などの検索設定 |
| 接続したアプリやコネクタ | 接続先の権限とアプリの設定 |
| MCPサーバー | サーバーの設定と接続方式 |
| ブラウザやComputer Use | それぞれの機能・承認設定 |
| クラウドの作業 | クラウド環境の通信設定 |
たとえば、コマンドの通信を止めたのにWeb検索ができるとしても、それだけで設定の不具合とは言えません。異なる経路を使っています。逆に、検索の対象ドメインを絞っても、シェルの通信先が同じ範囲へ制限されることにはなりません。
作業を任せる前に、どのツールがどの経路で情報を読むかを確認します。この整理は、権限を狭めるときだけでなく、必要な情報へアクセスできない原因を探すときにも使えます。
CodexのRulesは、コマンドを対象にする
Claude Codeの .claude/rules/ では、パスに応じたMarkdownの指示を扱いました。Codexの .rules は、それと同じ機能ではありません。コマンドの引数列へ一致する条件を書き、サンドボックス外での実行などの許可判断に使います。
例として、~/.codex/rules/review.rules に次の内容を置きます。
prefix_rule(
pattern = ["gh", "pr", "view"],
decision = "prompt",
justification = "PRの参照をサンドボックス外で実行するときは確認する",
match = [
"gh pr view 123",
"gh pr view 123 --json title,body",
],
not_match = [
"gh pr merge 123",
"gh --repo example/project pr view 123",
],
)
pattern は、コマンドの先頭から引数の並びを照合します。gh という文字列を含むかを見る正規表現ではありません。同じ仕事をするコマンドでも、引数の順番が変われば一致しないことがあります。
decision は、allow、prompt、forbidden を選べます。複数のルールが一致すれば、forbidden、prompt、allow の順で厳しい判断が優先されます。後ろに書いた許可が、先の禁止を打ち消す方式ではありません。
また、allow は単に「この文章の依頼は妥当」という意味ではありません。対象コマンドをサンドボックス外で確認なしに実行できる設定です。["gh"] のように広く書く前に、どの操作まで含まれるかを読みたいです。
Rulesは、実行前に照合結果を試せる
match と not_match は、期待する一致と不一致の例です。さらに、codex execpolicy check で、実際の引数列がどう評価されるか確認できます。
codex execpolicy check --pretty \ --rules ~/.codex/rules/review.rules \ -- gh pr view 123 --json title,body
これはPRを取得するコマンドではありません。渡したルールと引数列を照合します。記事のルールでは、一致した prefix_rule と prompt の判断を確認する用途です。
不一致も試します。
codex execpolicy check --pretty \ --rules ~/.codex/rules/review.rules \ -- gh pr merge 123
ここで対象ルールに一致しないことは、mergeが許可されるという意味ではありません。このファイルのルールから判断が出ないだけです。ほかのルールや権限の設定は、別に関係します。
シェルのラッパーにも注意します。単純な複合コマンドは分割して評価されますが、変数展開やリダイレクトなどを含む時は、全体の呼び出しとして扱われることがあります。普段使う引数列を、そのまま照合にかける方が確実です。
許可は、広げる順番を決めてから書く
Rulesを最初から広く許可すると、動いた理由と開いた範囲が分からなくなります。まず実際の引数列を prompt で確認し、繰り返し使う限定操作だけを allow へ移します。削除、公開、マージなど戻しにくい操作は、明示的に禁止するか、確認を残します。
| 判定 | 向いている場面 | 確認すること |
|---|---|---|
prompt |
初めて使う外部参照や、範囲を見極めたい操作 | 実際の引数列と利用者の判断 |
allow |
目的と範囲が決まった繰り返し操作 | 許可が別のサブコマンドへ広がらないこと |
forbidden |
実行させない操作 | 別の経路やラッパーから迂回できないこと |
1つの許可を足すたびに、一致する例と一致しない例を試します。細かく分けすぎて実際の呼び出しを追えなくなると、失敗時の調査も難しくなります。設定を共有するときには、照合に使ったコマンドと期待する判断も残しておきます。
権限は、結果の評価を代わりにしない
許可されたコマンドが成功しても、仕事の結果が正しいとは限りません。権限プロファイルとRulesは、エージェントが到達できる範囲や実行前の判断を決めます。対象ファイルを読み違えた、古いデータを使った、テストを実行しなかった、といった問題は別の検証で見つけます。
権限の制限と結果の検証を分けて考えると、無人実行へ渡すものも選びやすくなります。読み取りだけで済む調査は読み取り専用にし、変更を作る仕事は専用の作業場所へ分ける。外部へ公開する操作や削除は、許可ルールを細かくするだけで自動化せず、完了条件と人の確認を残します。狭い権限は、失敗をなくすためではなく、失敗したときの影響範囲を小さくするために使います。
操作が拒否されたときも、いきなり全体を許可しません。失敗したコマンド、必要だったパスや接続先、拒否された理由を記録し、その1回だけを再現できるルールから試します。再現できた許可と、同じ接頭辞でも拒否したい操作を並べれば、広すぎるallowを避けられます。
任せる深さは、次の3段階に分けると判断しやすくなります。
| 深さ | 例 | 残す確認 |
|---|---|---|
| 調査 | ファイル、ログ、差分を読む | 根拠になった対象と未確認の範囲 |
| ローカル変更 | Worktree内で編集し、テストを動かす | 差分、テスト結果、レビュー |
| 外部への作用 | push、merge、公開、削除 | 対象と結果を人が確認してから実行 |
権限を広げるほど、失敗した操作を戻せるか、結果を誰が確認するかを依頼へ書きます。読み取りの成功を、そのまま公開まで任せてよい根拠にはしません。
このとき、人の負担がどこへ移るかも考えます。操作ごとの承認を減らせば、作業中の割り込みは減ります。その分、任せる前にアクセス範囲を決め、終わった後に成果物を確かめる必要があります。承認画面で1行のコマンドを見るだけでは、そこから実行されるコードや、使われる認証情報の権限までは分かりません。人が確認できる材料を用意することまで含めて、任せ方を設計します。
確認回数より、説明できる範囲を増やす
設定を適用したら、普段の作業で必要な操作と、許可したくない操作の両方を確かめます。最初から本物の機密ファイルで試す必要はありません。検証用のファイルや接続先で、想定した範囲を確認します。
テストが止まったら、そのコマンドと失敗した操作を残します。依存パッケージを取得できないのか、生成物を書けないのか、承認を待っているのか。次に直す設定が分かれば、作業全体へ強い権限を渡さずに済むかを判断できます。
CLIを更新したりRulesを直したりしたら、許可した操作と拒否した操作を1つずつ再実行します。ルールを保存したことと、今の経路で判定されたことは別だからです。
Claude Codeの許可ルールをCodexへ移すときも、コマンドの一覧をそのまま書き換える前に、その仕事に必要なファイルと通信先を考えます。両者とも、操作の判断と実行環境の制限を組み合わせられます。権限プロファイルとRulesを使い分ける意味は、任せる範囲と例外を別々に説明できることにあります。
権限を広げる前に失敗した操作を特定し、許可と拒否を同じ条件で試す。そして、任せた範囲でできた成果物を確認する。確認を減らして生まれた時間を、設定の理由と仕事の結果を理解するために使いたいです。
本を出しました。宣伝。
