OpenAI加强Codex安全保护，通过更安全的清理和权限控制防止破坏性操作

OpenAI 强化 Codex 安全防护，新增清理与权限控制机制以防范破坏性操作

OpenAI 在调查了多起超出用户意图的破坏性操作报告后，已升级 Codex 的安全控制机制。

问题并不在于 AI 编程代理能够运行命令——这恰恰是 Codex 的核心价值所在。风险出现在当拥有广泛权限的代理执行清理或文件管理操作时，错误解析了目标路径。

据 OpenAI Codex 工程负责人 Thibault "Tibo" Sottiaux 介绍，公司调查了少数 GPT-5.6 在 Codex 中执行超出请求范围的破坏性操作的案例。其中一个反复出现的模式涉及临时目录清理，尤其是在以广泛访问权限和较少沙箱保护运行会话时。

OpenAI 最新的缓解措施同时从多个层面入手：

• 在破坏性操作之前验证删除目标；
• 使用专用临时目录，而非复用敏感的环境变量；
• 加强对高风险命令的检测与审查；
• 使"完全访问"模式更难以被意外启用；
• 改进自动审查功能，使其更可靠地识别破坏性操作；
• 基于团队观察到的失败案例，新增评估和训练任务。

关键变化并非单一的禁令列表。OpenAI 同时在收紧模型的指令和其周围的执行环境。

调查聚焦于临时目录清理

OpenAI 的调查发现，部分破坏性故障与临时工作目录的清理逻辑有关。

编程代理在工作过程中经常创建临时位置。任务可能涉及解压归档文件、生成中间文件、运行测试、暂存补丁或创建一次性构建产物。事后清理这些文件通常是安全的。

当标识临时目录的变量存在歧义、被复用、格式错误或意外指向重要位置时，危险便会出现。

Sottiaux 描述了一种失败模式：模型复用系统环境变量（如 $HOME）作为临时工作目录。如果后续的清理命令错误解析该变量，原本旨在删除临时目录的命令可能会指向用户的真实主目录。

这一故障链条可以从高层次理解为：

创建或识别临时工作区
↓
复用宽泛的系统变量
↓
构造清理命令
↓
解析出错误的目标路径
↓
以广泛权限执行破坏性操作
↓
删除超出预期范围的文件

在不受限制的会话中，这种风险尤为严重。

在严格限定的沙箱环境中，操作系统可以防止错误命令触及无关目录。而在完全访问模式下，这一边界被有意移除，因此路径解析错误可能造成更大的影响范围。

OpenAI 当前的 Codex 文档明确指出了这一区别：常规的 workspace-write 模式将日常编辑限制在当前工作区内，

而 danger-full-access 则会移除文件系统和网络沙箱边界。

Codex 现在更明确地检查破坏性目标

第一项主要缓解措施是在删除或类似破坏性操作之前进行更强的目标验证。

Codex 不再将清理视为例行的最后一步，而是被明确指示确认目标路径确实就是它打算修改的路径。

这一点很重要，因为破坏性 shell 命令通常只有在参数正确时才是安全的。

例如，删除专用临时目录和删除父级工作区之间的区别，可能只是一个错误的变量展开、引用错误、路径规范化问题或缺少参数。

新方法减少了对隐式假设的依赖。

在执行高风险文件系统操作之前，系统应更仔细地思考以下问题：

• 此命令究竟会影响哪个目录？
• 该目录是否为为此任务创建的临时位置？
• 路径是否解析在预期的工作区内？
• 目标是否意外地过于宽泛？
• 删除是否不可逆？
• 范围是否足够清晰，无需询问用户即可继续？

这是代理行为层面上的安全改进。

它不能替代沙箱，但可以首先降低危险命令到达沙箱边界的可能性。

专用临时目录取代有风险的变量复用

OpenAI 还在改变 Codex 处理临时工作的方式。

更安全的模式是创建一个全新的、特定用途的临时目录，而不是复用已经具有重要含义的系统变量。

像 $HOME 这样的变量尤其敏感，因为它们通常指向包含项目文件、配置、凭据、应用程序状态和其他个人数据的真实用户目录。

使用专用临时路径有两个优势。

首先，目标具有更窄的语义含义：它仅用于一次性任务数据。

其次，清理变得更容易验证，因为系统可以将删除目标与任务早期创建的精确临时目录进行比较。

这是一个直接的工程原则，但当自主代理能够以机器速度执行 shell 命令时，它就变得更加重要。

更安全的模式实际上是：

创建一个全新的临时目录
↓
将任务特定的临时文件存储在那里
↓
跟踪确切的路径
↓
在清理前验证该相同路径
↓
仅删除已验证的临时目录

目标是避免将广泛的环境状态变成清理目标。

危险命令检测和审查正在加强

路径验证只是防御的一层。

OpenAI 还加强了识别风险命令并将其转交审查的机制。

Codex 变更日志已经记录了针对强制 rm 操作的更强检测，以及更一致的 Full Access 确认。当前的自动审查策略也明确将具有显著不可逆损害风险的破坏性操作列入其旨在阻止的类别中。

