Codex rulesの書き方と承認範囲を安全に確認する実践手順

Codex rulesとは何か

Codex rulesは、Codexがコマンドを実行するときに「サンドボックスの外で進めてよいか」「実行前に確認するか」「その要求を拒否するか」を決める規則です。OpenAI公式のRules文書では、規則は実験的な機能であり、今後変わる可能性があると説明されています。したがって、設定を書いたら永続的な保証だと考えるのではなく、利用中のCodex CLIの版と公式文書を一緒に確認するのが基本です。

ここで混同しやすいのが、Codexが作業の方針を読むファイルと、コマンドの実行判定を行うファイルの違いです。AGENTS.mdは、命名規則やテスト方針、変更時の注意点などをCodexへ伝えるための文書です。一方、.rulesは実行されるコマンドの引数列を照合し、実行前の確認や拒否を決めます。前者に「確認してから実行する」と書いても、後者の判定が変わるわけではありません。

また、rulesはサンドボックスそのものをなくすスイッチではありません。特定のコマンドが規則に一致しても、作業場所、外部接続、OS側の隔離、プロジェクトの信頼状態など別の条件が残ります。規則は「どのコマンドをどの判定に結び付けるか」を担当し、サンドボックスや承認設定と組み合わせて働くものだと理解すると、許可されたはずなのに確認が出る状況も調べやすくなります。

2026年9月11日に rules を見直す理由

2026年9月9日に公開されたCodex 0.154.0では、GPT-6-Astraのモデル選択、作業用ワークツリー、Windowsの共有サーバーなど複数の更新に加え、承認確認が会話の要約後も権限の文脈を保ちやすくなる変更が案内されました。規則を一度書いたら終わりではなく、会話の継続、回答後の追加指示、作業の再開といった場面で「その許可がまだ同じ範囲か」を確認する必要性が高まっています。

この更新は、すべての規則が広く効くようになったという意味ではありません。OpenAI公式文書は、規則の読み込み先、信頼されたプロジェクト層、最も厳しい判定の採用を明示しています。つまり、版が新しくなった今こそ、ユーザー全体の設定に積み上がった許可を棚卸しし、プロジェクト単位で済むものを分け、コマンドの先頭部分が必要以上に広くなっていないかを見直すタイミングです。

新しい版を試す場合は、既存の.rulesをそのまま信頼するのではなく、まず読み込まれるファイルと判定結果を記録します。特にWindowsでは、同じ文字列に見える要求でも、PowerShellや実行ファイルの呼び出し方が変わることがあります。公式のリリースノート、Rules文書、実際のexecpolicy checkの出力を突き合わせると、更新による差分と環境固有の差分を分けて考えられます。

rulesファイルの置き場所と範囲

Rules文書の基本は、アクティブな設定層の横にあるrules/フォルダへ.rulesファイルを置くことです。代表的なファイル名はdefault.rulesですが、複数ファイルを用意して判定時に指定することもできます。重要なのはファイル名より、どの設定層のrules/が読み込まれるか、そしてその層が現在のセッションで有効かです。

ユーザー層に置く場合

ユーザー層は、どのプロジェクトからでも同じ読み取りコマンドを使いたいときに便利です。たとえば、git statusやgit diffのように、作業内容を確認するだけのコマンドを共通化する用途なら検討しやすいでしょう。ただし、同じgitでもgit pushやgit resetまで含めて許可する規則にすると、意図していないリポジトリにも影響します。共通化するのはコマンドの最小単位にとどめ、書いた理由をjustificationへ残します。

Codexの画面でコマンドの許可を記憶させた場合、公式文書ではユーザー層の~/.codex/rules/default.rulesへ書き込まれると説明されています。目の前のプロジェクトだけで必要だった許可が全体へ保存されていないか、編集後にこのファイルを確認する習慣を持つと安心です。

プロジェクト層に置く場合

