Codex权限Sandbox配置不再一刀切

Codex 的权限管理机制，终于从“一刀切”的粗放模式进化到了“精细化”控制阶段。

简单回顾一下，过去 Codex 在本地执行命令时，权限设计就像一个大沙盒：要么只读模式，要么允许整个工作区写入，要么索性完全放开。这种方式虽然操作简单，但显然不够智能。真实开发场景中，我们需要的往往不是“全有”或“全无”，而是更细粒度的控制：例如可以修改项目代码，但不能触碰 .env 文件；可以访问 API 接口，但不能连接追踪域名；可以读取工具链所需的路径，但不能扫描整个硬盘。

Permission profiles 正是为了解决这类痛点而诞生的。它是一个可命名、可复用、可继承的权限策略，将文件系统规则和网络规则统一放在同一个模型下进行管理。之后通过 default_permissions 指向要启用的 profile，即可实现灵活分配。

本次更新的主角是 Codex Permission profiles，目前仍处于 beta 阶段，官方文档已经正式上线。它替代了旧有 sandbox_mode / sandbox_workspace_write 等粗粒度的设置，核心能力涵盖文件读写拒绝、网络域名规则、Unix socket allowlist。最适合的受众，是那些经常需要让 Codex 在本地执行命令的高级用户和团队管理员。

当然，旧版 sandbox 短期内并不会立刻被弃用。但这一更新为高级用户提供了一个更贴近真实工作流的选择：不需要为了一个联网请求就放大整个任务的权限，也不需要为了编辑项目文件就顺手暴露所有敏感信息。

一个 profile 同时管控文件和网络

在新的 permission profile 中，文件权限其实只有三种：read、write、deny。但真正值得关注的是，deny 可以从更大的可读或可写范围里，精准切出一块禁止区域。

举个例子：一个项目编辑任务，可以允许 Codex 写入工作区中的普通代码，但将 **/*.env 设为拒绝。这样它仍然能够修改业务文件、运行测试、读取必要依赖路径，却不会顺手将环境变量文件读走。

官方文档给出的思路，可以这样理解：

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"
"*.github.com" = "allow"

这个配置中有三个细节值得特别留意。

第一，继承机制是被鼓励使用的。 例如从 :workspace 内置 profile 开始，再自行添加 .env 的 deny 规则和网络 allowlist，这种方式比完全手写一个 profile 更加稳妥。官方也明确了边界：不能继承 :danger-full-access，未知的父 profile 和循环继承会被拒绝。

第二，规则具有优先级。 更具体的路径会覆盖更宽泛的路径，同一路径上 deny 的权重高于 write，而 write 又高于 read。简单来说，你可以先给 Codex 划定一个工作范围，再逐个扣掉敏感点。

第三，这正是新权限模型与旧 sandbox 的根本差别。 旧模式像总闸，新 profile 更像一张任务权限表，能够精确控制每个任务的权限边界。

网络白名单比“能不能联网”更重要

很多人关心 Codex 能否联网，但这个问题其实问得过于宽泛。真正重要的是：它能连接哪些域名，不能连接哪些域名，本地服务是否被视为网络目标，Unix socket 会不会成为旁路攻击入口。

Permission profile 的网络规则是按域名来配置的。你可以允许 api.openai.com、github.com 这类任务必需的目的地，同时拒绝 tracking 域名。当没有 allow 条目时，域名请求会被直接阻断；写 "*" 等于放开一切公共网络，适合少数明确需要的任务，但不应该随意设为默认值。

本地和私有网络也默认不被放行。文档中提到，Codex 会默认阻断本地和私有网络目标，以防止 DNS rebinding 或误操作本机服务。要访问 localhost、127.0.0.1 这类地址，需要明确加入 allowlist；要让 allowlist 中的域名解析到本地或私有 IP，还必须开启 allow_local_binding。

Unix socket 同样被纳入这个模型。像 Docker 这类本地集成可以通过 socket allowlist 来授权，但这类能力本质上是一个本地逃逸口，应该尽可能少开、明开，且每次开启都要能解释清楚用途。

有一个边界需要说清楚：permission profiles 管理的只是本地沙箱化命令执行（sandboxed command execution）。它不会替代你管理 App connectors、MCP servers、browser/computer-use、Codex cloud 环境设置，也不会替代已批准的升级执行。换句话说，它很有用，但并非覆盖所有 Codex 功能面的总保险。

最后说一句

这次更新对个人用户很有帮助，但对团队管理员可能更为关键。因为它终于把“允许哪些 profile”也纳入了可管理的范围。

官方文档中有一个容易踩坑的点：permission profiles 不能与旧 sandbox_mode / sandbox_workspace_write 混用。配置中只要还存在旧 sandbox 设置、命令行传了 --sandbox 参数，或者选中的 config profile 仍然设置了 sandbox_mode，Codex 就会继续走旧 sandbox 模式。

企业侧的例外是 managed allowed_permission_profiles。一旦管理员配置了这个 allowlist，Codex 会按照 permission profiles 来工作，并且采用fail-closed机制：未列出的 profile 会被拒绝，包括未列出的内置 profile，以及未来 Codex 新增的 profile。

这一点非常关键。AI coding agent 的权限管理，最怕的不是“默认太严格”，而是“以后突然多了一个新能力，默认就被自动放进来”。fail-closed 的好处在于，新增能力不会自动进门，必须等管理员审核通过后才能使用。

如果现在想尝试，更建议从两类 profile 开始：

• 只读 + 必要联网：适用于代码审查、项目调研、读取项目结构等场景，只允许 api.openai.com 或 GitHub 等必要域名。
• workspace 可写 + 敏感文件 deny：适用于日常修改代码，先把 .env、secrets、凭据目录等敏感位置拒绝掉，再根据任务补充网络权限。

等到团队真的要全面放开，再着手处理版本兼容问题。官方提到，混合版本的企业 rollout 可以暂时保留旧的 allowed_sandbox_modes 约束，直到所有客户端都升级到 Codex 0.138.0 或更高版本。

一句话总结： Codex permission profiles 不是为了让 Agent 更自由，而是让它终于可以按任务变得更加克制、更加安全可控。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Codex权限Sandbox配置不再一刀切要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题