古法编程

OpenAI Codex Rules 用来控制哪些命令可以在沙箱外运行、哪些需要提示、哪些直接禁止。把 .rules 文件放到对应的 rules/ 目录后重启 Codex，再用 codex execpolicy check 验证匹配结果和最严格决策。

OpenAI Codex Rules：规则配置与命令控制

Rules 目前是实验性功能，接口可能变动。

创建规则文件

  1. 在靠近激活配置层的 rules/ 文件夹里创建 .rules 文件，例如 ~/.codex/rules/default.rules。
  2. 添加规则。下面这个例子会在允许 gh pr view 之前先提示：
# 在沙箱外运行前提示 prefix 为 `gh pr view` 的命令。
prefix_rule(
    # 要匹配的命令前缀。
    pattern = ["gh", "pr", "view"],

    # 匹配时采取的动作。
    decision = "prompt",

    # 可选：规则存在的原因。
    justification = "Viewing PRs is allowed with approval",

    # `match` 和 `not_match` 是可选的“内联单元测试”。
    match = [
        "gh pr view 7888",
        "gh pr view --repo openai/codex",
        "gh pr view 7888 --json title,body,comments",
    ],
    not_match = [
        # 不匹配，因为 `pattern` 必须是精确前缀。
        "gh pr --repo openai/codex view 7888",
    ],
)
  1. 重启 Codex。

Codex 启动时会扫描每个激活配置层下的 rules/，包括 Team Config 位置和用户层 ~/.codex/rules/。项目内的 <repo>/.codex/rules/ 只有在项目 .codex/ 层被信任时才会加载。

当你在 TUI 里把某个命令加入允许列表时，Codex 会把规则写入用户层 ~/.codex/rules/default.rules，这样后续运行就可以跳过提示。

启用 Smart approvals 时，Codex 在升级权限请求中可能会替你提议一个 prefix_rule。接受前要仔细检查建议的前缀。

管理员也可以在 requirements.toml 里强制下发更严格的 prefix_rule。

规则字段说明

prefix_rule() 支持这些字段：

  • pattern (required)：非空列表，用来定义要匹配的命令前缀。每个元素可以是：
    • 字面量字符串，例如 "pr"
    • 字面量联合，例如 ["view", "list"]，表示该位置可匹配多个值之一
  • decision (defaults to "allow")：规则匹配时采取的动作。多条规则同时匹配时，Codex 使用最严格的决策（forbidden > prompt > allow）。
    • allow：在沙箱外运行，不提示
    • prompt：每次匹配都先提示
    • forbidden：直接阻止请求，不提示
  • justification (optional)：非空、可读的原因说明。Codex 可能会在审批提示或拒绝消息里显示它。使用 forbidden 时，适合在这里写推荐替代方案，比如 "Use \rg` instead of `grep`."`
  • match 和 not_match (defaults to [])：Codex 在加载规则时会验证的示例，用来尽早发现写错的规则

当 Codex 判断某条命令是否可运行时，会把命令参数列表和 pattern 做比较。内部处理方式和 execvp(3) 接收到的参数列表一致。

Shell 包装器和复合命令

有些工具会把多个 shell 命令包在一次调用里，例如：

["bash", "-lc", "git add . && rm -rf /"]

因为这种命令可能把多个动作藏在同一个字符串里，Codex 会对 bash -lc、bash -c 以及对应的 zsh / sh 形式做特殊处理。

Codex 可以安全拆分的情况

如果 shell 脚本只是一条线性命令链，并且只包含：

  • 纯字面量，没有变量展开、VAR=...、$FOO、* 等
  • 用安全运算符连接，例如 &&、||、; 或 |

Codex 会用 tree-sitter 解析脚本，并在应用规则前拆成多条独立命令。

上面的脚本会被视为两条命令：

  • ["git", "add", "."]
  • ["rm", "-rf", "/"]

然后 Codex 分别对它们应用规则，最后取最严格的结果。

即使你允许 pattern=["git", "add"]，Codex 也不会因为 git add . && rm -rf / 而自动放行，因为 rm -rf / 会被单独评估，并阻止整个调用通过。

这样可以避免危险命令被夹带在安全命令后面。

Codex 不会拆分的情况

如果脚本用了更复杂的 shell 特性，例如：

  • 重定向（>、>>、<）
  • 替换（$(...)）
  • 环境变量（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 语法，参考 language spec。它的语法像 Python，但设计目标是安全执行：规则引擎可以在没有副作用的情况下运行它，比如不会去触碰文件系统。

常见问题

OpenAI Codex 规则文件修改后怎么生效

修改 .rules 后需要重启 Codex，运行中的 session 不会自动重新加载规则。启动时会重新扫描 rules/ 下的内容。

OpenAI Codex 怎么让团队统一使用同一套规则

把 .rules 文件放到仓库的 .codex/rules/ 目录并提交到 Git。Codex 在启动时会读取项目级规则，但前提是项目的 .codex/ 层已被信任。

prefix_rule 可以同时允许和禁止相似命令吗

可以。通过不同的规则分别设置 allow 和 forbidden，Codex 会优先采用更严格的决策。比如先禁止 git push --force，再允许普通 git push。