プロジェクト層は、特定のリポジトリでだけ必要なコマンドを限定する場所です。プロジェクトの設定を信頼していない場合は、/.codex/rules/の規則が読み込まれません。これは不具合ではなく、作業対象から設定を受け入れるかどうかを分けるための境界です。新しく配置したのに効かないときは、規則の内容だけでなく、プロジェクトの信頼状態と起動し直したかを確認します。

プロジェクト層の.rulesを共有する場合は、そこに書かれた許可がそのリポジトリを開く人へどのような判断を求めるかをレビューします。読み取りだけの規則、確認を残す規則、拒否する規則を混ぜること自体はできますが、目的が分からない短い規則を増やすと、後から判定理由を追えません。ファイルを小さく保ち、コマンドごとに理由を付ける方が保守しやすい設計です。

prefix_ruleの基本と書き方

.rulesファイルはStarlark形式で記述し、中心になるのがprefix_rule()です。Rules文書によると、patternは必須の空でないリストで、コマンドの引数列の先頭から照合されます。文字列を並べた部分はその順番で一致し、ある位置にリストを置けば、その位置で複数の文字列を候補にできます。名前の通り、完全な文字列ではなく先頭部分を指定するため、範囲を狭く書くことが重要です。

prefix_rule(
    pattern = ["git", "status"],
    decision = "allow",
    justification = "作業ツリーの状態確認だけを許可する",
    match = ["git status", "git status --short"],
    not_match = ["git push origin main"],
)

decisionで3つの扱いを分ける

decisionを省略するとallowが既定値になりますが、記事や共有設定では明示する方が意図を読み取りやすくなります。allowは一致したコマンドを確認なしでサンドボックス外へ進める判定、promptは一致するたびに確認を残す判定、forbiddenは確認を挟まず要求を拒否する判定です。複数の規則が同じ要求に一致した場合は、forbidden、prompt、allowの順に厳しい判定が優先されます。

prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
    justification = "共有先へ送る操作なので毎回確認する",
    match = ["git push origin main"],
)

prefix_rule(
    pattern = ["rm"],
    decision = "forbidden",
    justification = "この環境では削除コマンドを許可しない",
)

「確認をなくしたいから」といって、pattern = ["git"]のような広い指定から始めるのは避けます。状態確認と履歴変更、ローカル操作と共有先への送信では、失敗したときの影響が違います。読み取りをallow、変更をprompt、環境で禁止する操作をforbiddenへ分けると、規則の意図と実際の判定が追いやすくなります。

matchとnot_matchを確認材料にする

matchとnot_matchは、規則を書いた人の想定例を残すための項目です。読み込み時に例が検証されるため、引数の順番やスペースの扱いを早い段階で確認できます。たとえば、pattern = ["npm", "test"]に対してnpm run testを想定するなら、実際にCodexへ渡る引数列を確認してからパターンを組み立てます。例が規則の説明とずれていると、規則が有効でも誤った安心感につながります。

コマンドがどのように判定されるか

Codexは、実行しようとするコマンドを引数のリストとして扱い、各.rulesのpatternと照合します。pattern = ["git", "status"]なら、git statusや後ろにオプションを付けた呼び出しの先頭に一致しますが、git stashやgit pushには一致しません。スペースでつながった一つの文章として考えるより、実行ファイル名、サブコマンド、オプションがどの順で渡るかを分けて考える方が正確です。

一致する規則が複数あれば最も厳しい判定が勝ちます。このため、広いallowの後に狭いforbiddenを追加すれば危険な枝だけを止められますが、規則の数が増えるほど読み手は全体を追う必要があります。最初から広い許可を置かず、コマンドの用途ごとに短い規則を作る方が、優先順位を利用した複雑な構成よりも安全です。

シェルの連結を一つの許可と考えない

bash -lc、bash -c、zsh、shなどで複数のコマンドをまとめた呼び出しは、Codexが特別に扱います。単純な語だけで構成された直線的な連結で、&&、||、;、|などの安全な演算子だけが使われている場合は、個別のコマンドへ分解して規則を適用します。単純にgit add .を許可したからといって、後ろに別の危険なコマンドを連結した呼び出し全体が許可されるわけではありません。

