OpenAI Codex 源码研究(三):从策略到系统后端——编码代理如何建立执行边界

编码代理与普通聊天产品的关键差异，是它会执行命令并修改真实环境。因此，“能做什么”和“何时需要批准”必须成为运行时约束，而不能只依赖提示词。

Codex 的执行边界由四部分协同形成：策略类型、审批配置、操作系统后端，以及对沙箱状态的显式暴露。

策略是受约束的数据结构

SandboxPolicy 定义四种策略形态：

• danger-full-access
  不施加文件系统限制，应谨慎使用；
• read-only
  只读访问，网络字段默认关闭；
• external-sandbox
  声明进程已处于外部沙箱，Codex 自身允许完整磁盘访问，同时遵守配置的网络状态；
• workspace-write
  允许写入工作区和额外声明的 writable_roots，网络字段默认关闭。

把策略定义为枚举的价值，是限制合法配置形态并让协议层可生成结构化类型。它不能消除所有危险配置，但比自由字符串更容易校验和审计。

审批是独立维度

AskForApproval 不是简单的开关：

• untrusted
  除非 execpolicy 明确放行，否则命令需要审批；
• on-request
  模型决定何时请求审批，也是该枚举的默认值；
• granular
  分别控制沙箱审批、规则审批、技能脚本、权限请求和 MCP elicitation；
• never
  不向用户请求审批，失败直接返回模型。

沙箱决定命令被允许触达的边界，审批决定是否需要人为或自动评审。两者应分别配置，不能互相替代。

不同操作系统使用不同后端

Linux 还提供独立的 codex-linux-sandbox 执行入口。相关二进制可以根据进程名分发到沙箱执行逻辑，以减少额外分发组件。

沙箱状态对进程可见

仓库 AGENTS.md 规定了 CODEX_SANDBOX 环境变量约定。沙箱中的子进程和测试因此能够识别当前执行环境，并跳过不适用的操作。

这一事实说明沙箱不是完全透明的外壳；它也是运行时上下文的一部分。但仅凭该约定，不能推断所有 Codex 开发流程都始终运行在同一套沙箱中。

对自建团队的三点启示

1. 把策略形态结构化
   明确允许哪些组合，并对危险模式使用直观命名；
2. 默认限制网络
   需要联网时显式开启，并叠加目的地和凭据控制；
3. 支持外部沙箱
   企业已有容器、虚拟机或终端管控时，代理应能与现有边界组合，而不是假设自己是唯一防线。

本文基于 OpenAI Codex commit 343074d 的静态源码分析。文中的架构判断不等同于对安全性、性能或生产成熟度的背书。