用 prefix_rule 给 Codex 立规矩：哪些命令放行、哪些先问、哪些直接拦

Codex 的 rules 是一组 .rules 文件，按命令前缀决定 allow、prompt 还是 forbidden，能把反复点确认变成一次性的文件配置。本文整理了文件位置、prefix_rule 写法、execpolicy check 测试流程，以及复合 shell 命令和选项顺序带来的匹配陷阱。

规则是什么、放在哪

• 规则与 approval mode、sandbox 并行工作：approval mode 管整体询问频率，规则管具体某条命令
• 三种决定：allow 免询问执行、prompt 每次先问、forbidden 直接拦截；漏写 decision 默认是 allow
• 文件放在活跃 config 层旁边的 rules/ 目录，如 ~/.codex/rules/default.rules；项目级 <repo>/.codex/rules/ 只在信任该项目的 .codex 层后才加载
• 在终端 UI 里点允许加入的命令会自动写进 default.rules，这个文件会悄悄变大，偶尔要检查；改完规则需重启 Codex

prefix_rule 怎么写

• pattern 是必填的非空列表，每个位置可以是字面量或备选列表；decision、justification、match、not_match 可选
• match 和 not_match 里的示例命令会在加载时被 Codex 校验，能提前发现写错的规则
• 前缀匹配要求词序完全一致：gh pr --repo openai/codex view 7888 和 gh pr view 7888 是同一操作，但词序不同就不匹配，要把这些变体写进 not_match 暴露盲区
• forbidden 规则的 justification 可以给出替代建议，比如拦截 git push --force 时提示改用新提交

测试流程

• 用 codex execpolicy check --rules 指定规则文件，对真实命令做检查；--rules 可传多次合并多个文件
• 推荐流程：先写好 match/not_match 示例，再用 execpolicy check 跑三四条真实命令（含一条预期不匹配的），重启后在真实会话里试一遍
• 项目规则要等队友在自己机器上跑过同样的检查再提交

多条规则冲突与 shell 包装

• 多条规则同时命中时取最严格的：forbidden 优先于 prompt，prompt 优先于 allow；管理员还能通过 requirements.toml 强制限制，个人规则无法覆盖
• bash -c、bash -lc 及 zsh/sh 等价形式会被特殊处理：纯 &&、||、;、| 连接的简单命令会被拆开逐条评估，所以允许 git add 不会连带放行 rm -rf /
• 一旦脚本含重定向、变量替换、通配符或控制流，整条命令不再拆分，作为整体匹配规则——git status > out.txt 就是一条命令，allow 规则是否生效要用 execpolicy check 验证

常见坑

• Smart approvals 默认开启，Codex 升权时会建议 prefix_rule，容易顺手批准过宽的前缀，接受前先检查 pattern 长度
• pattern 写太短会覆盖过广：["git"] 放行所有 Git 子命令，["git", "status"] 才是安全粒度
• Work Cloud 环境不读本地 .rules 文件，走 Work Cloud 自身策略，管理员在 Agent Security 的 rules TOML 字段配置
• 规则功能标记为 experimental，前缀匹配只是防线之一，不能替代 sandbox 和服务端分支保护

落地建议

• 先给每天高频跑的只读命令写窄前缀 allow 规则，减少打断
• 对绝不该执行的命令写 forbidden 并附 justification，比如拦截 force push
• 把团队实际敲的命令形态作为规则依据，而不是理想化的写法