Codex命令规则怎么写？prefix_rule匹配、冲突与执行前检查

Codex执行某条命令时反复请求批准，或团队想固定命令边界，可以使用本地.rules规则。它处理的是沙箱外命令的决策，并不代替AGENTS.md项目说明。本文先在独立练习文件里检查规则，再决定是否加入实际配置，不需要真实运行GitHub操作。

第一步：确认使用的是哪个执行环境

官方将规则标为实验功能。本地Codex在启动时扫描有效配置层旁的rules目录，例如用户层~/.codex/rules/。项目层只有项目.codex配置受信任时才加载。Work Cloud的Local computer access使用受支持的托管rules TOML字段，不能直接假定它读取本地.rules。

先确认当前客户端与配置层，再备份已有规则文件。不要为了消除一次提示而把所有命令都设成allow；allow会允许匹配命令在沙箱外运行而不再逐次询问。管理员的限制及其他执行策略仍要一并检查。

第二步：写一条范围明确的练习规则

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "查看PR前核对目标仓库",
    match = ["gh pr view 123"],
    not_match = ["gh pr --repo example/repo view 123"],
)

将这段保存为自己练习目录里的review.rules，不覆盖现有default.rules。规则语言是Starlark，语法类似Python，但不能当普通Python脚本执行。pattern按命令参数列表的准确前缀匹配，不是搜索整条字符串包含某个词。

因此gh pr view 123符合前三个参数；把–repo提前放到pr后面，参数顺序改变就不再匹配这条规则。match和not_match是加载时验证的例子，帮助发现误判，不会真的替你调用命令，也不会自动扩大匹配范围。

第三步：先检查决策，不执行目标命令

codex execpolicy check --pretty --rules ./review.rules -- gh pr view 123
codex execpolicy check --pretty --rules ./review.rules -- gh pr --repo example/repo view 123

查看输出JSON中的严格决策及匹配规则。第一条应命中刚写的prompt；第二条应没有命中这一个前缀。不要把“未命中此文件”解释成所有环境都会自动允许，它还取决于其他规则与执行政策。检查工具用于解释规则，不等于实际执行后的业务结果。

第四步：检查多文件冲突和Shell包装

多个规则同时命中时，采用最严格决策：forbidden高于prompt，prompt高于allow。可重复传入–rules合并文件检查。若原本以为允许却被阻止，先看所有命中条目和理由，不能只看自己新增的最后一行。

对于bash -lc等包装，能够安全解析的简单命令链会拆开逐条判断，以最严格结果为准。包含变量、重定向或复杂控制流时可能按整个Shell调用检查。不要用一个宽泛的bash前缀绕过细粒度规则；也别假设允许一个只读命令就允许后面所有动作。

第五步：启用、重启与验收

确认练习结果后，将必要规则合并到有效配置层的.rules文件并重启Codex。用户在终端界面接受的允许列表会写入用户层default.rules，应同时查看，防止重复、过宽或互相矛盾。移除规则时只删对应条目，保留他人配置。

验收清单：客户端和配置层正确；准确参数顺序命中；相近命令未误命中；多文件最严格决策符合预期；组合命令边界已检查；重启后行为一致；回滚文件可恢复。

完成标准不是提示框变少，而是同一类命令在预期范围内获得一致决策。后续换客户端或切到云环境时重新核对加载位置，不把本地测试结果直接推广为全团队政策。

写规则理由时用能被同事读懂的具体目的，例如查看目标仓库，而不是笼统写“安全”。若要阻止一个操作，可在理由里指出允许的替代路径。排查期间把实际参数列表与匹配结果保存到练习记录，避免凭提示框文案猜规则到底来自哪个文件。

官方资料

资料核对日期：2026年11月11日。

• OpenAI：Rules