沙箱模式与审批策略对比

Codex 在执行模型生成的命令时，有两个彼此独立的控制层：

  • 沙箱决定命令“最多能做什么”，例如能否写文件、能否联网。
  • 审批决定命令“要不要先问人”，例如总是询问、由模型判断何时询问，或从不询问。

两层可以组合。把它们混为一谈，容易得到“看起来安全、实际仍有缺口”的配置。

命令从模型请求到执行或拒绝的流程：依次经过执行策略、沙箱和审批 模型发起命令 shell / 工具调用 执行策略 允许 / 询问 / 拒绝 沙箱 能做什么 审批 要不要问人 执行 / 拒绝 结果回到模型
执行策略先给出初步判定；沙箱限制实际能力；审批在需要时请求人工确认。

三种沙箱模式

模式能力边界适用场景
read-only可读文件；不允许写入，默认也不允许联网代码审查、只读分析、让模型先做调查
workspace-write可写当前工作区与临时目录；联网默认关闭，可显式开启日常开发，默认推荐
danger-full-access不启用文件系统沙箱，权限等同于当前用户仅限一次性容器、虚拟机等外部隔离环境

workspace-write 还有几个细节：

  • writable_roots 可以追加主工作区之外的可写目录。
  • network_access = true 才会放开沙箱内的联网；默认是 false。
  • exclude_tmpdir_env_var 与 exclude_slash_tmp 控制是否排除临时目录。
  • 命令行的 --add-dir 可以临时追加可写目录，适合一次性的多目录任务。

四种审批策略

策略行为备注
untrusted除非执行策略明确允许，否则命令都要审批主要用于被标记为不可信的项目
on-request由模型判断何时请求审批默认值；日常使用
granular用一张表分别控制沙箱升级、规则、技能、权限请求、MCP 等审批适合精细化管理
never从不询问；失败直接返回给模型只应在可丢弃环境中使用

注意：当前命令行 -a / --ask-for-approval 只接受 on-request 与 never 两个值；untrusted 与 granular 主要通过配置文件使用。不同版本可能调整这一限制，升级后请以 codex --help 为准。

推荐组合

目标沙箱审批说明
只读审查read-onlyon-request让模型调查、解释、找问题，不改文件
日常开发workspace-writeon-request平衡效率与可控性
无人值守的 CIworkspace-writenever只在一次性容器或可丢弃工作区中使用
外部已隔离danger-full-accessnever风险最高，必须有外层隔离与可恢复快照

两个常用快捷方式：

  • --approve-for-me：以 workspace-write 沙箱运行，审批走自动复核，适合希望减少打断但仍保留检查的场景。
  • --dangerously-bypass-approvals-and-sandbox：同时跳过审批与沙箱，风险极高，只用于外部已经隔离的环境。

配置示例

# ~/.codex/config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false
writable_roots = ["/Users/you/shared-libs"]

对应的命令行写法：

# 只读调查
codex -s read-only -a on-request "找出这个仓库里所有未处理的 TODO"

# 日常开发，额外允许写一个共享目录
codex -s workspace-write --add-dir ../shared "实现这个接口并跑测试"

常见误区

  • 把 never 当成“更少打扰”的默认选项。 它同时意味着出错时不会有人工兜底；在真实工作区里应谨慎。
  • 以为 workspace-write 就完全不能联网。 联网由 network_access 单独控制，默认关闭，但可以打开。
  • 以为审批能替代沙箱。 审批只决定是否询问；一旦批准，命令仍受沙箱能力边界约束。反过来，沙箱也不能替代审批。
  • 在宿主机上使用 danger-full-access。 这等于把当前用户的权限交给模型生成的命令；没有外层隔离时不要使用。

延伸阅读