# 放权 · 沙箱、审批与规则 · Codex · 多 Agent 的异步编码工作流 **作者** Aklman · **章节** 04 / 12 · **首发** 2026.08 · **语言** 中文为主, 中英双语 **原文** https://library.aklman.com/books/codex/04-approvals **全书 markdown** https://library.aklman.com/books/codex/llms.md **上一章** https://library.aklman.com/books/codex/03-cli/llms.md **下一章** https://library.aklman.com/books/codex/05-agents-md/llms.md > 本章来自 Aklman · Library, 完整免费阅读。允许 AI 摘读、引用、问答; 转载请保留作者署名与原文链接 (CC BY-NC-ND 4.0, https://library.aklman.com/license)。 --- > Codex 的安全模型是两个旋钮:沙箱定它「技术上能碰什么」(read-only / workspace-write / danger-full-access),审批策略定它「什么时候要问你」(untrusted / on-request / never)。默认的 Auto 档 —— 工作区随便写、越界才问 —— 加上默认断网和 .git 等保护路径,是多数活的甜点位。往细处走有规则文件:用 prefix_rule 给命令前缀定白灰黑名单,连 bash -lc 里藏的复合命令都会被拆开逐条审。最后一层最有意思:账号与组织可用时,把审批本身交给 reviewer agent —— auto_review 替你看越界请求,拦下外传数据、探凭据、破坏性动作。 放它上云、放它无人值守之前,得先搞清楚它「能碰什么、什么时候要问你」。如果你记忆里 Codex 的放权是「suggest / auto-edit / full-auto」三档,那已经过时了 —— 那套旧命名如今只剩 full-auto 作为一个弃用兼容 flag 残留在 codex exec 里(会打印告警,官方让你改用显式的 --sandbox)。现在的安全模型是两个正交的旋钮:沙箱定它技术上能做什么,审批定它什么时候必须停下来问 —— 再加上一层规则,和一个能替你把关的 reviewer agent。这一章讲怎么把这套调到「信方向就松、信不过的点钉死」。 ### I · 两个旋钮:能做什么,要不要问 Codex 的安全控制来自两层,分开转:**沙箱模式**定它技术上能做什么 —— 在哪写、能不能联网;**审批策略**定它什么时候必须先问你。[^1]两个旋钮各三档: | 旋钮 | 从紧到松 | |---|---| | 沙箱 | `read-only` · `workspace-write` · `danger-full-access` | | 审批 | `untrusted` · `on-request` · `never` | 沙箱作用的是它派生的每一个命令 —— git、包管理器、测试器,统统继承同一条边界,靠操作系统原生强制(macOS 的 Seatbelt、Linux / WSL2 的 bubblewrap、Windows 的原生沙箱)。[^2]这一点很重要:沙箱不是「模型答应不越界」,是「操作系统不让它越界」—— 你信的是强制的边界,不是它的意图。两个旋钮组合出你要的自由度:read-only + on-request 是最安全的调研档,danger-full-access + never 是全放行(只在隔离环境用)。 --- ### II · 默认与甜点位:Auto 档 多数活的甜点位是 **Auto 预设**:`workspace-write` 加 `on-request` —— 工作目录里随它读、改、跑命令,只有越界(工作区外写、要联网)才停下问你。[^1]Codex 启动时还会替你猜:目录在版本控制里就推荐 Auto,不在就推荐 read-only —— 因为有 git 兜底的地方,试错成本低。[^2]想临时收紧,`/permissions` 一键切 read-only,只聊不改。[^1] Auto 档有两条默认的硬边界,值得记牢。其一:**workspace-write 下网络默认是关的** —— 要放开得显式在 config 里写 `network_access = true`,断网是默认,不是意外。[^1]其二:就算在可写的工作区里,也有几条**保护路径**:`.git`、`.agents`、`.codex` 递归只读 —— 它能改你的源码,但改不了版本库元数据和它自己的配置。[^1]这两条是「放权但不失控」的地基:你放开的是工作区,不是整台机器。 --- ### III · 规则:给命令前缀定白灰黑名单 旋钮是粗调,规则是细调。规则(实验特性)控制 Codex 能在沙箱外跑哪些命令:一个 `.rules` 文件里用 `prefix_rule` 给命令前缀定裁决 —— `allow` 直接放行、`prompt` 每次问、`forbidden` 直接拦;多条命中,最严的赢。[^3] _一条规则:gh pr view 允许但每次问,带内联测试_ ```text title="~/.codex/rules/default.rules" ```python prefix_rule( pattern = ["gh", "pr", "view"], decision = "prompt", justification = "看 PR 可以,但要我点头", match = ["gh pr view 7888", "gh pr view --repo openai/codex"], not_match = ["gh pr merge 7888"], ) ``` ``` 规则最要紧的一条性质,是它拆得开复合命令。有人把危险动作藏在安全命令后面 —— `git add . && rm -rf /`。只要这串命令是普通词加安全操作符,Codex 就用 tree-sitter 把它拆成两条逐个判:就算你允许了 `git add`,后面那条 `rm -rf /` 会被单独评估,整条命令因此不会被自动放行。[^3]写完规则用 `codex execpolicy check` 拿具体命令测一测,别等它到线上才发现规则写漏了。[^3] --- ### IV · 把审批本身交给一个 reviewer 最后一层最有意思:账号与组织策略允许时,审批不一定要你亲自点。`approvals_reviewer` 默认是 `user`(问你),改成 `auto_review`,越界请求就先送给一个独立的 reviewer agent 判 —— 它只看那些本来就要停下问人的动作:沙箱升权、被拦的网络请求、可写根外的改动、有副作用的 MCP 调用。[^4]说清楚:这是**审查者的替换,不是权限的放开** —— 它不扩大可写范围、不开网络、不动保护路径,只改「谁来审这个越界」。[^4] reviewer 的策略默认拦几类真危险的动作:把私有数据或凭据外传、探凭据、持续削弱安全、有重大不可逆风险的破坏。[^4]它还带熔断:同一轮里连续拒绝 3 次(或滚动窗口内 10 次),Codex 直接中止本轮 —— 免得 agent 在越权尝试上死循环;判断出错时 fail closed(宁可拦错,不放过)。[^4]被误拦了也有退路:`/approve` 对某个被拒动作放行一次重试。这一层是无人值守(第 9 章)真正的价值 —— 没有人在场时,得有个东西替你说不。 多 Agent 不会另开一条安全后门。子 agent 继承父线程这轮的沙箱与 permission mode;你临时切成 read-only,孩子也会被重新套上 read-only,即使它自己的 TOML 写了更松的默认。[^5]CLI 里后台线程仍可能提出审批,弹层会标清来源;不能弹新审批的非交互流程则直接失败、把结果交回主线程。角色可以分工,权限不能偷偷升级。 > 反过来的纪律:auto_review 不是把安全外包,别用它替代好的沙箱设计。它只评估「已经要越界」的动作 —— 待在沙箱内的常规操作根本不经它;它也会犯错,尤其在对抗性场景里。真正的地基仍是把沙箱和审批调对,规则钉死那几个不能碰的前缀,auto_review 是这之上的一层,不是这之下的替身。 动手 · 把放权从直觉调成配置: - 在一个有 git 的项目里确认默认落在 Auto(workspace-write + on-request),用 /status 看当前档。 - 给一个你不想让它随便跑的命令前缀写一条 prompt 规则,用 codex execpolicy check 验它真拦。 - 如果账号里可用,在一个长任务上试一次 auto_review,读它拦下 / 放行的记录 —— 判断它的口味和你的是否一致。 > 信方向就松档, > 信不过的点用规矩钉死 ## 引用与参考 01 · OpenAI Codex 文档 · Agent approvals & security —— 安全控制来自两层:Sandbox mode 定它技术上能做什么(在哪写、能否联网),Approval policy 定它什么时候必须先问你。默认 agent 断网;本地用 OS 沙箱把它限制在工作区。Auto 预设(--sandbox workspace-write --ask-for-approval on-request)让它在工作目录里自动读、改、跑命令,越界(工作区外写、要联网)才问。可用 /permissions 切 read-only。默认 workspace-write 下网络关闭,需显式 [sandbox_workspace_write] network_access = true 打开。可写根里仍有保护路径:.git、.agents、.codex 递归只读。截至 2026-08-05。 (OpenAI · Agent approvals & security) 02 · OpenAI Codex 文档 · Sandbox —— 常见沙箱模式:read-only(只读,改文件 / 跑命令要批)、workspace-write(读 + 在工作区内写 + 跑常规本地命令,是低摩擦默认)、danger-full-access(无沙箱限制)。常见审批策略:untrusted(非信任集里的命令先问)、on-request(默认在沙箱内工作,越界才问)、never(不停下来问)。沙箱作用于派生命令(git、包管理器、测试器都继承同一边界),OS 原生强制(macOS Seatbelt、Linux/WSL2 bubblewrap、Windows 原生沙箱)。启动时检测:版本库目录推荐 Auto,非版本库推荐 read-only。截至 2026-08-05。 (OpenAI · Sandbox) 03 · OpenAI Codex 文档 · Rules(实验特性)—— 用规则控制 Codex 能在沙箱外跑哪些命令。.rules 文件用 Starlark 写 prefix_rule(pattern 命令前缀、decision = allow / prompt / forbidden、justification、match / not_match 内联测试);多条匹配时最严的赢(forbidden > prompt > allow)。放 ~/.codex/rules/ 或项目 .codex/rules/(仅信任项目加载)。对 bash -lc 里 && 串起的复合命令,若只含普通词 + 安全操作符,Codex 会用 tree-sitter 拆开逐条判 —— 所以 git add . && rm -rf / 不会因你允许了 git add 就整条放行。codex execpolicy check 可测试规则。截至 2026-08-05。 (OpenAI · Rules) 04 · OpenAI Codex 文档 · Auto-review —— 把沙箱边界上的人工审批换成一个独立的 reviewer agent:approvals_reviewer = "user"(默认)或 "auto_review"。它只评估那些本来就要停下问人的越界请求(沙箱升权、被拦的网络请求、可写根外的文件改动、有副作用的 MCP / app 调用),是审查者的替换,不是权限的放开。策略默认拦:外传私有数据 / 凭据、探凭据、持续削弱安全、有重大不可逆风险的破坏性动作。带熔断:同一轮连续 3 次拒绝(或滚动窗口内 10 次)就中止本轮;出错 fail closed。/approve 可对某个被拒动作放行一次重试。截至 2026-08-05。 (OpenAI · Auto-review) 05 · OpenAI · Subagents / Approvals and sandbox controls —— 子 agent 继承父线程当前沙箱与 permission mode;父线程本轮的 live override 会重新施加到子线程。CLI 中即使你正看主线程,inactive 子线程也可能弹审批,overlay 会标出来源,按 o 可打开该线程。不能显示新审批的非交互流程里,越界动作失败并回报主线程。截至 2026-08-05。 (OpenAI · Subagent approvals) --- *放权 · 沙箱、审批与规则 · Codex · 多 Agent 的异步编码工作流 · Aklman 著 · CC BY-NC-ND 4.0 · https://library.aklman.com/books/codex/04-approvals*