コンテンツにスキップ

ルール

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

ルールは試験的な機能であり、変更される可能性があります。

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

  1. アクティブな設定レイヤー（例: ~/.codex/rules/default.rules）の隣にある rules/ フォルダーの下に .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",
    ],
)
  1. Codex を再起動します。

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

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

スマート承認が有効になっている場合（デフォルト）、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 に似ていますが、安全に実行できるよう設計されています。たとえば、ルールエンジンは副作用（ファイルシステムへのアクセスなど）なしで実行できます。