一方、リダイレクト、変数展開、コマンド置換、ワイルドカード、条件分岐などが含まれると、Codexは安全に分解できないものとして全体を一つのシェル呼び出しとして扱います。この場合は、個別のgit規則に一致しないため確認が出ることがあります。規則を広げて解決しようとする前に、実際に渡っているラッパーとスクリプトの形を確認します。

# これは説明用の危険な例であり、実行しない
["bash", "-lc", "git add . && rm -rf /"]

execpolicy checkで判定を確かめる

編集した.rulesがどのように評価されるかは、Codex CLIのexecpolicy checkで調べられます。公式文書の例では、--rulesで判定対象のファイルを指定し、--prettyで見やすいJSONを出力します。照合だけを確認する段階では、実際に変更を加えるコマンドではなく、状態表示や差分表示のような安全なコマンドを使います。

codex execpolicy check --pretty \
  --rules ~/.codex/rules/default.rules \
  -- git status

WindowsのPowerShellでは、ユーザー層のファイルを次のように指定できます。パスに空白が入る可能性を考え、引用符を付けたまま確認するのが無難です。

Get-Content "$HOME\.codex\rules\default.rules"
codex execpolicy check --pretty --rules "$HOME\.codex\rules\default.rules" -- git status

結果にmatchedRulesがあれば、どの規則のどの接頭辞が一致したかを確認できます。decisionが表示された場合は最終判定、justificationがあればその理由です。matchedRulesが空なら、パスの違い、パターンの違い、プロジェクト層の未信頼、読み込み前のセッションなどを疑います。複数ファイルを比較するときは--rulesを複数回指定し、どのファイルを混ぜた結果なのかを記録します。

判定確認を安全な順番で進める

1. codex --versionで利用中のCodex CLIの版を確認する。
2. 編集した.rulesの絶対パスと内容を読み直す。
3. codex execpolicy checkでgit statusやgit diff --statのような読み取り系コマンドを確認する。
4. allowの結果でも、対象プロジェクトとサンドボックスの範囲が想定通りかを確認する。
5. 最後に、変更を伴う操作を一つだけ選び、実行前の表示と実行後の結果を照合する。

この順番なら、規則の文法、パス、照合、実行環境の差を一度に混ぜずに調べられます。判定確認のために広い許可へ変更してしまうと、本来の問題が見えなくなるため、検証中も既存の範囲を維持します。

最小権限でrulesを設計する

実用上は、コマンドの種類ごとに許可の強さを分けることが大切です。読み取りは狭い接頭辞でallow、ファイル変更や外部への送信を含む操作はprompt、その環境で扱わない操作はforbiddenにします。ここでいう最小とは、文字数を減らすことではなく、Codexへ渡る引数のうち、許可したい範囲だけを一致させることです。

たとえば、次のように状態確認とテストは狭く許可し、共有先へ送る操作には確認を残せます。

prefix_rule(
    pattern = ["git", "status"],
    decision = "allow",
    justification = "作業ツリーの状態を確認するだけ",
    match = ["git status", "git status --short"],
)

prefix_rule(
    pattern = ["git", "diff"],
    decision = "allow",
    justification = "変更内容を表示するだけ",
    match = ["git diff", "git diff --stat"],
)

prefix_rule(
    pattern = ["npm", "test"],
    decision = "prompt",
    justification = "テスト実行時の環境差を確認する",
    match = ["npm test"],
)

prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
    justification = "共有先への送信前に確認する",
    match = ["git push origin main"],
)

この例でも、実際のプロジェクトで使うコマンドやブランチ名に合わせて見直します。npm testが内部で別のコマンドを呼ぶ場合や、PowerShell経由で実行される場合、Codexが受け取る引数列が変わる可能性があります。規則を追加するたびに、想定した呼び出しと想定外の呼び出しをmatch、not_match、execpolicy checkで確認します。

