ルール

ルールを使用して、Codex がサンドボックス外で実行できるコマンドを制御します。

ルールファイルを作成する

Work Cloud のローカルコンピューターへのアクセスでは、Agent Security の TOML フィールド rules を使用して、対応する管理対象のコマンドルールを設定します。これらのルールはローカルの実行環境に適用されます。Work のクラウドコンテナでは、既存の Work Cloud ポリシーが使用されます。

ここで説明するローカルの .rules の手順は Codex に適用されます。Work Cloud のローカルコンピューターへのアクセスがローカルのルールファイルを読み込むとは限りません。管理対象の Work の要件については、管理対象の設定と設定リファレンスをご覧ください。

1. アクティブな設定レイヤーの隣にある rules/ フォルダーの下に .rules ファイルを作成します（例：~/.codex/rules/default.rules）。
2. ルールを追加します。次の例では、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",
       ],
   )

3. Codex を再起動します。

Codex は起動時に、Team Config の場所や ~/.codex/rules/ のユーザーレイヤーを含む、すべてのアクティブな設定レイヤーの下にある rules/ をスキャンします。<repo>/.codex/rules/ にあるプロジェクトローカルのルールは、プロジェクトの .codex/ レイヤーが信頼されている場合にのみ読み込まれます。

TUI でコマンドを許可リストに追加すると、Codex はユーザーレイヤーの ~/.codex/rules/default.rules に書き込み、以降の実行では確認を省略できるようにします。

Smart approvals が有効な場合（デフォルト）、Codex は権限昇格リクエストの際に prefix_rule を提案することがあります。承認する前に、提案されたプレフィックスを慎重に確認してください。

管理者は、requirements.toml から制限的な prefix_rule エントリを適用することもできます。

ルールのフィールドを理解する

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 と比較します。内部では、Codex はコマンドを引数のリストとして扱います（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 / を個別に評価するためです。

これにより、安全なコマンドに紛れ込ませて危険なコマンドを実行することを防ぎます。

Codex がスクリプトを分割しない場合

スクリプトで、次のような高度なシェル機能が使用されている場合：

• リダイレクト（>、>>、<）
• 置換（$(...)、...）
• 環境変数（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 に似ていますが、安全に実行できるように設計されています。ルールエンジンは、ファイルシステムへのアクセスなどの副作用を起こさずに実行できます。