框架内部：按轮次划定权限，正在成为智能体运行时的基础原语

OpenAI Codex 仓库里有一个 7 月中旬提交的 issue，它比大多数发布公告都更能说明智能体运行时正在往哪里走。报告者发现，如果一个轮次还在运行时修改 Codex 的权限模式，当前轮次根本不会理你。它会继续使用启动时的权限，新设置只会应用到下一轮。中途提高权限，智能体仍然被挡住；中途降低权限，则更麻烦，界面已经显示“受限”，但智能体可能还会继续拥有原来的能力几分钟。

这种行为从最直观的角度看并不算缺陷。它其实暴露了一个正在各类智能体运行时里悄悄成为标准的设计决定：权限以轮次为作用域，在轮次开始时生成快照，并被视为这一个工作单元的属性，而不是用户、机器或整个会话的属性。这篇文章想讲清楚这个原语到底是什么，它解决了什么威胁模型，以及目前最清晰的参考实现 Codex 究竟怎么把它接起来。

关键要点 - 按轮次权限意味着，运行时在一个轮次开始时对审批策略、沙箱策略和权限配置生成快照，该轮次里的每一次工具调用都依据这份快照执行。 - 威胁模型并不是恶意用户，而是一个能力很强、正在遵循恶意指令，也就是提示注入，或者逐渐偏离任务的智能体，而且它恰好还拿着你的凭据，在你的机器上工作。 - Codex 把边界拆成三个互相独立的旋钮：审批策略，也就是要不要问；沙箱模式，也就是命令能碰什么；权限配置，也就是细粒度文件系统和网络规则。这些由操作系统执行，而不是靠模型自觉。 - 强制执行位于模型以下：macOS 使用 Seatbelt，Linux 使用 bubblewrap 加 seccomp，Windows 使用专用沙箱。遇到无法强制执行的策略时，Codex 会拒绝运行命令。 - 尚未解决的前沿问题是轮次中途修改权限。今天这份快照在整个轮次生命周期内不可变，这很安全，有时也非常让人抓狂。

发生了什么

从 7 月下旬到 8 月初，Codex 的权限界面从两项粗粒度设置逐渐长成更接近策略引擎的东西，文档也跟了上来。旧模型只有 config.toml 里的两个旋钮：sandbox_mode（read-only、workspace-write、danger-full-access）和 approval_policy（untrusted、on-request、never）。新模型增加了目前仍处于测试阶段的权限配置：命名、可组合的策略，把文件系统规则，也就是每个路径的 read、write、deny，其中 deny 优先，与网络规则，也就是通过本地代理执行的域名允许清单组合在一起。运行时内置三套：:read-only、:workspace 和 :danger-full-access，你通常是在它们基础上扩展，而不是从零开始。

配置界面变化的同时，交互模型也越来越围绕“轮次”来设计。/permissions 可以在同一个运行会话里切换模式。更细的审批策略允许某些提示类别继续交互，例如沙箱提权、MCP 信息请求，同时自动拒绝其他类别，其中甚至有一个单独的 request_permissions 类别，代表智能体自己在任务中途请求更多权限。根据 OpenAI 的审批与安全文档，审批请求还可以先交给自动审查智能体，筛查数据外传、凭据探测和破坏性操作，再决定是否需要人类看到。

这些并不是来自某一场单独发布。更像是一个运行时像操作系统当年长出用户账户一样，在一次次撞上现实之后，不情不愿地长出了权限层。

根据官方权限文档和审批文档，OpenAI Codex 已从两项粗粒度设置，也就是沙箱模式和审批策略，发展到命名权限配置，可组合按路径文件规则和通过代理执行的网络域名规则，同时支持会话中途切换、细分审批类别，以及可选的自动审查智能体。

“按轮次”到底是什么意思

我能给出的最干净定义是：智能体允许做什么，被绑定到一个单独轮次的生命周期，在轮次开始时捕获，并且原则上在轮次结束时释放。它不绑定到用户，因为用户可能离开一个小时，而智能体继续工作；不绑定到机器，因为一台机器会承载风险完全不同的很多轮任务；甚至不绑定整个会话，因为同一个会话上午可能只是审查代码，下午却要安装依赖。

文章开头提到的 Codex issue，就是快照真实存在的证据。按报告者的说法，运行中的轮次会“保留轮次开始时创建的权限或沙箱快照”。他们提出的修复，是建立一套机制，把新的审批策略、沙箱策略和权限配置传播到活动轮次；如果无法做到，就在内部暂停并恢复任务，让轮次在新权限下重新启动，而无需用户再次输入提示。再看验收标准，几乎就是把按轮次权限写成一等运行时概念的规范：中途降低权限必须阻止新的违规操作，提高权限必须解除对应阻塞，而恢复、委派和压缩过的轮次都必须保留更新后的上下文。

