Codexのrulesは、サンドボックス（作業できる範囲を区切る仕組み）の外でCodexがコマンドを動かす時の扱いを、あらかじめ決めておくファイルです。扱いは「確認なしで許可する」「毎回確認する」「禁止する」の3つから選べます。~/.codex/rules/に.rulesファイルを置き、prefix_rule()で「このコマンドで始まるなら、こう扱う」と書きます。複数のルールに当てはまった時に選ばれるのは、いちばん厳しい扱いです。書いたルールは、codex execpolicy checkで事前に試せます。
この記事は、OpenAIの公式資料（Rules、Agent approvals & security、Configuration Reference、Managed configuration）を2026年10月25日に確認して作成しました。編集部はCodex CLI 0.164.0で、練習用のrulesファイルをcodex execpolicy checkに読ませ、どの判定になるかを確かめました。一方、実際の会話の中でのrulesの効き方、承認の画面から許可を足す操作、プロジェクトの.codex/rules/の読み込み、管理者がrequirements.tomlで強制する仕組みは、編集部では実測していません。これらは公式資料に基づいて説明します。なお、公式資料ではrulesは実験的な機能で、今後変わる可能性があるとされています。
Codexのrulesとは：サンドボックスの外で動かすコマンドの扱いを決める仕組み
Codexは、ふだんはサンドボックスの中でコマンドを動かします。初期設定（Auto）では、サンドボックスの外に出る必要があるコマンド（たとえば、ネットワークを使うghコマンドや、作業フォルダの外を書き換えるコマンド）は、動かす前に「動かしてよいか」を人に確認します。この確認の回数や範囲を決めるのが、承認ポリシー（approval_policy）です。
rulesは、この確認をコマンドごとに細かく決めるためのものです。たとえば「git statusのような読むだけのコマンドは確認なしでよい」「git pushは必ず確認してほしい」「rmは使わせない」といった決まりを、ファイルに書いておけます。毎回同じ確認に答える手間を減らしつつ、危ないコマンドを止めやすくなるのが利点です（ただし、後で説明するように、まとめて書かれたコマンドでは判定のされ方が変わることがあります）。
rulesで選べる3つの扱い
allow：確認なしで、サンドボックスの外で動かしてよい。ルールにdecisionを書かなかった時は、この扱いになります（どのルールにも当たらないコマンドが許可される、という意味ではありません）。prompt：当てはまるコマンドを動かす前に、毎回確認する。forbidden：確認も出さずに、動かすのを断る。
rulesファイルの置き場所と、読み込まれる条件
rulesファイルは、Codexの設定ファイル（config.toml）を置くフォルダの中にrules/フォルダを作り、その中に.rulesという拡張子で置きます。個人用なら~/.codex/rules/default.rulesです。Codexは起動する時に、個人用の~/.codex/や、チームで配る設定（Team Config）の場所など、使っている設定の場所のrules/を読み込みます。書き足したり直したりした後は、Codexを起動し直してください。プロジェクトの.codex/rules/には、次に説明する条件があります。
プロジェクトの.codex/rules/は信頼済みの時だけ読まれる
リポジトリ（プログラムのファイル一式）の中の.codex/rules/にも置けます。ただし公式資料によると、読み込まれるのは、そのプロジェクトをCodexで「信頼する」と設定している時だけです。信頼していないプロジェクトでは、.codex/にある設定・フック・ルールがまとめて読み飛ばされます。信頼の考え方はCodexのconfig.tomlの記事で説明しています。
承認の画面で許可すると、default.rulesに書かれる
Codex CLIの対話画面で、確認に答える時にそのコマンドを許可の一覧に加えると、Codexは個人用の~/.codex/rules/default.rulesに書き込みます。次からは同じ並びのコマンドで確認を省けるようになります。また、初期設定で有効な「Smart approvals」では、確認を求める時にCodexがルールの案（prefix_rule）を出してくることがあり、公式資料は案をよく確かめてから受け入れるよう勧めています。編集部の補足として、短い並びの案ほど多くのコマンドに当てはまります。どこまでのコマンドを許可する案なのかを確かめてから選んでください。
会社の管理者が強制するrules
会社で使う場合、管理者はrequirements.tomlの[rules]でルールを強制できます。こちらはdecisionを必ず書き、使えるのはpromptとforbiddenだけです（allowは書けません）。管理者のルールは個人の.rulesと合わせて判定され、ここでもいちばん厳しい扱いが選ばれます。
rulesの書き方：prefix_ruleの5つの項目
rulesファイルは、Pythonに似た「Starlark」という言語で書きます。ファイルを読んでもほかの場所に影響を出さないように作られた言語です。公式資料の例を、少し短くしたものが次です。
prefix_rule(
pattern = ["gh", "pr", "view"],
decision = "prompt",
justification = "PRの閲覧は確認してから",
match = ["gh pr view 7888", "gh pr view --repo openai/codex"],
not_match = ["gh pr --repo openai/codex view 7888"],
)| 項目 | 内容 |
|---|---|
pattern（必須） | 当てはめるコマンドの、先頭からの並び。["view", "list"]のように入れ子にすると、その位置は「viewかlist」の意味になる |
decision | allow・prompt・forbiddenのどれか。書かなければallow |
justification | このルールがある理由。確認や断りの画面に出ることがある。forbiddenなら代わりの方法も書いておくとよい |
match | このルールに当てはまるはずのコマンドの例 |
not_match | 当てはまらないはずのコマンドの例 |
Codexはコマンドを、プログラムの名前と、その後に続く指定（引数）を1つずつ並べたものとして扱い、patternと先頭から順に比べます。そのため、gh pr viewのルールはgh pr --repo openai/codex view 7888には当たりません。matchとnot_matchは、ルールを読み込む時にCodexが確かめる「小さな試験」です。書き間違いに早く気づけるので、ルールごとに書いておくと安心です。
rulesで複数のルールに当たった時は、いちばん厳しい扱いになる
1つのコマンドが複数のルールに当てはまる時、Codexはforbidden、prompt、allowの順に厳しいと考え、その中でいちばん厳しい扱いを選びます。たとえば、git全体をallowにして、git pushだけをpromptにしておくと、git statusは確認なしで動き、git pushは確認が出ます。書いた順番で決まるわけではないので、「広く許可して、危ないものだけ厳しくする」書き方ができます。
bash -lcでまとめたコマンドとrulesの判定
Codexがコマンドを動かす時、bash -lc "git add . && rm -rf /"のように、いくつかのコマンドを1つの文字列にまとめることがあります。公式資料によると、Codexはbash -lc・bash -cと、同じ形のzsh・shを特別に扱います。
- 中身が、変数やワイルドカード（
*など）を使わない単純な言葉だけで、&&・||・;・|でつないだものなら、Codexは1つずつのコマンドに分けてから判定します。上の例ならgit add .とrm -rf /の2つに分け、厳しいほうの扱いになります。git addを許可していても、一緒に書かれたrm -rf /は見逃されません。 - リダイレクト（
>など）、$(...)、FOO=barのような変数、ワイルドカード、ifやforを使った中身は分けません。bash -lc "<中身全体>"という1つのコマンドとして判定します。
codex execpolicy checkでrulesを試す方法
書いたルールが思ったとおりに働くかは、Codexに作業を頼む前にcodex execpolicy checkで試せます。ルールのファイルと、試したいコマンドを渡します。
codex execpolicy check --pretty \
--rules ~/.codex/rules/default.rules \
-- gh pr view 7888 --json title,body,comments結果はJSON（決まった形の文字データ）で表示され、当てはまったルール、いちばん厳しい扱い、ルールに書いた理由が分かります。--rulesを2回以上書けば、複数のファイルを合わせて試せます。--prettyは結果を読みやすく整えるための指定です。
編集部でrulesを試した結果
編集部は、Codex CLI 0.164.0で練習用のrulesファイルを作り、codex execpolicy checkだけを使って判定を確かめました。ファイルには「gh pr viewは確認」「git status・git diff・git logは許可」「git全体は許可」「git pushは確認」「rmは禁止」の5つを書きました。codex execpolicy checkは、渡したコマンドがどのルールに当たるかを表示するためのもので、編集部は試したコマンドを実際には動かしていません。手元の~/.codex/の設定とルールも、試す前と後で中身が変わっていないことを確かめています。
gh pr view 7888 --json title,bodyはpromptになり、結果にはルールに書いた理由も入っていました。gh pr --repo openai/codex view 7888は、どのルールにも当たりませんでした。この場合、結果にはdecisionの項目そのものが表示されません。git push origin mainは、gitの許可とgit pushの確認の両方に当たり、厳しいほうのpromptになりました。別のファイルでgit pushを禁止にして2つのファイルを一緒に渡すと、forbiddenになりました。rm -rf buildはforbiddenになり、ルールに書いた代わりの方法が結果に出ました。/usr/bin/git statusのように、コマンドを置き場所付き（絶対パス）で書くと、gitのルールには当たりませんでした。--resolve-host-executablesを付けるとgitのルールとして判定され、実際のプログラムの場所も結果に出ました。bash -lc "git add . && rm -rf build"を渡すと、どのルールにも当たりませんでした。リダイレクトやパイプを使った中身でも、結果は同じでした。codex execpolicy checkは渡した並びをそのまま判定し、bash -lcの中身までは分けませんでした。前の章で説明した「分けてから判定する」動きは、公式資料が書いている実際の作業中の扱いです。このコマンドでは確かめることができませんでした。matchに、patternと合わない例（gh pr list）を書いたファイルは、読み込みの時点で「当てはまらない例がある」という内容のエラーになり、判定まで進みませんでした。decision = "ask"のような、使えない値を書いた時もエラーになりました。
どれも1回ずつの試行です。実際の会話の中で同じ判定になるか、すべての版で同じかまでは確かめていません。
rules・承認ポリシー・hooks・AGENTS.mdの違い
| 仕組み | 決めること |
|---|---|
承認ポリシー（approval_policy） | 全体として、どんな時に確認を求めるか |
rules（.rules） | サンドボックスの外で動かすコマンドを、並びごとに許可・確認・禁止する |
| hooks | 決まった時点で自分のスクリプトを動かし、中身を見て止めたり記録したりする |
AGENTS.md | 仕事の進め方を文章で伝える。Codexへのお願いで、仕組みとしての禁止ではない |
rulesと承認ポリシーは、approval_policyの細かい設定（granular）でつながっています。approval_policy = { granular = { ... } }の中でrulesをtrueにすると、promptのルールに当たった時の確認が画面に出るようになります。公式資料によると、この細かい設定では、確認の種類ごとに「表示する」か「自動で断る」かを選べます。また、個人の設定でプロジェクトをtrust_level = "untrusted"にし、approval_policyを書かずにおくと、rulesで許可したコマンド以外はすべて確認が必要になります。
先頭の並びだけでは決められず、コマンドの中身を自分のスクリプトで調べて判断したい時は、rulesではなくCodex hooksが向いています。仕事のルールを文章で伝えるならCodexのAGENTS.mdを使います。
rulesが効かない時の確認順
- Codexを起動し直したか。rulesは起動の時に読み込まれます。
- 置き場所と拡張子は正しいか。設定ファイルを置くフォルダの
rules/の中に、.rulesという拡張子で置きます。 - プロジェクトに置いたなら、信頼済みか。信頼していないプロジェクトの
.codex/rules/は読まれません。 - コマンドの並びが
patternと先頭から合っているか。途中に別の指定（--repoなど）が入ると当たりません。絶対パスで書かれたコマンドにも注意します。 - もっと厳しいルールに当たっていないか。許可したのに確認が出る時は、ほかのファイルや管理者のルールに
promptやforbiddenが無いかを見ます。 - ファイルに書き間違いがないか。
codex execpolicy checkに同じファイルとコマンドを渡し、エラーが出ないか、どのルールに当たるかを確かめます。
Codex CLIでは、権限の設定（読み取り専用やAutoなど）を/permissionsで切り替えられ、作業できるフォルダの範囲は/statusで確かめられます。使い方はCodexのスラッシュコマンドの記事にまとめています。
まとめ：rulesは「確認が多いコマンド」から少しずつ書く
Codexのrulesは、サンドボックスの外で動かすコマンドを、並びごとに許可・確認・禁止するファイルです。最初は、毎回確認に答えている読むだけのコマンドをallowに、絶対に動かしてほしくないコマンドをforbiddenにするところから始めるのがおすすめです。ルールにはmatchとnot_matchの例を添え、codex execpolicy checkで判定を確かめてから使いましょう。rulesは実験的な機能なので、最新の仕様は公式のRulesで確認してください。Codex全体の使い方はCodexの使い方とできることで紹介しています。
