Codex の Execution policy rules を理解して安全・快適に利用する
Codex CLI(以後は Codex と略します)を使い始めると(Claude Code と比べて)コマンドの承認要求が多いと感じることがあります。

コマンドの承認要求の例
Codex のコマンド実行ポリシー
Claude Code と同様、Codex もコマンド実行のルールを内部的に管理しています。
Codex 上の承認プロンプトで許可したコマンドは設定ファイルに記録され、以降のセッションでは自動的に実行されます。ただし Codex は、承認したコマンドをパラメータや引数も含めて前方一致のルールとして記録します。
そのため、対象のファイル名や引数が変わるたびに、都度承認が必要になります。
例えば、git add foo を許可した後に続けて bar を add しようとすると、改めて git add bar に対する許可が求められます。
これはセキュリティとのトレードオフであり一概に良し悪しは言えませんが、Claude Code に慣れているとやや不便に感じる挙動です。
Codex の Execution policy rules
Codex ではコマンド実行のポリシーを Execution policy rules という概念で管理しています。
すでに Codex を利用されている方であれば ~/.codex/rules/default.rules というファイルが存在するはずです。このファイルには過去に CLI 上で承認したコマンドが Codex によって記録されています。
ルールのカスタマイズ
ドキュメントによると、ユーザーが任意のルールを追加することが可能です。
標準の ~/.codex/rules/default.rules に直接、カスタマイズしたルールを追記することもできますが、このファイルは Codex 上で承認したルールが自動的に追記されるので、カスタマイズに利用することはあまりお勧めしません。ただし、定期的に内容をチェックして承認したルールを棚卸(削除)することを勧めします。
Codex は起動時に ~/.codex/rules/ に存在する*.rules を読み込む仕様のため、カスタマイズ専用のファイルを作成してそちらに追記することをお勧めします(例えば ~/.codex/rules/custom.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",
# `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",
],
)
prefix_rule() で囲まれた範囲が一つのルールです、主に覚える必要があるのは pattern と decisionです。
pattern には許可するコマンドを前方一致の形式で記述します。
pattern = ["gh", "pr", "view"],
この例では gh pr view や gh pr view 7888 のように先頭が一致するコマンドが許可されます。
pattern の内部はネストされたリストを使用できるため、複数の prefix からなるコマンドを許可したい場合は次のように記述可能です。例として git で始まるコマンドのいくつかを許可する場合は次のように記述します。
prefix_rule(pattern=["git", ["status", "diff", "log"]], decision="allow")
上記の例では下記のようなコマンドの実行が許可されます。
git status
git diff
git log HEAD^..HEAD
decision には allow の他に prompt と forbidden があります。複数のコマンドをまとめてブロックしたい場合は次のように記述できます。
prefix_rule(pattern=["git", "push", ["-f", "--force", "--force-with-lease", "--force-if-includes"]], decision="forbidden")
それぞれのルールをファイルに記載するとこのようになります。
prefix_rule(pattern=["git", ["status", "diff", "log"]], decision="allow")
prefix_rule(pattern=["git", "push", ["-f", "--force", "--force-with-lease", "--force-if-includes"]], decision="forbidden")
なお decision の優先順位は forbidden > prompt> allow です。
ルールのテスト
match および not_match を利用すると、追加したルールが意図した挙動であるかを Unit Test の形式で記述することができます。
先ほどの decision="allow" ルールに対して match と not_match を追加してみます。
prefix_rule(
pattern=["git", ["status", "diff", "log"]],
decision="allow",
match = [
"git status",
"git diff",
"git log origin/main main"
],
not_match = [
"git commit -m 'message'",
]
)
この状態で Codex を起動すると正常に起動するはずです、もし match や not_match が pattern の内容と一致しない(指定したルールと異なっている)内容で記述した状態で Codex を起動するとエラーメッセージと共に起動に失敗します。
例えば以下のケースでは match および not_match が pattern の内容と一致しないので起動しません。
prefix_rule(
pattern=["git", ["status", "diff", "log"]],
decision="allow",
match = [
"git add foo" # pattern で許可していないコマンドなのでエラー
],
not_match = [
"git log" # pattern で許可しているコマンドなのでエラー
]
)
任意のコマンドのルール適用結果を検証する
任意のコマンドが記述したルールによってどのように解釈されるのかを検証するための codex execpolicy check コマンドが用意されています。
先ほど書いたルール custom.rules を使って codex execpolicy check を実行すると git status がルールによって許可されることを検証できます("decision": "allow")。
% codex execpolicy check --pretty \
--rules ~/.codex/rules/custom.rules \
-- git status
{
"matchedRules": [
{
"prefixRuleMatch": {
"matchedPrefix": [
"git",
"status"
],
"decision": "allow"
}
}
],
"decision": "allow"
}
試しにルールに含まれていないコマンド(以下の例では git add)で実行すると、マッチするルールが存在しないことがわかります("matchedRules": [])。
% codex execpolicy check --pretty \
--rules ~/.codex/rules/custom.rules \
-- git add
{
"matchedRules": []
}
注意事項
ルールの記述にミスがあると Codex が正常に立ち上がらなくなることがあります。その際は、ルールが正しく記述されているか、codex execpolicy check の出力結果が正しか、などを確認すると良いです(最悪、カスタマイズしたファイルを削除することで立ち上がるようになるはずです)。
なお、Execution policy rules はセキュリティに関わる機能です。利用にあたっては公式ドキュメント等を確認のうえ、各自の責任で設定・運用してください。
Discussion