为什么一开始要做快照？因为另一种方案更糟。如果权限是可变的全局状态，那么任何能影响那份状态的东西，包括智能体读取的内容，都有机会撬动它下一步允许做什么。每轮不可变的快照意味着，权限决定只做一次，由人类或策略在意图清楚的时刻确定，而且智能体不能在执行途中通过对话把自己绕过去。轮次于是成为最小信任单元，这也符合智能体工作真正的拆分方式：“审查这份差异”和“推送到 main”就不该共享同一套权限上下文，即使它们发生在同一个会话里。

Codex 把权限绑定到轮次开始时的快照。2026 年 7 月的一个 issue记录了这样一种行为：轮次中途修改访问模式不会影响正在运行的轮次，并提出把新的审批策略、沙箱策略和权限配置传播到活动轮次，同时让恢复和委派的轮次保留新上下文。

它回应的威胁模型

这里最好说得精确一点，因为“智能体安全”很容易变成一大团模糊焦虑。按轮次权限背后的威胁模型，主要有三类明确行为者，而且没有一个是穿连帽衫的黑客。

提示注入是最显眼的威胁。 智能体整天都在读取不可信内容：代码仓库、网页、issue 工单、工具输出。其中任何东西都可能夹带针对智能体的指令。OpenAI 自己的文档对后果写得很直接：默认网页搜索使用缓存模式而不是实时模式，目的就是降低注入暴露；指南也明确警告，开启网络访问后，被注入的智能体可以抓取并继续遵循不可信指令。按轮次、默认关闭网络的沙箱，会限制一次成功注入在当前轮次里究竟能触达什么。

任务漂移和越界更安静。 一个能力很强、正在做正当工作的智能体仍然会自己走远：安装点东西、抓一个依赖、顺手“帮你”清理某个目录。沙箱解决这件事时，不需要先假设智能体是恶意的。也正因为如此，边界由操作系统执行，macOS 上是 Seatbelt，Linux 上是 bubblewrap 加 seccomp，Windows 上是原生沙箱，而不是依靠模型自己的良好判断。如果平台无法执行请求的策略，Codex 会直接拒绝命令，而不是无沙箱执行。失败时关闭，不要失败时祈祷。

凭据暴露会把前两类风险放大。 文档里的 devcontainer 指南说得很直接：如果让 Codex 在容器里拥有完全访问权限，那么恶意项目就可能外传容器里的任何东西，包括 Codex 凭据。这也是为什么新原语对秘密的处理如此具体：用 "**/*.env" = "deny" 这样的 glob，把凭据文件从可写工作区里剔出去；在可写根目录内把 .git、.codex 和 .agents 保护为只读；网络代理则默认阻止本地和私有目标，以抵御 DNS 重绑定。这和我在更广泛的智能体 AI 架构里讨论的是同一种形态：模型提出动作，智能体框架决定能不能执行，而秘密应该留在智能体框架手里。

根据 OpenAI 的安全文档，Codex 明确防范的威胁集中在三类：提示注入，也就是默认关闭网络、使用缓存网页搜索来降低恶意实时内容暴露；智能体漂移，也就是用操作系统强制沙箱，遇到无法执行的策略直接拒绝命令；以及凭据暴露，也就是对 .env 文件使用 deny glob，把 .git 和 .codex 路径设为只读，并阻断本地网络。

实现细节是怎样接起来的

有三个实现细节很值得拿去影响你自己对运行时的设计。

同等具体程度下，deny 优先于 write，write 优先于 read。 权限配置允许先给宽权限，再挖出例外：工作区可写，**/*.env 禁止，.devcontainer 只读。更具体的路径会覆盖更宽泛的路径，而且可写父目录里的被禁子路径仍然保持禁止。你甚至可以在一个宽泛 deny 里重新开放一个很窄的子树，例如禁止整个 ~/Documents，但允许写 ~/Documents/codex。这种优先级模型是对的，因为它让最小权限可以在宽泛写权限上逐层增加，而不是要求人类从记忆中一点点减权限。

“能联网”和“网络过滤”是两个独立开关。 network.enabled = true 让命令可以访问网络；真正通过本地代理执行域名规则的是 features.network_proxy = true。只开前者不开后者，就等于提供无限制出站访问，同时制造一种“好像有治理”的错觉。域名规则以允许清单为先，deny 优先，而且 localhost 等本地目标默认被阻止，除非你明确允许。一个能访问本地守护进程的沙箱智能体，本质上并没有真正被沙箱隔离。

新旧两套系统不会组合。 权限配置与旧的 sandbox_mode 设置互斥。只要任何已加载配置设置了 sandbox_mode，权限配置就会被忽略。企业管理员可以通过托管的 allowed_permission_profiles 允许清单强制使用新模型，未列出的内置配置也会被拒绝。如果整个设计只留下一条运营经验，就是这句：两套都“同时生效”的权限系统，最容易让人以为自己已经禁掉某件事，实际却没有。选一套，用 /permissions 和 /status 验证，再逐步扩大。

对运行 CLI 以外智能体的团队，这个模式同样适用。每个任务都生成独立权限上下文快照；凭据放在工具执行层，不放进模型上下文；强制执行位于模型以下；任务结束就让权限过期。你是从厂商运行时获得这套能力，还是自己搭智能体框架，就是自建还是采购的问题。如果自己运行，那么自托管智能体的取舍也会原样存在，只是旋钮更多。

根据权限文档，Codex 权限配置采用 deny 优先于 write、write 优先于 read 的规则，并支持更具体路径覆盖；网络连通与通过代理执行域名规则被拆成两个开关；权限配置还拒绝与旧沙箱设置组合，以避免歧义。管理员可以通过托管允许清单强制限定可用配置。

现在可以做什么

1. 今天： 下一次 Codex 会话里运行 /permissions 和 /status，看看真正生效的是什么，而不是你以为生效的是什么。如果任意配置层仍设置 sandbox_mode，你其实已经悄悄退出权限配置模式。先决定到底用哪一套。

2. 本周： 写一个自定义配置，继承 :workspace，禁止 **/*.env，只允许真正需要访问的 API 域名，并打开 network_proxy。信任它之前，用 codex debug，也就是沙箱命令，实际测试。如果你会审查第三方代码，可以在项目配置里把这些项目固定到从 :read-only 派生的配置。

