⭐ 设为星标 · 第一时间收到推送
这次改的不是按钮，是权限模型
OpenAI 在 Codex 开发者文档里新增了 Permission profiles 页面，发布时间是 2026 年 6 月 29 日。官方把它标成 beta，也说得很直接：这个能力还在开发中，后续可能变化。
以前本地让 Codex 跑命令，大体是在几个大档位之间切：只读、workspace 可写，或者 danger full access。这个思路好理解，但不够细。真实开发任务里，常见需求不是“全开”或“全关”，而是：可以改这个项目，不能读 .env；可以访问 OpenAI API，不能碰 tracking 域名；可以读工具链需要的最小路径，但不要扫完整硬盘。
Permission profile 解决的正是这类问题。它是一个可命名、可复用、可继承的权限策略：里面同时写文件系统规则和网络规则，再由 default_permissions 指向要启用的 profile。
| 维度 | 这次变化 |
|---|---|
| 主角 | Codex Permission profiles |
| 状态 | beta，官方文档已上线 |
| 替代对象 | 粗粒度 `sandbox_mode` / `sandbox_workspace_write` |
| 核心能力 | 文件读写拒绝、网络域名规则、Unix socket allowlist |
| 最适合谁 | 经常让 Codex 跑本地命令的高级用户和团队管理员 |
它不是说旧 sandbox 立刻不能用了，而是给高级用户一个更接近真实工作流的选择：不用为了一个联网请求就放大整个任务权限，也不用为了编辑项目文件就顺手暴露所有敏感文件。
一个 profile 同时管文件和网络
新 profile 里最关键的文件权限只有三种：read、write、deny。真正有意思的是，deny 可以从更大的可读或可写范围里切出一块禁区。
比如一个项目编辑任务，可以允许 Codex 写 workspace 里的普通代码，但把 **/*.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 开始，再加自己的 .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 surface 的总保险。
最后说一句
这次更新对个人用户有用，对团队管理员可能更重要。因为它终于把“允许哪些 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 更自由，而是让它终于可以按任务变得更克制。