ルールを使うと、Codex がサンドボックスの外で実行できるコマンドを制御できます。
ルールファイルの作成
Work クラウドからローカルコンピューターにアクセスする場合は、エージェントのセキュリティ設定にある TOML の rules フィールドで、サポート対象の管理用コマンドルールを設定します。これらのルールはローカルの実行環境に適用されます。Work クラウドのコンテナには既存の Work クラウドポリシーが適用されます。
以下のローカル .rules ファイルの設定手順は Codex 向けです。Work クラウドからローカルコンピューターにアクセスする場合も、ローカルのルールファイルが読み込まれるとは限りません。管理対象の Work に適用される要件については、管理対象の設定と設定リファレンスを参照してください。
-
拡張子が
.rulesのファイルを、有効な設定レイヤーの設定ファイルと同じディレクトリにあるrules/フォルダ内に作成します（例：~/.codex/rules/default.rules）。 -
ルールを追加します。次の例では、
gh pr viewをサンドボックスの外で実行する前に承認を求めます。# Prompt before running commands with the prefix `gh pr view` outside the sandbox. prefix_rule( # The prefix to match. pattern = ["gh", "pr", "view"], # The action to take when Codex requests to run a matching command. decision = "prompt", # Optional rationale for why this rule exists. justification = "Viewing PRs is allowed with approval", # `match` and `not_match` are optional "inline unit tests" where you can # provide examples of commands that should (or should not) match this rule. match = [ "gh pr view 7888", "gh pr view --repo openai/codex", "gh pr view 7888 --json title,body,comments", ], not_match = [ # Does not match because the `pattern` must be an exact prefix. "gh pr --repo openai/codex view 7888", ], ) -
Codex を再起動します。
Codex は起動時に、有効な設定レイヤーごとに rules/ をスキャンします。対象にはチーム設定の配置先と、ユーザーレイヤーの ~/.codex/rules/ が含まれます。プロジェクト内の <repo>/.codex/rules/ にあるルールは、そのプロジェクトの .codex/ レイヤーが信頼されている場合にのみ読み込まれます。
TUI でコマンドを許可リストに追加すると、Codex はユーザーレイヤーの ~/.codex/rules/default.rules にルールを書き込みます。これにより、次回以降の実行時には承認の確認を省略できます。
スマート承認が有効な場合（デフォルト）、Codex は権限昇格を求める際に prefix_rule を提案することがあります。承認する前に、提案されたプレフィックスをよく確認してください。
管理者は、制限を課す prefix_rule エントリを requirements.toml で強制適用することもできます。
ルールのフィールド
prefix_rule() は次のフィールドをサポートしています。
pattern（必須）：照合するコマンドのプレフィックスを定義する空でないリストです。各要素には次のいずれかを指定します。- 文字列リテラル（例：
"pr"） - リテラルの集合（例：
["view", "list"]）。その位置の引数がいずれかのリテラルに一致すれば、条件を満たします。
- 文字列リテラル（例：
decision（デフォルトは"allow"）：ルールに一致した場合の動作です。複数のルールに一致する場合、Codex は最も厳しい判定を適用します（forbidden>prompt>allow）。allow：承認を求めずに、コマンドをサンドボックスの外で実行します。prompt：一致するコマンドを実行するたびに承認を求めます。forbidden：承認を求めずにリクエストを拒否します。
justification（任意）：ルールを設けた理由を、空でない文字列でわかりやすく記述します。Codex は承認を求める際やリクエストを拒否する際に、この理由を表示することがあります。forbiddenを使う場合は、必要に応じて推奨する代替手段を理由に含めてください（例："Use \rg` instead of `grep`.“`）。matchとnot_match（デフォルトは[]）：Codex がルールを読み込む際に検証するコマンド例です。ルールが適用される前に、設定の誤りを検出できます。
Codex はコマンドを実行するかどうかを判定する際に、コマンドの引数リストを pattern と照合します。内部では、コマンドを引数のリストとして扱います。これは execvp(3) が受け取る形式と同様です。
シェルラッパーと複合コマンド
ツールによっては、次のように複数のシェルコマンドをまとめて 1 回の呼び出しで実行します。
["bash", "-lc", "git add . && rm -rf /"]この形式では、1 つの文字列に複数の操作が隠れている可能性があります。そのため Codex は、bash -lc、bash -c、および zsh や sh での同等の呼び出しを特別に扱います。
スクリプトを安全に分割できる場合
シェルスクリプトがコマンドを順につないだもので、次の条件を両方満たす場合、Codex はスクリプトを分割できます。
- 各コマンドが単純な単語のみで構成されている（変数展開や
VAR=...、$FOO、*などを含まない） - コマンドを安全な演算子（
&&、||、;、|）のみでつないでいる
この場合、Codex は tree-sitter でスクリプトを解析し、個々のコマンドに分割してからルールを適用します。
上の例は、次の 2 つのコマンドとして扱われます。
["git", "add", "."]["rm", "-rf", "/"]
Codex は各コマンドをルールと照合し、最も厳しい判定を採用します。
pattern=["git", "add"] を許可していても、Codex は git add . && rm -rf / を自動的に許可しません。rm -rf / を個別に評価するためです。
これにより、安全なコマンドに紛れ込ませた危険なコマンドの実行を防ぎます。
スクリプトを分割しない場合
スクリプトで次のような高度なシェル機能を使っている場合は、扱いが異なります。
- リダイレクト（
>、>>、<） - コマンド置換（
$(...)、...） - 環境変数（
FOO=bar） - ワイルドカードパターン（
*、?） - 制御構造（
if、for、代入を伴う&&など）
この場合、Codex はスクリプトの解釈や分割を試みません。
呼び出し全体を次の形式で扱います。
["bash", "-lc", "<full script>"]ルールは、この単一の呼び出しに適用されます。
こうすることで、安全に分割できる場合はコマンドごとに評価して安全性を確保し、分割できない場合は呼び出し全体を慎重に扱います。
ルールファイルのテスト
codex execpolicy check を使うと、コマンドにルールがどのように適用されるかをテストできます。
codex execpolicy check --pretty \
--rules ~/.codex/rules/default.rules \
-- gh pr view 7888 --json title,body,commentsこのコマンドは、最も厳しい判定と、一致したすべてのルールを JSON で出力します。一致したルールに justification があれば、その値も含まれます。複数のファイルを組み合わせるには --rules フラグを複数回指定し、出力を整形するには --pretty を追加します。
ルール記述言語
.rules ファイルは Starlark で記述します（言語仕様を参照）。構文は Python に似ていますが、安全に実行できるよう設計されています。ルールエンジンは、ファイルシステムへの変更などの副作用を起こさずにルールを実行できます。