之所以重要，是因为一条命令即使语法上完全合法，也可能不安全。

一条删除命令可能完全符合 shell 语法规则，但仍然很危险，因为它可能：

• 目标目录范围过广；
• 影响工作区之外的数据；
• 使用了未解析的变量；
• 递归删除大型目录树；
• 破坏未提交的工作成果；
• 削弱安全控制；
• 将多个危险操作合并到一次 shell 调用中。

因此，OpenAI 的更新版安全防护机制不仅会判断命令能否执行。

它还会判断在当前权限和用户授权下，这条命令是否应当执行。

完全访问权限更难以被意外开启

原文还重点提到了 Codex 完全访问权限体验的变化。

完全访问权限是刻意设计为高度强大的。OpenAI 当前的权限文档指出，在该模式下，Codex 可以编辑计算机上的任意文件，并在无需征求批准的情况下运行具有网络访问权限的命令。

这在临时虚拟机、专用开发环境或其他严格控制、操作者有意希望实现无限制自动化的系统中非常有用。

然而，在普通工作站上，这种模式会显著增大失误带来的后果。

OpenAI 现在为开启该模式设置了更高的门槛。

当前的 Codex 文档规定，完全访问权限必须先在桌面应用的设置中显式启用，才会作为可选权限模式出现。界面还会显示更强烈的警告，提示可能发生的数据丢失、泄露和意外行为。

对于经批准的高风险安全模型，OpenAI 表示桌面应用在完全访问权限启用前会额外显示一条针对该模型的警告，并推荐使用更安全的“代我批准”模式。

主要权限模式说明

关键在于：自动审查和完全访问不是一回事。

自动审查保留了沙箱机制。它改变的是谁来评估跨越沙箱边界的请求。

完全访问则直接移除了沙箱边界本身。

自动审查现在更严格地识别破坏性操作

OpenAI 还更新了自动审查规则，以更好地识别破坏性操作。

自动审查是一个独立的审查代理，当主 Codex 代理想要跨越沙箱边界时，它会评估符合条件的请求。

正常流程如下：

主 Codex 代理在沙箱内工作
↓
某个操作需要额外权限
↓
Codex 创建批准请求
↓
自动审查评估该请求
↓
批准 → 继续执行
拒绝 → Codex 必须寻找更安全的路径或询问用户

OpenAI的文档显示，自动审查可以评估涉及以下内容的请求：

• 提升的shell或执行权限；
• 被阻止的网络访问；
• 对可写根目录之外的修改；
• 产生副作用的外部MCP或应用工具调用；
• 对新网站或域名的计算机使用访问。

其策略旨在拒绝或限制包括凭据探测、数据泄露、持续削弱安全控制以及具有重大不可逆损害风险的破坏性行为。

这使得自动审查成为用户的重要安全层，既减少了手动干预，又不会让主编码代理获得无限制访问权限。

然而，OpenAI明确表示，自动审查不能替代沙箱机制。

如果用户选择完全访问权限并移除沙箱，自动审查器无法重新创建一个已不存在的边界。

OpenAI正在新评估中回放故障

缓解工作也在反馈到模型测试中。

索蒂奥表示，OpenAI构建了有针对性的评估，回放在调查过程中发现的各类故障。公司还在增加针对这些风险的强化学习任务和评分器。

这一点很重要，因为如果罕见的破坏性错误仅作为孤立案例进行评估，就很难加以改进。

将真实故障转化为可重复的测试，让团队能够提出以下问题：

• 模型是否能识别出意外过大的删除目标？
• 它是否会避免重用敏感的环境变量？
• 当范围不明确时，它是否会停止操作？
• 它是否在可能的情况下优先选择可恢复的操作？
• 自动审查是否正确升级或拒绝该操作？
• 未来的模型是否会重复同样的故障？

换句话说，该事件正在被转化为回归测试覆盖。

安全目标不仅是修补一个命令模式，而是让未来的Codex版本更不可能重现更广泛类别的故障。

沙箱和权限仍然比单纯的提示词更重要

调查还强化了关于编码代理安全的一个更广泛观点。

“小心处理文件”这样的自然语言指令并不是强大的安全边界。

执行沙箱才是。

OpenAI自身的部署指南将沙箱和审批描述为互补的控制措施：

• 沙箱决定Codex可以写入的位置以及可以访问的网络资源；
• 审批策略决定Codex在跨越该边界之前何时必须停止。

对于大多数本地工作，OpenAI目前建议使用工作区范围的配置，而非无限制执行。

一个具有代表性的更安全配置是：

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

希望使用自动升级审查的用户可以保持相同的沙箱，同时更改审查器：

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

这些配置在正常工作区周围保留了操作系统级别的边界。

相比之下，完全访问权限有意移除了该保护，只应在环境本身提供

你所需的隔离。

这次 Codex 安全升级对开发者意味着什么

对开发者而言，这次更新并不意味着 Codex 永远不会犯破坏性错误。