3. 本月： 如果你在构建或封装智能体运行时，把轮次作为权限单元：轮次开始生成快照，轮次结束让权限过期，秘密放在模型上下文之外，并让强制执行采取失败即拒绝。然后把 Codex 自己还没完全解决的开放问题写清楚：轮次中途权限变化时应该发生什么？“下一轮之前什么都不变”很安全，但用户会自然期待界面显示的状态是真的。

常见问题

什么是按轮次权限？

一种权限模型。运行时在智能体轮次开始时捕获审批策略、沙箱边界和文件系统、网络规则，并把这份快照应用到该轮次里的每一次工具调用。权限属于工作单元，而不是用户、机器或整个会话。原则上轮次结束后就会释放，因此临时提升的访问不会默认持续存在。

这和直接让智能体以受限操作系统用户运行有什么区别？

操作系统用户是机器级、静态的，同一个智能体运行的所有任务都会继承同一张权限毯子。按轮次划分后，同一会话里，“审查这个仓库”可以只读运行，而“安装依赖并测试”可以在工作区写入并附加域名允许清单，无需更换账户。它还天然提供一个权限过期点，而操作系统用户本身没有。

提示注入能改变 Codex 的权限吗？

按照设计，在同一个轮次里不能。当前轮次依据启动时生成的快照执行，设置在轮次中途发生变化也不会传播进来，这正是 issue #32612 记录的行为。剩余风险主要在下一轮，以及权限配置本来就允许访问的范围，所以网络默认关闭，敏感路径也会被禁止或设为只读。

权限配置已经稳定到可以依赖了吗？

它们仍明确处于测试阶段，而且无法与旧的 sandbox_mode 设置组合，因此更适合把它们看成未来方向，而不是已经完成的 API。今天更稳定的基线仍是旧模式。团队铺开时，每个客户端版本先选定一种权限模型，用 /status 验证行为，并预期配置字段还会继续变化一段时间。

最后的判断

智能体权限正在像 Unix 权限当年一样成熟：从“root 或什么都没有”走向细粒度、最小权限、可审计的边界，只不过这里的基本单位不是进程或用户，而是一个轮次。Codex 是现在最值得研究的清晰实现，而它最粗糙的边角，也就是轮次中途不可变的权限快照，反而最有启发性：即使参考运行时自己，也仍在摸索一项权限究竟能动态到什么程度，才不会失去“权限”这个词本身的意义。如果你在构建或运营智能体，现在就该学会这个原语的形状。一年内所有严肃运行时都会有类似东西，而那些把快照语义做错的团队，大概率会公开学到这一课。

如果你正在设计自己智能体的权限层，希望有人从第二视角审一遍，这也是我会和客户团队一起做的工作。欢迎联系我。

来源

• OpenAI Developers，《Codex permissions》：https://developers.openai.com/codex/permissions （检索于 2026 年 8 月 29 日）

• OpenAI Developers，《智能体审批与安全》：https://developers.openai.com/codex/agent-approvals-security （检索于 2026 年 8 月 29 日）

• GitHub，openai/codex issue #32612，《将访问控制变更应用到当前运行轮次》：https://github.com/openai/codex/issues/32612 （提交于 2026 年 7 月 12 日，检索于 2026 年 8 月 29 日）

• GitHub，openai/codex issue #23626，《Codex CLI 的 /permissions 在 WSL2 中未显示只读模式，但在 Windows PowerShell 中会显示》：https://github.com/openai/codex/issues/23626 （提交于 2026 年 5 月 20 日，检索于 2026 年 8 月 29 日）

• OpenAI Codex 项目仓库：https://github.com/openai/codex （检索于 2026 年 8 月 29 日）