Codex 命令规则怎么写？prefix_rule、allow、prompt、forbidden 与 execpolicy 指南

先说结论：Rules 管理沙箱外命令，不替代沙箱

Codex 的 .rules 文件用于决定某类命令请求在沙箱外执行时是直接允许、每次询问还是禁止。它适合为团队常用且范围明确的命令建立可审计策略，但不能代替文件系统沙箱、网络边界、最小凭证和用户授权。

官方目前将 Rules 标记为实验功能，字段与行为可能变化。上线前应在当前 Codex 版本使用 codex execpolicy check 测试，并保留可回退的默认审批策略，不要把旧教程中的配置直接复制到生产环境。

一、规则文件放在哪里

在活动配置层旁的 rules/ 目录创建 .rules 文件，例如用户层 ~/.codex/rules/default.rules。Codex 启动时会扫描各活动配置层，包括用户层与 Team Config。修改后需要重新启动，让规则重新加载。

项目内 <repo>/.codex/rules/ 只有在项目 .codex/ 配置层被信任时才加载。团队通用规则放在受管理层，个人便捷规则放在用户层，项目特定例外保持窄范围，能减少来源混乱。

二、prefix_rule 的最小结构

每条 prefix_rule() 至少要有非空 pattern。pattern 是按参数位置排列的列表，例如 ['gh','pr','view'] 只匹配以这三个参数开头的命令，而不是任意包含这些文字的字符串。

建议同时写 decision 与 justification。理由不仅帮助未来维护，也可能出现在审批或拒绝提示中。对于 forbidden 规则，最好在理由中给出安全替代方案，而不是只写‘禁止’。

三、allow、prompt、forbidden 分别代表什么

allow 表示匹配的命令可在沙箱外运行且不再提示；prompt 表示每次匹配都需要审批；forbidden 表示直接阻止且不弹审批。省略 decision 时默认是 allow，因此不应为了省字而省略关键意图。

当多条规则同时匹配时，Codex 采用最严格决策：forbidden 高于 prompt，prompt 高于 allow。这使管理员可以用更严格规则覆盖个人允许项，也避免宽泛 allow 意外绕过敏感命令。

四、怎样写精确而不脆弱的 pattern

把稳定的命令和子命令放进前缀，例如 ['git','status']、['gh','pr',['view','list']]。联合字面量可以在一个参数位置匹配多个允许值。不要只允许 ['git']、['python'] 或 ['bash'] 这类过宽前缀。

规则按程序实际接收的参数列表匹配，而不是按人眼看到的整行字符串匹配。选项位置改变会影响命中，例如 gh pr view --repo x 与 gh pr --repo x view 不是相同前缀，必须用测试样例确认。

五、match 与 not_match 是规则的内联单元测试

match 列出应该命中的命令，not_match 列出不应命中的命令。Codex 加载规则时会验证这些样例，可以在规则变更时较早发现前缀写错、参数顺序误判或范围过宽。

每条关键规则至少准备一个正常案例、一个相近但不应命中的案例和一个危险边界案例。团队评审规则时，把测试样例当成策略文档，比只读 pattern 更容易理解实际影响。

六、为什么 shell 包装器需要特别小心

bash -lc、bash -c 及相似的 sh、zsh 包装器可能把多个命令塞进一个字符串。对于只含普通单词并由 &&、||、分号或管道连接的简单线性脚本，Codex 会尝试拆分并分别评估。

例如允许 git add 不会自动允许同一行后的危险删除，因为各子命令会分别匹配并采用最严格结果。但规则设计者仍不应依赖宽泛 shell 允许项，应该直接允许必要的底层命令。

七、哪些复合脚本不会被拆分

当脚本包含重定向、命令替换、环境变量赋值、通配符或控制流时，Codex不会尝试细拆，而是把整个 bash -lc <script> 当作单个调用匹配。这是保守行为，避免错误理解复杂 shell 语义。

因此不要为某个复杂脚本创建允许所有 bash -lc 的规则。更好的做法是把受审计逻辑放进仓库内固定脚本，只允许精确脚本路径，并让脚本自身校验参数、目标目录和失败条件。

八、怎样用 execpolicy 检查规则

使用 codex execpolicy check --pretty --rules <文件> -- <命令及参数> 可在保存或发布策略前查看最严格决策、匹配规则和理由。多个规则文件可重复传入 --rules，模拟用户层、项目层和团队层组合效果。

测试应覆盖允许、询问、禁止和未匹配四类结果，并在 Codex 升级后重新运行。把测试命令放进 CI 或团队脚本，可以防止规则重构时悄悄扩大权限。

九、TUI 允许列表与 Smart approvals 的关系

在 TUI 中把命令加入允许列表时，Codex 可能写入用户层 ~/.codex/rules/default.rules，让未来运行跳过相同提示。Smart approvals 也可能在升级请求中建议 prefix_rule。

接受建议前应检查它是否只覆盖当前需要的前缀、是否包含可控参数、是否会跨项目生效。一次方便的点击可能变成长期用户级规则，定期审计默认规则文件很有必要。

十、管理员与团队如何分层

管理员可以通过 requirements.toml 强制更严格的 prefix_rule。管理层规则只能收紧，而不应允许个人绕过组织要求。团队应记录规则负责人、变更原因、测试样例和复审日期。

建议把部署、删除、凭证管理、远程执行和生产数据库命令设为 prompt 或 forbidden；把只读状态检查限制在明确工具和参数范围。规则不能识别所有业务风险，高影响操作仍需要外层审批与回滚。

十一、常见错误与修正方法

常见错误包括：允许整个解释器、忽略参数顺序、没有 not_match、把规则当网络白名单、用 allow 解决所有弹窗、未重启导致旧配置仍生效。发现行为不符时，先用 execpolicy 检查真实参数列表和命中来源。

如果多条规则重叠，查看最严格决策与 justification；如果项目规则不加载，确认项目 .codex/ 是否受信任；如果团队规则覆盖个人规则，不要尝试绕过，应联系管理员调整受控策略。

十二、安全落地清单

从 read-only 或 workspace-write 沙箱开始；只为重复且低风险命令写规则；pattern 至少覆盖命令和子命令；补充 match 与 not_match；禁止通用 shell 和危险文件操作；用 execpolicy 测试；记录变更；定期删除不用的 allow。

更多 Codex 实践可访问 https://gptupcn.com/codex/ 。权限、审批和 Rules 会随版本更新，最终应以当前官方文档、本机命令帮助和组织策略为准。规则解决的是可预测命令审批，不是替代安全工程。

结语

好的 Codex 命令规则既不会让每个安全动作都反复询问，也不会为便利开放整个 shell。用精确前缀、最严格决策、内联测试与 execpolicy 验证，才能把重复审批变成可维护策略。