本文为非官方中文翻译，内容以 OpenAI 官方英文文档为准。
官方来源：https://developers.openai.com/codex/rules

规则

使用规则来控制 Codex 可以在沙箱外运行哪些命令。

规则是实验性的，可能会发生变化。

创建规则文件

在活动配置层旁边的 rules/ 文件夹下创建一个 .rules 文件（例如，~/.codex/rules/default.rules）。

添加一条规则。此示例会在允许 gh pr view 在沙箱外运行前进行提示。

# 在沙箱外运行前，对以前缀 `gh pr view` 开头的命令进行提示。
prefix_rule(
    # 要匹配的前缀。
    pattern = ["gh", "pr", "view"],

    # 当 Codex 请求运行匹配命令时要采取的操作。
    decision = "prompt",

    # 关于此规则存在原因的可选说明。
    justification = "允许在批准后查看 PR",

    # `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",
    ],
)

重启 Codex。

Codex 会在启动时扫描每个活动配置层下的 rules/，包括 Team Config 位置以及位于 ~/.codex/rules/ 的用户层。位于 /.codex/rules/ 下的项目本地规则，仅在项目 .codex/ 层被信任时才会加载。

当你在 TUI 中将某个命令添加到允许列表时，Codex 会写入用户层的 ~/.codex/rules/default.rules，这样未来运行时就可以跳过提示。

当启用 Smart approvals（默认）时，Codex 可能会在升级权限请求期间为你建议一条 prefix_rule。接受前请仔细检查建议的前缀。

管理员还可以从 requirements.toml 强制实施限制性的 prefix_rule 条目。

理解规则字段

prefix_rule() 支持以下字段：

pattern （必填）：一个非空列表，用于定义要匹配的命令前缀。每个元素可以是：
- 一个字面字符串（例如，"pr"）。
- 一个字面值联合（例如，["view", "list"]），用于匹配该参数位置上的备选值。
decision （默认为 "allow"）：规则匹配时要采取的操作。当多条规则匹配时，Codex 会应用最严格的决定（forbidden > prompt > allow）。
- allow：在不提示的情况下于沙箱外运行该命令。
- prompt：每次匹配调用前都进行提示。
- forbidden：不提示，直接阻止该请求。
justification （可选）：规则的人类可读、非空原因。Codex 可能会在批准提示或拒绝消息中显示它。当你使用 forbidden 时，应在适当情况下在说明中包含推荐的替代方案（例如，"Use \rg` instead of `grep`."`）。
match 和 not_match （默认为 []）：Codex 在加载规则时会验证的示例。使用它们可以在规则生效前发现错误。

当 Codex 考虑运行某个命令时，它会将命令的参数列表与 pattern 进行比较。在内部，Codex 将该命令视为参数列表（类似于 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（参见语言规范）。它的语法类似 Python，但设计目标是安全运行：规则引擎可以在没有副作用的情况下运行它（例如，不会触碰文件系统）。

创建规则文件​

理解规则字段​

Shell 包装器与复合命令​

当 Codex 可以安全拆分脚本时​

当 Codex 不会拆分脚本时​

测试规则文件​

理解规则语言​