放权 · 沙箱、审批与规则Set the Leash · Sandbox, Approvals, and Rules.
Codex 的安全模型是两个旋钮:沙箱定它「技术上能碰什么」(read-only / workspace-write / danger-full-access),审批策略定它「什么时候要问你」(untrusted / on-request / never)。默认的 Auto 档 —— 工作区随便写、越界才问 —— 加上默认断网和 .git 等保护路径,是多数活的甜点位。往细处走有规则文件:用 prefix_rule 给命令前缀定白灰黑名单,连 bash -lc 里藏的复合命令都会被拆开逐条审。最后一层最有意思:把审批本身交给一个 reviewer agent —— auto_review 替你看每个越界请求,拦下外传数据、探凭据、破坏性动作。Codex's safety model is two dials: the sandbox sets what it can technically touch (read-only / workspace-write / danger-full-access), the approval policy sets when it must ask (untrusted / on-request / never). The default Auto setting — write freely in the workspace, ask at the boundary — plus network-off-by-default and protected paths like .git, is the sweet spot for most work. Finer control comes from rules files: prefix_rule puts command prefixes on allow / prompt / forbid lists, and even compound commands hiding inside bash -lc get split and judged one by one. The last layer is the most interesting: hand approval itself to a reviewer agent — auto_review reads every boundary-crossing request and blocks exfiltration, credential probing, and destructive actions.
10 分钟 · 初稿 2026.0710 Min · Drafted 2026.07
放它上云、放它无人值守之前,得先搞清楚它「能碰什么、什么时候要问你」。如果你记忆里 Codex 的放权是「suggest / auto-edit / full-auto」三档,那已经过时了 —— 那套旧命名如今只剩 full-auto 作为一个弃用兼容 flag 残留在 codex exec 里(会打印告警,官方让你改用显式的 --sandbox)。现在的安全模型是两个正交的旋钮:沙箱定它技术上能做什么,审批定它什么时候必须停下来问 —— 再加上一层规则,和一个能替你把关的 reviewer agent。这一章讲怎么把这套调到「信方向就松、信不过的点钉死」。Before you send it to the cloud or let it run unattended, you have to settle what it can touch and when it must ask. If your memory of Codex's permissions is a three-way 'suggest / auto-edit / full-auto,' that's out of date — of that old naming only full-auto survives, as a deprecated compatibility flag on codex exec (it prints a warning; the docs tell you to use an explicit --sandbox instead). The model now is two orthogonal dials: the sandbox sets what it can technically do, approvals set when it must stop and ask — plus a layer of rules and a reviewer agent that can gate on your behalf. This chapter tunes all of it to 'loosen where you trust the direction, pin down the points you don't.'
— I
两个旋钮:能做什么,要不要问Two Dials: What It Can Do, Whether to Ask.
Codex 的安全控制来自两层,分开转:沙箱模式定它技术上能做什么 —— 在哪写、能不能联网;审批策略定它什么时候必须先问你。1注 1Note 1OpenAI 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-07-17。OpenAI Codex Docs · Agent approvals & security — security controls come from two layers: Sandbox mode sets what it can technically do (where it writes, whether it reaches the network), Approval policy sets when it must ask you first. By default the agent has no network; locally an OS sandbox confines it to the workspace. The Auto preset (--sandbox workspace-write --ask-for-approval on-request) lets it read, edit, and run commands in the working directory automatically, asking only at the boundary (writing outside the workspace, needing network). Use /permissions to switch to read-only. Under default workspace-write, network is off and needs an explicit [sandbox_workspace_write] network_access = true. Writable roots still contain protected paths: .git, .agents, .codex are recursively read-only. As of 2026-07-17.两个旋钮各三档:Codex's security controls come from two layers, turned separately: sandbox mode sets what it can technically do — where it writes, whether it reaches the network; approval policy sets when it must ask you first.1注 1Note 1OpenAI 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-07-17。OpenAI Codex Docs · Agent approvals & security — security controls come from two layers: Sandbox mode sets what it can technically do (where it writes, whether it reaches the network), Approval policy sets when it must ask you first. By default the agent has no network; locally an OS sandbox confines it to the workspace. The Auto preset (--sandbox workspace-write --ask-for-approval on-request) lets it read, edit, and run commands in the working directory automatically, asking only at the boundary (writing outside the workspace, needing network). Use /permissions to switch to read-only. Under default workspace-write, network is off and needs an explicit [sandbox_workspace_write] network_access = true. Writable roots still contain protected paths: .git, .agents, .codex are recursively read-only. As of 2026-07-17. Three settings on each dial:
旋钮Dial
从紧到松Tight to loose
沙箱Sandbox
read-only · workspace-write · danger-full-access
审批Approvals
untrusted · on-request · never
沙箱作用的是它派生的每一个命令 —— git、包管理器、测试器,统统继承同一条边界,靠操作系统原生强制(macOS 的 Seatbelt、Linux / WSL2 的 bubblewrap、Windows 的原生沙箱)。2注 2Note 2OpenAI 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-07-17。OpenAI Codex Docs · Sandbox — common sandbox modes: read-only (inspect only; edits / commands need approval), workspace-write (read + write within the workspace + run routine local commands — the low-friction default), danger-full-access (no sandbox restrictions). Common approval policies: untrusted (ask before commands outside a trusted set), on-request (work inside the sandbox by default, ask at the boundary), never (don't stop to ask). The sandbox applies to spawned commands (git, package managers, test runners inherit the same boundary), OS-native enforcement (macOS Seatbelt, Linux/WSL2 bubblewrap, Windows native sandbox). On launch it detects: version-controlled folders recommend Auto, non-version-controlled recommend read-only. As of 2026-07-17.这一点很重要:沙箱不是「模型答应不越界」,是「操作系统不让它越界」—— 你信的是强制的边界,不是它的意图。两个旋钮组合出你要的自由度:read-only + on-request 是最安全的调研档,danger-full-access + never 是全放行(只在隔离环境用)。The sandbox applies to every command it spawns — git, package managers, test runners all inherit the same boundary, enforced natively by the operating system (Seatbelt on macOS, bubblewrap on Linux / WSL2, the native sandbox on Windows).2注 2Note 2OpenAI 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-07-17。OpenAI Codex Docs · Sandbox — common sandbox modes: read-only (inspect only; edits / commands need approval), workspace-write (read + write within the workspace + run routine local commands — the low-friction default), danger-full-access (no sandbox restrictions). Common approval policies: untrusted (ask before commands outside a trusted set), on-request (work inside the sandbox by default, ask at the boundary), never (don't stop to ask). The sandbox applies to spawned commands (git, package managers, test runners inherit the same boundary), OS-native enforcement (macOS Seatbelt, Linux/WSL2 bubblewrap, Windows native sandbox). On launch it detects: version-controlled folders recommend Auto, non-version-controlled recommend read-only. As of 2026-07-17. This matters: the sandbox isn't 'the model promises not to overstep,' it's 'the OS won't let it overstep' — you trust an enforced boundary, not its intent. The two dials compose the freedom you want: read-only + on-request is the safest research setting; danger-full-access + never is full access (isolated environments only).
— II
默认与甜点位:Auto 档The Default and the Sweet Spot: Auto.
多数活的甜点位是 Auto 预设:workspace-write 加 on-request —— 工作目录里随它读、改、跑命令,只有越界(工作区外写、要联网)才停下问你。1注 1Note 1OpenAI 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-07-17。OpenAI Codex Docs · Agent approvals & security — security controls come from two layers: Sandbox mode sets what it can technically do (where it writes, whether it reaches the network), Approval policy sets when it must ask you first. By default the agent has no network; locally an OS sandbox confines it to the workspace. The Auto preset (--sandbox workspace-write --ask-for-approval on-request) lets it read, edit, and run commands in the working directory automatically, asking only at the boundary (writing outside the workspace, needing network). Use /permissions to switch to read-only. Under default workspace-write, network is off and needs an explicit [sandbox_workspace_write] network_access = true. Writable roots still contain protected paths: .git, .agents, .codex are recursively read-only. As of 2026-07-17.Codex 启动时还会替你猜:目录在版本控制里就推荐 Auto,不在就推荐 read-only —— 因为有 git 兜底的地方,试错成本低。2注 2Note 2OpenAI 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-07-17。OpenAI Codex Docs · Sandbox — common sandbox modes: read-only (inspect only; edits / commands need approval), workspace-write (read + write within the workspace + run routine local commands — the low-friction default), danger-full-access (no sandbox restrictions). Common approval policies: untrusted (ask before commands outside a trusted set), on-request (work inside the sandbox by default, ask at the boundary), never (don't stop to ask). The sandbox applies to spawned commands (git, package managers, test runners inherit the same boundary), OS-native enforcement (macOS Seatbelt, Linux/WSL2 bubblewrap, Windows native sandbox). On launch it detects: version-controlled folders recommend Auto, non-version-controlled recommend read-only. As of 2026-07-17.想临时收紧,/permissions 一键切 read-only,只聊不改。1注 1Note 1OpenAI 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-07-17。OpenAI Codex Docs · Agent approvals & security — security controls come from two layers: Sandbox mode sets what it can technically do (where it writes, whether it reaches the network), Approval policy sets when it must ask you first. By default the agent has no network; locally an OS sandbox confines it to the workspace. The Auto preset (--sandbox workspace-write --ask-for-approval on-request) lets it read, edit, and run commands in the working directory automatically, asking only at the boundary (writing outside the workspace, needing network). Use /permissions to switch to read-only. Under default workspace-write, network is off and needs an explicit [sandbox_workspace_write] network_access = true. Writable roots still contain protected paths: .git, .agents, .codex are recursively read-only. As of 2026-07-17.The sweet spot for most work is the Auto preset: workspace-write plus on-request — it reads, edits, and runs commands freely in the working directory, stopping to ask only at the boundary (writing outside the workspace, needing network).1注 1Note 1OpenAI 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-07-17。OpenAI Codex Docs · Agent approvals & security — security controls come from two layers: Sandbox mode sets what it can technically do (where it writes, whether it reaches the network), Approval policy sets when it must ask you first. By default the agent has no network; locally an OS sandbox confines it to the workspace. The Auto preset (--sandbox workspace-write --ask-for-approval on-request) lets it read, edit, and run commands in the working directory automatically, asking only at the boundary (writing outside the workspace, needing network). Use /permissions to switch to read-only. Under default workspace-write, network is off and needs an explicit [sandbox_workspace_write] network_access = true. Writable roots still contain protected paths: .git, .agents, .codex are recursively read-only. As of 2026-07-17. On launch Codex even guesses for you: a folder under version control recommends Auto, one that isn't recommends read-only — because where git is a backstop, the cost of a mistake is low.2注 2Note 2OpenAI 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-07-17。OpenAI Codex Docs · Sandbox — common sandbox modes: read-only (inspect only; edits / commands need approval), workspace-write (read + write within the workspace + run routine local commands — the low-friction default), danger-full-access (no sandbox restrictions). Common approval policies: untrusted (ask before commands outside a trusted set), on-request (work inside the sandbox by default, ask at the boundary), never (don't stop to ask). The sandbox applies to spawned commands (git, package managers, test runners inherit the same boundary), OS-native enforcement (macOS Seatbelt, Linux/WSL2 bubblewrap, Windows native sandbox). On launch it detects: version-controlled folders recommend Auto, non-version-controlled recommend read-only. As of 2026-07-17. To tighten temporarily, /permissions switches to read-only for chat-only, no edits.1注 1Note 1OpenAI 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-07-17。OpenAI Codex Docs · Agent approvals & security — security controls come from two layers: Sandbox mode sets what it can technically do (where it writes, whether it reaches the network), Approval policy sets when it must ask you first. By default the agent has no network; locally an OS sandbox confines it to the workspace. The Auto preset (--sandbox workspace-write --ask-for-approval on-request) lets it read, edit, and run commands in the working directory automatically, asking only at the boundary (writing outside the workspace, needing network). Use /permissions to switch to read-only. Under default workspace-write, network is off and needs an explicit [sandbox_workspace_write] network_access = true. Writable roots still contain protected paths: .git, .agents, .codex are recursively read-only. As of 2026-07-17.Auto 档有两条默认的硬边界,值得记牢。其一:workspace-write 下网络默认是关的 —— 要放开得显式在 config 里写 network_access = true,断网是默认,不是意外。1注 1Note 1OpenAI 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-07-17。OpenAI Codex Docs · Agent approvals & security — security controls come from two layers: Sandbox mode sets what it can technically do (where it writes, whether it reaches the network), Approval policy sets when it must ask you first. By default the agent has no network; locally an OS sandbox confines it to the workspace. The Auto preset (--sandbox workspace-write --ask-for-approval on-request) lets it read, edit, and run commands in the working directory automatically, asking only at the boundary (writing outside the workspace, needing network). Use /permissions to switch to read-only. Under default workspace-write, network is off and needs an explicit [sandbox_workspace_write] network_access = true. Writable roots still contain protected paths: .git, .agents, .codex are recursively read-only. As of 2026-07-17.其二:就算在可写的工作区里,也有几条保护路径:.git、.agents、.codex 递归只读 —— 它能改你的源码,但改不了版本库元数据和它自己的配置。1注 1Note 1OpenAI 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-07-17。OpenAI Codex Docs · Agent approvals & security — security controls come from two layers: Sandbox mode sets what it can technically do (where it writes, whether it reaches the network), Approval policy sets when it must ask you first. By default the agent has no network; locally an OS sandbox confines it to the workspace. The Auto preset (--sandbox workspace-write --ask-for-approval on-request) lets it read, edit, and run commands in the working directory automatically, asking only at the boundary (writing outside the workspace, needing network). Use /permissions to switch to read-only. Under default workspace-write, network is off and needs an explicit [sandbox_workspace_write] network_access = true. Writable roots still contain protected paths: .git, .agents, .codex are recursively read-only. As of 2026-07-17.这两条是「放权但不失控」的地基:你放开的是工作区,不是整台机器。Auto carries two default hard boundaries worth remembering. First: under workspace-write, network is off by default — opening it needs an explicit network_access = true in config; no-network is the default, not an accident.1注 1Note 1OpenAI 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-07-17。OpenAI Codex Docs · Agent approvals & security — security controls come from two layers: Sandbox mode sets what it can technically do (where it writes, whether it reaches the network), Approval policy sets when it must ask you first. By default the agent has no network; locally an OS sandbox confines it to the workspace. The Auto preset (--sandbox workspace-write --ask-for-approval on-request) lets it read, edit, and run commands in the working directory automatically, asking only at the boundary (writing outside the workspace, needing network). Use /permissions to switch to read-only. Under default workspace-write, network is off and needs an explicit [sandbox_workspace_write] network_access = true. Writable roots still contain protected paths: .git, .agents, .codex are recursively read-only. As of 2026-07-17. Second: even inside the writable workspace there are protected paths: .git, .agents, and .codex are recursively read-only — it can edit your source but not the repo metadata or its own configuration.1注 1Note 1OpenAI 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-07-17。OpenAI Codex Docs · Agent approvals & security — security controls come from two layers: Sandbox mode sets what it can technically do (where it writes, whether it reaches the network), Approval policy sets when it must ask you first. By default the agent has no network; locally an OS sandbox confines it to the workspace. The Auto preset (--sandbox workspace-write --ask-for-approval on-request) lets it read, edit, and run commands in the working directory automatically, asking only at the boundary (writing outside the workspace, needing network). Use /permissions to switch to read-only. Under default workspace-write, network is off and needs an explicit [sandbox_workspace_write] network_access = true. Writable roots still contain protected paths: .git, .agents, .codex are recursively read-only. As of 2026-07-17. These two are the foundation of 'delegate without losing control': you loosen the workspace, not the whole machine.
— III
规则:给命令前缀定白灰黑名单Rules: Allow / Prompt / Forbid Lists for Command Prefixes.
旋钮是粗调,规则是细调。规则(实验特性)控制 Codex 能在沙箱外跑哪些命令:一个 .rules 文件里用 prefix_rule 给命令前缀定裁决 —— allow 直接放行、prompt 每次问、forbidden 直接拦;多条命中,最严的赢。3注 3Note 3OpenAI 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-07-17。OpenAI Codex Docs · Rules (experimental) — use rules to control which commands Codex can run outside the sandbox. A .rules file uses Starlark prefix_rule (pattern the command prefix, decision = allow / prompt / forbidden, justification, match / not_match inline tests); when several match, the most restrictive wins (forbidden > prompt > allow). Placed in ~/.codex/rules/ or project .codex/rules/ (trusted projects only). For compound commands chained with && inside bash -lc, if they contain only plain words + safe operators, Codex splits them with tree-sitter and judges each — so git add . && rm -rf / isn't waved through just because you allowed git add. codex execpolicy check tests rules. As of 2026-07-17.The dials are coarse; rules are fine. Rules (experimental) control which commands Codex may run outside the sandbox: a .rules file uses prefix_rule to give a command prefix a verdict — allow runs it, prompt asks each time, forbidden blocks it; when several match, the most restrictive wins.3注 3Note 3OpenAI 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-07-17。OpenAI Codex Docs · Rules (experimental) — use rules to control which commands Codex can run outside the sandbox. A .rules file uses Starlark prefix_rule (pattern the command prefix, decision = allow / prompt / forbidden, justification, match / not_match inline tests); when several match, the most restrictive wins (forbidden > prompt > allow). Placed in ~/.codex/rules/ or project .codex/rules/ (trusted projects only). For compound commands chained with && inside bash -lc, if they contain only plain words + safe operators, Codex splits them with tree-sitter and judges each — so git add . && rm -rf / isn't waved through just because you allowed git add. codex execpolicy check tests rules. As of 2026-07-17.
一条规则:gh pr view 允许但每次问,带内联测试One rule: gh pr view is allowed but prompts each time, with inline tests
规则最要紧的一条性质,是它拆得开复合命令。有人把危险动作藏在安全命令后面 —— git add . && rm -rf /。只要这串命令是普通词加安全操作符,Codex 就用 tree-sitter 把它拆成两条逐个判:就算你允许了 git add,后面那条 rm -rf / 会被单独评估,整条命令因此不会被自动放行。3注 3Note 3OpenAI 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-07-17。OpenAI Codex Docs · Rules (experimental) — use rules to control which commands Codex can run outside the sandbox. A .rules file uses Starlark prefix_rule (pattern the command prefix, decision = allow / prompt / forbidden, justification, match / not_match inline tests); when several match, the most restrictive wins (forbidden > prompt > allow). Placed in ~/.codex/rules/ or project .codex/rules/ (trusted projects only). For compound commands chained with && inside bash -lc, if they contain only plain words + safe operators, Codex splits them with tree-sitter and judges each — so git add . && rm -rf / isn't waved through just because you allowed git add. codex execpolicy check tests rules. As of 2026-07-17.写完规则用 codex execpolicy check 拿具体命令测一测,别等它到线上才发现规则写漏了。3注 3Note 3OpenAI 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-07-17。OpenAI Codex Docs · Rules (experimental) — use rules to control which commands Codex can run outside the sandbox. A .rules file uses Starlark prefix_rule (pattern the command prefix, decision = allow / prompt / forbidden, justification, match / not_match inline tests); when several match, the most restrictive wins (forbidden > prompt > allow). Placed in ~/.codex/rules/ or project .codex/rules/ (trusted projects only). For compound commands chained with && inside bash -lc, if they contain only plain words + safe operators, Codex splits them with tree-sitter and judges each — so git add . && rm -rf / isn't waved through just because you allowed git add. codex execpolicy check tests rules. As of 2026-07-17.Rules' most important property is that they split compound commands. People hide a dangerous action behind a safe one — git add . && rm -rf /. As long as the chain is plain words plus safe operators, Codex splits it with tree-sitter and judges each: even if you allowed git add, the trailing rm -rf / is evaluated on its own, so the whole command isn't auto-approved.3注 3Note 3OpenAI 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-07-17。OpenAI Codex Docs · Rules (experimental) — use rules to control which commands Codex can run outside the sandbox. A .rules file uses Starlark prefix_rule (pattern the command prefix, decision = allow / prompt / forbidden, justification, match / not_match inline tests); when several match, the most restrictive wins (forbidden > prompt > allow). Placed in ~/.codex/rules/ or project .codex/rules/ (trusted projects only). For compound commands chained with && inside bash -lc, if they contain only plain words + safe operators, Codex splits them with tree-sitter and judges each — so git add . && rm -rf / isn't waved through just because you allowed git add. codex execpolicy check tests rules. As of 2026-07-17. After writing rules, test a concrete command with codex execpolicy check — don't discover a gap in production.3注 3Note 3OpenAI 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-07-17。OpenAI Codex Docs · Rules (experimental) — use rules to control which commands Codex can run outside the sandbox. A .rules file uses Starlark prefix_rule (pattern the command prefix, decision = allow / prompt / forbidden, justification, match / not_match inline tests); when several match, the most restrictive wins (forbidden > prompt > allow). Placed in ~/.codex/rules/ or project .codex/rules/ (trusted projects only). For compound commands chained with && inside bash -lc, if they contain only plain words + safe operators, Codex splits them with tree-sitter and judges each — so git add . && rm -rf / isn't waved through just because you allowed git add. codex execpolicy check tests rules. As of 2026-07-17.
— IV
把审批本身交给一个 reviewerHand Approval Itself to a Reviewer.
最后一层最有意思:审批不一定要你亲自点。approvals_reviewer 默认是 user(问你),改成 auto_review,越界请求就先送给一个独立的 reviewer agent 判 —— 它只看那些本来就要停下问人的动作:沙箱升权、被拦的网络请求、可写根外的改动、有副作用的 MCP 调用。4注 4Note 4OpenAI Codex 文档 · Auto-review —— 把沙箱边界上的人工审批换成一个独立的 reviewer agent:approvals_reviewer = "user"(默认)或 "auto_review"。它只评估那些本来就要停下问人的越界请求(沙箱升权、被拦的网络请求、可写根外的文件改动、有副作用的 MCP / app 调用),是审查者的替换,不是权限的放开。策略默认拦:外传私有数据 / 凭据、探凭据、持续削弱安全、有重大不可逆风险的破坏性动作。带熔断:同一轮连续 3 次拒绝(或滚动窗口内 10 次)就中止本轮;出错 fail closed。/approve 可对某个被拒动作放行一次重试。截至 2026-07-17。OpenAI Codex Docs · Auto-review — replaces the human approval at the sandbox boundary with a separate reviewer agent: approvals_reviewer = "user" (default) or "auto_review". It evaluates only the boundary-crossing requests that would otherwise pause for a person (sandbox escalations, blocked network requests, edits outside writable roots, side-effecting MCP / app calls) — a reviewer swap, not a permission grant. Its policy blocks: sending private data / credentials out, probing for credentials, persistently weakening security, destructive actions with significant irreversible risk. It carries a circuit breaker: 3 consecutive denials in a turn (or 10 in a rolling window) aborts the turn; failures fail closed. /approve grants one retry for a denied action. As of 2026-07-17.说清楚:这是审查者的替换,不是权限的放开 —— 它不扩大可写范围、不开网络、不动保护路径,只改「谁来审这个越界」。4注 4Note 4OpenAI Codex 文档 · Auto-review —— 把沙箱边界上的人工审批换成一个独立的 reviewer agent:approvals_reviewer = "user"(默认)或 "auto_review"。它只评估那些本来就要停下问人的越界请求(沙箱升权、被拦的网络请求、可写根外的文件改动、有副作用的 MCP / app 调用),是审查者的替换,不是权限的放开。策略默认拦:外传私有数据 / 凭据、探凭据、持续削弱安全、有重大不可逆风险的破坏性动作。带熔断:同一轮连续 3 次拒绝(或滚动窗口内 10 次)就中止本轮;出错 fail closed。/approve 可对某个被拒动作放行一次重试。截至 2026-07-17。OpenAI Codex Docs · Auto-review — replaces the human approval at the sandbox boundary with a separate reviewer agent: approvals_reviewer = "user" (default) or "auto_review". It evaluates only the boundary-crossing requests that would otherwise pause for a person (sandbox escalations, blocked network requests, edits outside writable roots, side-effecting MCP / app calls) — a reviewer swap, not a permission grant. Its policy blocks: sending private data / credentials out, probing for credentials, persistently weakening security, destructive actions with significant irreversible risk. It carries a circuit breaker: 3 consecutive denials in a turn (or 10 in a rolling window) aborts the turn; failures fail closed. /approve grants one retry for a denied action. As of 2026-07-17.The last layer is the most interesting: approval need not be your own click. approvals_reviewer defaults to user (asks you); set it to auto_review and boundary-crossing requests go first to a separate reviewer agent — it sees only the actions that would otherwise pause for a person: sandbox escalations, blocked network requests, edits outside writable roots, side-effecting MCP calls.4注 4Note 4OpenAI Codex 文档 · Auto-review —— 把沙箱边界上的人工审批换成一个独立的 reviewer agent:approvals_reviewer = "user"(默认)或 "auto_review"。它只评估那些本来就要停下问人的越界请求(沙箱升权、被拦的网络请求、可写根外的文件改动、有副作用的 MCP / app 调用),是审查者的替换,不是权限的放开。策略默认拦:外传私有数据 / 凭据、探凭据、持续削弱安全、有重大不可逆风险的破坏性动作。带熔断:同一轮连续 3 次拒绝(或滚动窗口内 10 次)就中止本轮;出错 fail closed。/approve 可对某个被拒动作放行一次重试。截至 2026-07-17。OpenAI Codex Docs · Auto-review — replaces the human approval at the sandbox boundary with a separate reviewer agent: approvals_reviewer = "user" (default) or "auto_review". It evaluates only the boundary-crossing requests that would otherwise pause for a person (sandbox escalations, blocked network requests, edits outside writable roots, side-effecting MCP / app calls) — a reviewer swap, not a permission grant. Its policy blocks: sending private data / credentials out, probing for credentials, persistently weakening security, destructive actions with significant irreversible risk. It carries a circuit breaker: 3 consecutive denials in a turn (or 10 in a rolling window) aborts the turn; failures fail closed. /approve grants one retry for a denied action. As of 2026-07-17. To be clear: this is a reviewer swap, not a permission grant — it doesn't widen writable scope, open the network, or touch protected paths; it changes only who reviews the overstep.4注 4Note 4OpenAI Codex 文档 · Auto-review —— 把沙箱边界上的人工审批换成一个独立的 reviewer agent:approvals_reviewer = "user"(默认)或 "auto_review"。它只评估那些本来就要停下问人的越界请求(沙箱升权、被拦的网络请求、可写根外的文件改动、有副作用的 MCP / app 调用),是审查者的替换,不是权限的放开。策略默认拦:外传私有数据 / 凭据、探凭据、持续削弱安全、有重大不可逆风险的破坏性动作。带熔断:同一轮连续 3 次拒绝(或滚动窗口内 10 次)就中止本轮;出错 fail closed。/approve 可对某个被拒动作放行一次重试。截至 2026-07-17。OpenAI Codex Docs · Auto-review — replaces the human approval at the sandbox boundary with a separate reviewer agent: approvals_reviewer = "user" (default) or "auto_review". It evaluates only the boundary-crossing requests that would otherwise pause for a person (sandbox escalations, blocked network requests, edits outside writable roots, side-effecting MCP / app calls) — a reviewer swap, not a permission grant. Its policy blocks: sending private data / credentials out, probing for credentials, persistently weakening security, destructive actions with significant irreversible risk. It carries a circuit breaker: 3 consecutive denials in a turn (or 10 in a rolling window) aborts the turn; failures fail closed. /approve grants one retry for a denied action. As of 2026-07-17.reviewer 的策略默认拦几类真危险的动作:把私有数据或凭据外传、探凭据、持续削弱安全、有重大不可逆风险的破坏。4注 4Note 4OpenAI Codex 文档 · Auto-review —— 把沙箱边界上的人工审批换成一个独立的 reviewer agent:approvals_reviewer = "user"(默认)或 "auto_review"。它只评估那些本来就要停下问人的越界请求(沙箱升权、被拦的网络请求、可写根外的文件改动、有副作用的 MCP / app 调用),是审查者的替换,不是权限的放开。策略默认拦:外传私有数据 / 凭据、探凭据、持续削弱安全、有重大不可逆风险的破坏性动作。带熔断:同一轮连续 3 次拒绝(或滚动窗口内 10 次)就中止本轮;出错 fail closed。/approve 可对某个被拒动作放行一次重试。截至 2026-07-17。OpenAI Codex Docs · Auto-review — replaces the human approval at the sandbox boundary with a separate reviewer agent: approvals_reviewer = "user" (default) or "auto_review". It evaluates only the boundary-crossing requests that would otherwise pause for a person (sandbox escalations, blocked network requests, edits outside writable roots, side-effecting MCP / app calls) — a reviewer swap, not a permission grant. Its policy blocks: sending private data / credentials out, probing for credentials, persistently weakening security, destructive actions with significant irreversible risk. It carries a circuit breaker: 3 consecutive denials in a turn (or 10 in a rolling window) aborts the turn; failures fail closed. /approve grants one retry for a denied action. As of 2026-07-17.它还带熔断:同一轮里连续拒绝 3 次(或滚动窗口内 10 次),Codex 直接中止本轮 —— 免得 agent 在越权尝试上死循环;判断出错时 fail closed(宁可拦错,不放过)。4注 4Note 4OpenAI Codex 文档 · Auto-review —— 把沙箱边界上的人工审批换成一个独立的 reviewer agent:approvals_reviewer = "user"(默认)或 "auto_review"。它只评估那些本来就要停下问人的越界请求(沙箱升权、被拦的网络请求、可写根外的文件改动、有副作用的 MCP / app 调用),是审查者的替换,不是权限的放开。策略默认拦:外传私有数据 / 凭据、探凭据、持续削弱安全、有重大不可逆风险的破坏性动作。带熔断:同一轮连续 3 次拒绝(或滚动窗口内 10 次)就中止本轮;出错 fail closed。/approve 可对某个被拒动作放行一次重试。截至 2026-07-17。OpenAI Codex Docs · Auto-review — replaces the human approval at the sandbox boundary with a separate reviewer agent: approvals_reviewer = "user" (default) or "auto_review". It evaluates only the boundary-crossing requests that would otherwise pause for a person (sandbox escalations, blocked network requests, edits outside writable roots, side-effecting MCP / app calls) — a reviewer swap, not a permission grant. Its policy blocks: sending private data / credentials out, probing for credentials, persistently weakening security, destructive actions with significant irreversible risk. It carries a circuit breaker: 3 consecutive denials in a turn (or 10 in a rolling window) aborts the turn; failures fail closed. /approve grants one retry for a denied action. As of 2026-07-17.被误拦了也有退路:/approve 对某个被拒动作放行一次重试。这一层是无人值守(第 8 章)真正的价值 —— 没有人在场时,得有个东西替你说不。The reviewer's policy blocks a few genuinely dangerous classes by default: sending private data or credentials out, probing for credentials, persistently weakening security, destructive actions with significant irreversible risk.4注 4Note 4OpenAI Codex 文档 · Auto-review —— 把沙箱边界上的人工审批换成一个独立的 reviewer agent:approvals_reviewer = "user"(默认)或 "auto_review"。它只评估那些本来就要停下问人的越界请求(沙箱升权、被拦的网络请求、可写根外的文件改动、有副作用的 MCP / app 调用),是审查者的替换,不是权限的放开。策略默认拦:外传私有数据 / 凭据、探凭据、持续削弱安全、有重大不可逆风险的破坏性动作。带熔断:同一轮连续 3 次拒绝(或滚动窗口内 10 次)就中止本轮;出错 fail closed。/approve 可对某个被拒动作放行一次重试。截至 2026-07-17。OpenAI Codex Docs · Auto-review — replaces the human approval at the sandbox boundary with a separate reviewer agent: approvals_reviewer = "user" (default) or "auto_review". It evaluates only the boundary-crossing requests that would otherwise pause for a person (sandbox escalations, blocked network requests, edits outside writable roots, side-effecting MCP / app calls) — a reviewer swap, not a permission grant. Its policy blocks: sending private data / credentials out, probing for credentials, persistently weakening security, destructive actions with significant irreversible risk. It carries a circuit breaker: 3 consecutive denials in a turn (or 10 in a rolling window) aborts the turn; failures fail closed. /approve grants one retry for a denied action. As of 2026-07-17. It also carries a circuit breaker: 3 consecutive denials in a turn (or 10 in a rolling window) and Codex aborts the turn — so the agent can't loop on escalation attempts; on a judgment error it fails closed (rather block wrongly than let it through).4注 4Note 4OpenAI Codex 文档 · Auto-review —— 把沙箱边界上的人工审批换成一个独立的 reviewer agent:approvals_reviewer = "user"(默认)或 "auto_review"。它只评估那些本来就要停下问人的越界请求(沙箱升权、被拦的网络请求、可写根外的文件改动、有副作用的 MCP / app 调用),是审查者的替换,不是权限的放开。策略默认拦:外传私有数据 / 凭据、探凭据、持续削弱安全、有重大不可逆风险的破坏性动作。带熔断:同一轮连续 3 次拒绝(或滚动窗口内 10 次)就中止本轮;出错 fail closed。/approve 可对某个被拒动作放行一次重试。截至 2026-07-17。OpenAI Codex Docs · Auto-review — replaces the human approval at the sandbox boundary with a separate reviewer agent: approvals_reviewer = "user" (default) or "auto_review". It evaluates only the boundary-crossing requests that would otherwise pause for a person (sandbox escalations, blocked network requests, edits outside writable roots, side-effecting MCP / app calls) — a reviewer swap, not a permission grant. Its policy blocks: sending private data / credentials out, probing for credentials, persistently weakening security, destructive actions with significant irreversible risk. It carries a circuit breaker: 3 consecutive denials in a turn (or 10 in a rolling window) aborts the turn; failures fail closed. /approve grants one retry for a denied action. As of 2026-07-17. A wrong block has a way out too: /approve grants one retry for a denied action. This layer is the real value of unattended work (chapter 8) — when no one's present, something has to say no for you.动手 · 把放权从直觉调成配置:Hands-on · turn permissions from instinct into configuration:
在一个有 git 的项目里确认默认落在 Auto(workspace-write + on-request),用 /status 看当前档。In a git project, confirm the default lands on Auto (workspace-write + on-request) via /status.
给一个你不想让它随便跑的命令前缀写一条 prompt 规则,用 codex execpolicy check 验它真拦。Write a prompt rule for a command prefix you don't want run freely, and verify it blocks with codex execpolicy check.
在一个长任务上试一次 auto_review,读它拦下 / 放行的记录 —— 判断它的口味和你的是否一致。Try auto_review once on a long task and read its block / allow record — judge whether its taste matches yours.
信方向就松档,
信不过的点用规矩钉死.
Trust the direction, loosen the dial;
pin the points you don't with rules.
Aklman Library
— 讨论Discussion
讨论Discussion.
评论区初始化中…Initializing comments…
01 / 01
没有匹配结果No matches.
换个关键词，或按 Esc 回到页面Try another keyword, or press Esc to return