For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/zh/articles/openai-hardens-codex-against-destructive-actions.md.
OpenAI 在调查少数 Codex 执行超出用户意图的破坏性操作后，强化了目标路径校验、临时目录隔离、高风险命令审查和完全访问权限提示。对本地开发而言，最稳妥的做法仍是保持 workspace-write 沙箱，仅在确有需要时提升权限。
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 不再将清理视为例行的最后一步，而是被明确指示确认目标路径确实就是它打算修改的路径。
这一点很重要，因为破坏性 shell 命令通常只有在参数正确时才是安全的。
例如，删除专用临时目录和删除父级工作区之间的区别，可能只是一个错误的变量展开、引用错误、路径规范化问题或缺少参数。
新方法减少了对隐式假设的依赖。
在执行高风险文件系统操作之前，系统应更仔细地思考以下问题：
这是代理行为层面上的安全改进。
它不能替代沙箱，但可以首先降低危险命令到达沙箱边界的可能性。
OpenAI 还在改变 Codex 处理临时工作的方式。
更安全的模式是创建一个全新的、特定用途的临时目录，而不是复用已经具有重要含义的系统变量。
像 $HOME 这样的变量尤其敏感，因为它们通常指向包含项目文件、配置、凭据、应用程序状态和其他个人数据的真实用户目录。
使用专用临时路径有两个优势。
首先，目标具有更窄的语义含义：它仅用于一次性任务数据。
其次，清理变得更容易验证，因为系统可以将删除目标与任务早期创建的精确临时目录进行比较。
这是一个直接的工程原则，但当自主代理能够以机器速度执行 shell 命令时，它就变得更加重要。
更安全的模式实际上是：
创建一个全新的临时目录
↓
将任务特定的临时文件存储在那里
↓
跟踪确切的路径
↓
在清理前验证该相同路径
↓
仅删除已验证的临时目录
目标是避免将广泛的环境状态变成清理目标。
路径验证只是防御的一层。
OpenAI 还加强了识别风险命令并将其转交审查的机制。
Codex 变更日志已经记录了针对强制 rm 操作的更强检测，以及更一致的 Full Access 确认。当前的自动审查策略也明确将具有显著不可逆损害风险的破坏性操作列入其旨在阻止的类别中。
之所以重要，是因为一条命令即使语法上完全合法，也可能不安全。
一条删除命令可能完全符合 shell 语法规则，但仍然很危险，因为它可能：
因此，OpenAI 的更新版安全防护机制不仅会判断命令能否执行。
它还会判断在当前权限和用户授权下，这条命令是否应当执行。
原文还重点提到了 Codex 完全访问权限体验的变化。
完全访问权限是刻意设计为高度强大的。OpenAI 当前的权限文档指出，在该模式下，Codex 可以编辑计算机上的任意文件，并在无需征求批准的情况下运行具有网络访问权限的命令。
这在临时虚拟机、专用开发环境或其他严格控制、操作者有意希望实现无限制自动化的系统中非常有用。
然而，在普通工作站上，这种模式会显著增大失误带来的后果。
OpenAI 现在为开启该模式设置了更高的门槛。
当前的 Codex 文档规定，完全访问权限必须先在桌面应用的设置中显式启用，才会作为可选权限模式出现。界面还会显示更强烈的警告，提示可能发生的数据丢失、泄露和意外行为。
对于经批准的高风险安全模型，OpenAI 表示桌面应用在完全访问权限启用前会额外显示一条针对该模型的警告，并推荐使用更安全的“代我批准”模式。
| 模式 | 沙箱 | 批准行为 | 实际风险 |
|---|---|---|---|
| 请求批准 | workspace-write | 用户审查所有越界请求 | 大多数本地工作的推荐默认模式 |
| 代我批准 / 自动审查 | workspace-write | 审查代理评估符合条件的升级请求 | 在保持相同沙箱边界的同时降低操作摩擦 |
| 完全访问 | danger-full-access | 没有常规批准边界 | 风险最高；拥有广泛的文件系统和网络访问权限 |
| 只读 | read-only | 修改需要升级权限 | 适用于检查和规划 |
关键在于：自动审查和完全访问不是一回事。
自动审查保留了沙箱机制。它改变的是谁来评估跨越沙箱边界的请求。
完全访问则直接移除了沙箱边界本身。
OpenAI 还更新了自动审查规则，以更好地识别破坏性操作。
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
自动审查是一个独立的审查代理，当主 Codex 代理想要跨越沙箱边界时，它会评估符合条件的请求。
正常流程如下：
主 Codex 代理在沙箱内工作
↓
某个操作需要额外权限
↓
Codex 创建批准请求
↓
自动审查评估该请求
↓
批准 → 继续执行
拒绝 → Codex 必须寻找更安全的路径或询问用户
OpenAI的文档显示，自动审查可以评估涉及以下内容的请求：
其策略旨在拒绝或限制包括凭据探测、数据泄露、持续削弱安全控制以及具有重大不可逆损害风险的破坏性行为。
这使得自动审查成为用户的重要安全层，既减少了手动干预，又不会让主编码代理获得无限制访问权限。
然而，OpenAI明确表示，自动审查不能替代沙箱机制。
如果用户选择完全访问权限并移除沙箱，自动审查器无法重新创建一个已不存在的边界。
缓解工作也在反馈到模型测试中。
索蒂奥表示，OpenAI构建了有针对性的评估，回放在调查过程中发现的各类故障。公司还在增加针对这些风险的强化学习任务和评分器。
这一点很重要，因为如果罕见的破坏性错误仅作为孤立案例进行评估，就很难加以改进。
将真实故障转化为可重复的测试，让团队能够提出以下问题：
换句话说，该事件正在被转化为回归测试覆盖。
安全目标不仅是修补一个命令模式，而是让未来的Codex版本更不可能重现更广泛类别的故障。
调查还强化了关于编码代理安全的一个更广泛观点。
“小心处理文件”这样的自然语言指令并不是强大的安全边界。
执行沙箱才是。
OpenAI自身的部署指南将沙箱和审批描述为互补的控制措施：
对于大多数本地工作，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 永远不会犯破坏性错误。
OpenAI 自己的文档警告说，自动化审查可能会出错，任何代理级安全机制都不应被视为可恢复开发实践的替代品。
实际的变化是纵深防御。
高风险操作现在有更多机会被阻止：
这比依赖任何单一安全措施都更加稳健。
对于日常编码，最安全的默认设置仍然很简单：除非任务确实需要更广泛的访问权限，否则让代理留在工作区内。
OpenAI 的调查发现了一个与临时目录清理相关的失败模式。在某些情况下，$HOME 等宽泛的系统变量可能会在临时工作中被重复使用，而格式错误的清理路径可能会指向真实的用户数据，而不是一次性目录。
OpenAI 表示，Codex 现在会更明确地检查删除目标，使用更安全的临时目录模式，加强破坏性操作检测，改进自动审查，并让完全访问更难被意外启用。该公司还根据观察到的失败创建了有针对性的评估。
完全访问会移除常规沙箱限制，允许 Codex 广泛编辑文件并运行具有网络访问权限的命令，而没有通常的审批边界。OpenAI 警告说，这会显著增加数据丢失、泄露和意外行为的风险。
不一样。自动审查会保留现有沙箱，并将符合条件的升级请求发送给审查代理。完全访问则会移除沙箱边界，因此两种模式提供的保护级别非常不同。
OpenAI 当前的政策表示，自动审查旨在识别并阻止会造成重大不可逆损害风险的破坏性操作，以及凭证探测和数据窃取等风险。它只审查在当前沙箱和审批政策下已经需要审批的操作。
OpenAI 建议大多数本地工作从基于常规审批的模式开始。它允许在工作区内进行常规编辑，同时在 Codex 超出该边界或访问受限资源之前要求审查。
会。这些措施降低了风险，但不能保证零错误行为。版本控制、备份、狭窄的工作区
权限，以及对高风险操作的有意批准仍然非常重要。
在 ChatGPT 桌面应用或 IDE 扩展中，使用与任务关联的权限控制。在 Codex CLI 中，/permissions 显示可用模式，而官方配置文档描述了 sandbox_mode、approval_policy 和 approvals_reviewer。
read-only、workspace-write 和 danger-full-access 的官方参考。rm 检测、完全访问确认及相关安全改进的发布历史。在调查了少数破坏性清理操作影响到用户预期范围之外文件的罕见案例后，OpenAI 加强了 Codex。主要故障模式涉及临时目录处理、过宽的环境变量、目标验证不足，以及权限过宽导致错误命令可能造成重大损害的会话。
新的安全措施增加了目标路径检查、更安全的临时目录处理、更强的破坏性命令审查、更清晰的完全访问警告，以及改进的自动审查策略。OpenAI 还在将观察到的
将失败转化为可重复的评估和训练任务。
这些更改降低了编码代理将普通清理错误演变成大型文件系统事故的可能性，但并未使不受限制的执行毫无风险。
对于大多数本地开发，最安全的方法仍然是让 Codex 保持在工作区沙箱内，并且仅在任务确实需要时提升权限。
从一句话开始，几分钟内拿到完整网站。