OpenAI 自己的文档警告说，自动化审查可能会出错，任何代理级安全机制都不应被视为可恢复开发实践的替代品。

实际的变化是纵深防御。

高风险操作现在有更多机会被阻止：

1. 模型被指示验证目标。
2. 临时工作预期使用更安全的专用路径。
3. 高风险命令模式可以被执行框架识别。
4. 沙箱边界可以阻止对工作区之外的访问。
5. 审批或自动审查可以评估跨越边界的请求。
6. 完全访问需要更清晰、更慎重的用户操作。
7. 失败案例被添加到评估和未来训练中。

这比依赖任何单一安全措施都更加稳健。

对于日常编码，最安全的默认设置仍然很简单：除非任务确实需要更广泛的访问权限，否则让代理留在工作区内。

常见问题

为什么 Codex 有时会删除目标目录之外的文件？

OpenAI 的调查发现了一个与临时目录清理相关的失败模式。在某些情况下，$HOME 等宽泛的系统变量可能会在临时工作中被重复使用，而格式错误的清理路径可能会指向真实的用户数据，而不是一次性目录。

调查之后 Codex 发生了什么变化？

OpenAI 表示，Codex 现在会更明确地检查删除目标，使用更安全的临时目录模式，加强破坏性操作检测，改进自动审查，并让完全访问更难被意外启用。该公司还根据观察到的失败创建了有针对性的评估。

什么是 Codex 完全访问？

完全访问会移除常规沙箱限制，允许 Codex 广泛编辑文件并运行具有网络访问权限的命令，而没有通常的审批边界。OpenAI 警告说，这会显著增加数据丢失、泄露和意外行为的风险。

自动审查和完全访问一样吗？

不一样。自动审查会保留现有沙箱，并将符合条件的升级请求发送给审查代理。完全访问则会移除沙箱边界，因此两种模式提供的保护级别非常不同。

自动审查会阻止破坏性命令吗？

OpenAI 当前的政策表示，自动审查旨在识别并阻止会造成重大不可逆损害风险的破坏性操作，以及凭证探测和数据窃取等风险。它只审查在当前沙箱和审批政策下已经需要审批的操作。

大多数 Codex 用户应该选择哪种权限模式？

OpenAI 建议大多数本地工作从基于常规审批的模式开始。它允许在工作区内进行常规编辑，同时在 Codex 超出该边界或访问受限资源之前要求审查。

在这些更改之后，Codex 仍然会犯错吗？

会。这些措施降低了风险，但不能保证零错误行为。版本控制、备份、狭窄的工作区

权限，以及对高风险操作的有意批准仍然非常重要。

我可以在哪里检查 Codex 的权限和沙箱设置？

在 ChatGPT 桌面应用或 IDE 扩展中，使用与任务关联的权限控制。在 Codex CLI 中，/permissions 显示可用模式，而官方配置文档描述了 sandbox_mode、approval_policy 和 approvals_reviewer。

相关工具

• OpenAI Codex：适用于本地、IDE、桌面和云端工作流的官方 Codex 文档。
• Codex CLI：OpenAI 的开源命令行编码代理及其发布历史。
• Codex 权限：关于“请求批准”、“自动审查”、“完全访问”及相关权限模式的官方说明。
• Codex 自动审查：关于沙箱边界批准请求自动审查的文档。
• Codex 沙箱化：关于 read-only、workspace-write 和 danger-full-access 的官方参考。
• Codex 规则：用于允许、提示或阻止选定命令模式的命令策略控制。

相关链接

• Thibault Sottiaux 的 Codex 安全更新：描述调查经过和新发布缓解措施的 OpenAI Codex 工程更新。
• 在 OpenAI 安全运行 Codex：OpenAI 关于沙箱化、批准、网络控制、托管配置和可审计性的概述。
• 代理批准与安全：关于沙箱边界、批准策略、受保护路径和自动批准审查的详细指南。
• Codex 自动审查：涵盖触发条件、审查流程、破坏性操作策略和失败行为的官方文档。
• Codex 权限：关于面向用户的权限模式和完全访问警告的官方描述。
• Codex 更新日志：记录更强的强制 rm 检测、完全访问确认及相关安全改进的发布历史。
• OpenAI Codex GitHub 仓库：源代码、问题、发布说明以及开源 Codex CLI 实现。

总结

在调查了少数破坏性清理操作影响到用户预期范围之外文件的罕见案例后，OpenAI 加强了 Codex。主要故障模式涉及临时目录处理、过宽的环境变量、目标验证不足，以及权限过宽导致错误命令可能造成重大损害的会话。

新的安全措施增加了目标路径检查、更安全的临时目录处理、更强的破坏性命令审查、更清晰的完全访问警告，以及改进的自动审查策略。OpenAI 还在将观察到的

将失败转化为可重复的评估和训练任务。

这些更改降低了编码代理将普通清理错误演变成大型文件系统事故的可能性，但并未使不受限制的执行毫无风险。

对于大多数本地开发，最安全的方法仍然是让 Codex 保持在工作区沙箱内，并且仅在任务确实需要时提升权限。