ユーザー全体の許可とプロジェクト固有の許可を分ける

「どのリポジトリでも使う読み取り」と「このリポジトリでだけ使う書き込み」を同じdefault.rulesへ置かないようにします。全体の設定に置くと、別のリポジトリを開いたときも同じ判定が残ります。プロジェクト固有の操作はプロジェクト層へ置き、読み込まれていることと、その設定を信頼してよいことを別々に確認します。

Codex 0.154.0のリリースでは、再開や分岐した会話で保存済みの権限を扱う変更も案内されています。これは「前回の許可がどこに保存され、次のセッションでどの範囲に見えるか」を意識する理由になります。許可が増えたと感じたら、ユーザー層の.rulesを読み、不要な接頭辞を削り、プロジェクト層へ移すか確認し直します。

AGENTS.md・サンドボックス・rulesの違い

三つの設定を一つのものとして扱うと、原因の切り分けを誤ります。AGENTS.mdはCodexへ渡す作業上の指示、サンドボックスはファイルや外部接続の隔離、rulesはコマンドの接頭辞に対する判定です。AGENTS.mdにテスト手順を書いても、rulesがそのテストコマンドを拒否することがあります。反対に、rulesがallowでも、作業場所や別の保護条件が残っていれば確認が出る場合があります。

この区別を先に行えば、「Codexが指示を読んでいない」のか、「指示は読んだがコマンドが規則に一致しない」のか、「一致したがサンドボックス側の確認が残っている」のかを分けられます。設定を強くすることだけを目標にせず、どの層が最終判断へ影響したかを記録します。

Windowsでrulesが効かないときの確認

Windowsではユーザー層の代表的な場所が%USERPROFILE%\\.codex\\rules\\default.rulesです。PowerShellからは$HOMEを使って同じ場所を参照できます。ファイルを作成または編集した直後は、公式文書に従ってCodexを再起動し、プロジェクト層を使う場合はその.codex層が信頼されているかも確認します。パスを見間違えやすいので、エクスプローラーで開いた場所とCLIが参照する場所を一致させます。

WindowsのPowerShellでは、同じコマンドでもシェルのラッパー、実行ファイルの絶対パス、引数の引用符が変わることがあります。Rules文書はコマンドを引数列として比較すると説明しているため、git statusを許可した規則で、PowerShellの複雑な呼び出し全体が同じように判定されるとは限りません。まず単純なコマンドで照合し、次に実際の呼び出しの形を確認します。

公式のCodexリポジトリには、WindowsやPowerShellでexecpolicy checkの結果と実行時の承認表示が一致しないという報告があります。これはすべての環境で再現するという意味ではありませんが、checkのJSONだけを見て実行経路まで断定しないための注意材料になります。規則が一致しているのに確認が出るときは、まず確認が残ること自体を異常と決め付けず、サンドボックスの境界、プロジェクトの信頼、ラッパーの引数を分けて調べます。

Windowsでの安全な切り分け手順

1. Get-Content "$HOME\\.codex\\rules\\default.rules"で読み込ませたい内容を表示する。
2. codex execpolicy check --pretty --rules "$HOME\\.codex\\rules\\default.rules" -- git statusで単純な引数列を確認する。
3. 画面に出たコマンドの実体が、PowerShellのラッパーを含むものか確認する。
4. プロジェクト層を使う場合は、<repo>\\.codex\\rules\\default.rulesを同じ方法で指定する。
5. 許可の範囲を広げる前に、Codexの版と公式リリースの差分を確認する。

この手順では、rulesのファイルパス、規則の照合、Windowsの呼び出し形、プロジェクト層、版の差を分けて確認できます。特に、確認が出たからといってpattern = ["powershell"]やpattern = ["git"]のような広い規則を追加するのは避けます。原因がラッパーにある場合、広い許可は問題を隠したまま影響範囲だけを増やします。

よくあるトラブルと見直し方

