Codex 沙箱升级：可继承的权限配置与系统级文件保护

Codex 团队近期宣布沙箱模式迎来一次重大更新：用可复用、可继承的权限配置文件（Permission Profiles）替代原来粗糙的沙箱模式。新机制在操作系统层面强制执行文件读写与拒绝规则（甚至细化到 **/*.env 这类敏感文件），支持绑定到每个域名的网络访问控制和 Unix 套接字限制，并配合 fail-closed 的管理员白名单，让每个任务都遵循最小权限原则运行。

一、从全开全关，到精细权限

之前：粗糙的沙箱模式

Codex 之前的沙箱接近两种极端：要么让 Agent 完全受限，几乎什么都做不了；要么完全放开，什么都能碰。中间没有精细控制。对日常开发来说，这两种模式都不理想：受限模式拖慢迭代节奏，放开模式又让人提心吊胆，尤其是当项目里放着 .env、密钥这类敏感文件时。

现在：权限配置文件（Permission Profiles）

新的权限系统引入了可复用、可继承的权限配置文件，每个配置文件定义五类规则：

关键在于，这些规则由操作系统级强制执行，而不是 Codex 软件层的软限制。Agent 在运行中即使被诱导，试图读写越权文件或连接未授权域名，操作系统也会直接拒绝，绕不过去。

二、三个核心设计

1. 可继承（Inheritable）

权限配置文件支持继承：用一个基础配置定义通用规则，子配置继承它，再叠加特定任务的限制。

base-profile（基础配置）
  ├── 拒绝 **/*.env
  ├── 拒绝 **/secrets/**
  └── 允许 src/**
      │
      ├── frontend-task（继承 base）
      │   └── 只允许 src/frontend/**
      │
      └── backend-task（继承 base）
          └── 允许 src/api/**，并绑定 db.local:5432

不需要为每个任务从头配置权限：继承基础配置，再补上特定规则即可。安全策略调整一处就能全量生效，这对多任务并行的大项目尤其省心。

2. Fail-closed 管理员白名单

默认拒绝，只放行白名单内的操作。一个操作不在白名单里，就被拒绝。这是安全设计的经典原则：不是罗列要拒绝什么，而是默认全部拒绝，只放行明确允许的。相比之下，fail-open 的默认放行策略一旦有疏漏，攻击面就直接暴露在外面。

3. 每任务最小权限（Least Privilege）

每个任务只拿到完成所需的最小权限：不需要写文件就不给写权限，不需要网络就不给网络。这也印证了 Agent 安全领域的一个共识：循环越自主，权限越要收紧。自主循环跑得越久、动作越多，一次越权造成的破坏就越大，把权限收紧在源头，比事后审查更可靠。

三、新旧沙箱对比

最大的提升是从软件层限制走向操作系统级强制。过去把权限做在应用层，约束与被约束的代码跑在同一个可变环境里：靠系统提示词约束模型行为，或者靠软件检查点拦截，一旦模型被提示注入（prompt injection）诱导、或软件层出现漏洞，约束就可能被绕过。OS 级强制把防线下沉到内核，文件、网络、套接字的访问都由操作系统裁决，Agent 进程本身没有能力越过。这与 Docker 沙箱中 CapDrop、ReadonlyRootfs 这类纵深防御思路一脉相承，也是企业级 Agent 平台在安全合规上普遍认可的方向：权限可声明、可审计、可继承，且默认拒绝。

四、谁该关注

以下读者值得留意这次更新：

• 用 Codex 跑自主任务或长时间循环的个人与团队；
• 让 Agent 访问含敏感文件（.env、secrets、密钥）的项目；
• 企业环境需要最小权限控制与合规审计；
• 关心 Agent 安全、想防 prompt injection 越权的安全工程师；
• 在内网或受限网络中运行 Agent、需要按域名放行的运维同学。

五、小结

一句话总结：Codex 沙箱升级为可继承的权限配置文件，在操作系统层强制文件读写规则（含 .env 保护），加上每域名网络绑定、fail-closed 白名单与每任务最小权限。

从全开全关的粗糙沙箱，到文件级、域名级、操作系统强制执行的精细权限，这是 Agent 安全从凑合走向认真的转折点。对把真实代码和真实凭据交给 Agent 的团队来说，这类机制正在从可选变成标配。

本文基于 Codex 团队在 X 平台发布的沙箱更新说明整理。