Rulesのトラブルは、文法エラー、ファイルの範囲、パターンの幅、判定の優先順位、実行経路の違いに分けると調べやすくなります。いきなり設定を増やす前に、どのファイルが読まれ、どの規則が一致し、どの判定が最も厳しかったかを確認します。公式のRules文書自体が実験的な機能だと説明しているため、更新後は以前の挙動を前提にせず、短い検証をやり直すことが重要です。

allowなのに毎回確認が出る場合

最初に、execpolicy checkのdecisionが本当にallowなのか、matchedRulesが別の規則を示していないかを確認します。promptやforbiddenが一つでも一致すれば、より厳しい判定が採用されます。次に、実行しようとしたコマンドが単純な引数列なのか、シェルラッパーや変数展開を含む一つの呼び出しなのかを見ます。最後に、rulesが担当する判定とサンドボックス側の確認を分けます。

確認が残ることは、必ずしも規則が壊れていることを意味しません。危険な変更を伴う操作、作業対象の外へ出る操作、プロジェクト層が信頼されていない操作では、別の境界が確認を求めることがあります。判断に迷う場合は、許可を広げずに読み取り系コマンドで再現条件を小さくします。

規則が広すぎる場合

pattern = ["git"]、pattern = ["npm"]、pattern = ["powershell"]のような一語だけの規則は、後続の引数を広く含みます。短い指定が便利に見えても、読み取りと変更、確認と送信を分けられません。git status、git diff、npm testのように目的を表すところまで書き、変更を伴う操作はpromptへ戻す方が、後から見たときに意図を説明できます。

規則を整理するときは、まずユーザー層のdefault.rulesをコピーして内容を確認し、不要な行を削除します。次に、共通して必要な読み取りだけを残し、プロジェクト固有の操作をプロジェクト層へ移します。削除や移動の前後でexecpolicy checkを実行し、同じコマンドがどの判定になったかを記録すれば、変更の影響を追跡できます。

公式情報で更新を確認する場所

Rulesは実験的な機能なので、記事の手順だけを固定的に頼るのではなく、公式の文書とリリースを確認します。特に、ファイルの置き場所、判定値、シェルの分解、複数ファイルの扱いは、CLIの版によって変わる可能性があります。2026年9月11日時点で参照しやすい一次情報は次のとおりです。

• OpenAI公式 Codex Rules：.rulesの作成場所、prefix_ruleのフィールド、シェル連結、execpolicy checkを確認できます。
• OpenAI Codex 0.154.0のリリース：2026年9月9日の更新内容と、権限・承認確認に関する変更を確認できます。
• openai/codexのexecpolicy README：判定の形式、host_executable、JSON出力、複数の.rulesを指定する方法を確認できます。
• openai/codexの実行判定コード：規則一致後の承認判定や、サンドボックス境界との関係を実装の一次情報として確認できます。
• Windowsでのexecpolicy確認に関する公式リポジトリの報告：PowerShellで照合結果と実行時の表示が一致しない場合を調べる入口になります。

公式文書とリリースノートで仕様を確認し、実際の環境では安全なコマンドを一つずつ照合します。個別の報告は環境や版に依存するため、そのまま全環境の仕様だと判断せず、再現条件と利用中の版を添えて切り分けることが大切です。

まとめ

Codex rulesは、Codexへの作業指示を書くファイルではなく、コマンドの接頭辞と判定を結び付ける仕組みです。~/.codex/rules/に置くか、信頼できるプロジェクトの.codex/rules/に置くかで影響範囲が変わり、allow、prompt、forbiddenの優先順位によって最終結果が決まります。まず狭いpatternと理由を用意し、読み取り系から確認します。

規則が効かないときは、ファイルの場所、再起動、プロジェクトの信頼、引数列、シェルラッパー、サンドボックスを順番に分けて調べます。codex execpolicy checkは規則の照合を可視化する入口ですが、実行環境すべての判定を一度に保証するものではありません。2026年9月の更新を使う場合も、公式Rules文書とリリースノートを確認し、不要な許可を増やさないことが安全な運用につながります。