摘要：OpenAI披露，少量Codex任务中出现了超出用户要求的破坏性操作，最严重的模式涉及临时目录清理命令误指向用户文件。事件把一个具体问题摆到开发团队面前：代理执行删除时，系统究竟检查命令文本，还是检查展开后的真实路径与影响范围？
**摘要：**OpenAI近日披露，团队调查了少量Codex执行超出用户要求的破坏性操作。最严重的模式出现在临时工作清理阶段：模型错误复用系统环境变量，或在没有确认目录现状的情况下删除、覆盖路径，用户文件因此面临损失风险。OpenAI已经修改模型指令、命令检查、全权限入口、自动审查和内部评测。对开发团队来说，更重要的问题是把删除保护落到执行层：解析真实路径、限制代理活动范围，并确保关键文件可以恢复。
AI编程代理与早期代码补全工具的差别，主要体现在行动能力。
它可以阅读仓库、修改文件、安装依赖、执行测试、操作Git，还能自行创建和清理工作目录。很多任务因此缩短到几十分钟。模型一旦误判路径，影响也会直接落到文件系统。
8月19日，OpenAI工程师Tibo Sottiaux公开说明，团队在几周前开始调查少量报告：GPT-5.6在Codex中执行了用户没有要求的破坏性操作。最严重的模式与临时工作清理有关，错误命令可能删除用户文件。
公开说明没有披露受影响用户数量、文件规模和最终损失。可以确认的是，OpenAI观察到了真实失败模式，并围绕这些失败部署了多层修正。
临时目录为什么会碰到真实文件
编程代理经常创建临时目录，用于下载测试仓库、解压依赖、生成中间文件或建立一次性构建环境。任务结束后，代理再把这些内容清掉。
OpenAI披露的一种模式涉及$HOME之类的系统环境变量。模型把系统变量挪作临时用途，后续清理命令又没有正确限定目标。这类变量复用会让删除路径有机会指向用户真实主目录。
另一种情况发生在已有路径上。代理准备删除或覆盖某个“临时目录”，却没有先检查该路径是否早已存在。若目录里保存着用户数据，清理动作就可能造成损失。
问题由多步操作叠加形成。创建目录时的一个方便写法，经过变量赋值、Shell展开和清理脚本后，可能变成完全不同的目标。只看代理最初说了什么，很难判断最终会删到哪里。
审查命令名称远远不够
rm -rf会引起警觉，但文件删除并不只通过rm完成。Python、Node.js、Git、构建工具和文件管理API都能清理目录。覆盖文件有时比删除更难察觉。
执行层需要关注命令运行后的实际效果：
- 变量和相对路径展开后，目标位于哪里；
- 路径是否越过当前工作区；
- 目标是否指向Home、根目录、凭据目录或其他受保护位置；
- 符号链接是否把仓库内路径引向仓库外；
- 目录中是否存在未提交或未跟踪文件；
- 本次操作预计影响多少文件，能否恢复。
如果产品只提示“Codex准备执行一条删除命令”，用户仍然需要自己阅读复杂Shell。更有效的提示应该直接展示解析后的绝对路径、影响文件数量、Git状态和越界情况。
高风险命令被拦截后，策略还要限制最终效果。否则代理可能换用Python脚本或Git命令完成同样的删除。
OpenAI已经做了哪些修改
Tibo Sottiaux的公开说明列出了几项已经上线的变化。
Codex现在被明确要求在删除前检查目标，使用新建的临时目录，避免把系统环境变量改作临时路径，优先采用可恢复操作；范围不清时停止继续执行。
执行检查也得到加强。系统会识别高风险删除命令并升级审查。命令遭到拒绝后，代理需要寻找更安全的处理方法。
Full access变得更难被意外开启，警告信息更清晰，部分高风险权限组合受到进一步限制。Auto-review也增加了对破坏性动作的识别。
OpenAI还把已经出现的失败加入回放评测，并增加针对这类风险的强化学习任务、评分器和训练数据过滤。公司称相关行为在内部评测中明显减少，但没有公开具体数字，外界暂时无法独立判断下降幅度。
原帖建议用户保持Codex应用更新，优先使用受沙箱和审批策略约束的模式；Full access只适用于可信且可恢复的环境。
Full access的关键标准是“可恢复”
很多人把“可信环境”理解成自己的电脑、自己的仓库或熟悉的项目。模型误判通常没有恶意，环境可信并不能消除操作错误。
更实用的判断标准是恢复能力。代理拥有较高权限时，工作环境最好满足几个条件：代码已经进入版本控制，重要提交有远端副本，未提交文件有快照或文件历史，凭据可以快速吊销，构建环境可以重建。
一次性容器、隔离虚拟机和专用云工作区更适合高权限任务。代理可以安装依赖、运行服务和清理目录，个人Home、SSH密钥和其他项目不会跟着暴露。
本机真实工作区也能使用代理，但权限边界应收紧到当前仓库。仓库外访问需要单独申请，生产凭据不应长期存在于同一会话环境中。
针对此次风险，至少需要三项门禁
删除前解析并展示真实路径
系统先完成变量展开、相对路径归一化和符号链接解析，再判断风险。审批界面应显示最终绝对路径、文件数量、目录大小和Git状态。路径含义不清时停止执行。
Home、根目录、凭据目录和仓库父目录可以设为保护区。代理即使获得仓库写权限，也不能直接清理这些位置。
权限跟着任务走
用户拥有某项权限，不代表当前任务需要继承全部能力。
修复一个仓库内的单元测试，代理只需要读取和修改该工作树；安装依赖可以放进隔离环境；访问其他项目、系统配置或生产资源，应当重新说明用途并获得授权。
按任务签发短期能力，可以减少当前任务能够触碰的目录和系统。任务结束后，权限随环境一起失效。
默认采用可恢复删除
普通清理操作可以先移动到隔离区或回收站，确认任务成功后再延迟删除。涉及未提交文件、仓库外目录或大量文件时，系统先创建快照或保存清单。
恢复能力也要进入测试。团队需要知道误删后从哪里恢复、恢复到哪个时间点、需要多长时间。Git能够保护已提交代码，保护不了未跟踪文件、本地数据库和其他工作资料。
企业该记录什么
编程代理的审计日志不必无限扩张，围绕删除风险先记录四项就够用：仓库外写入或删除次数、高风险命令拦截记录、恢复是否成功、事故恢复耗时。
每次任务还应保留模型版本、权限模式、最终执行命令、文件差异和批准记录。模型和产品持续更新，同一个任务可能走出不同操作路径。缺少这些信息，事故复盘只能依赖聊天截图。
内部评测可以直接复现本次公开失败模式：变量被覆盖、临时目录已存在、符号链接指向工作区外、Git中有未提交内容。它们比普通代码题更接近生产环境中的风险。
结语
这次披露最直接的教训，是删除操作必须由路径校验、最小权限和可恢复机制共同约束。
模型指令可以降低错误概率，执行层仍要守住最后一道门。代理准备删除什么、实际会删到哪里、发生错误后能否恢复，都应该在命令运行前给出清楚答案。
主要参考
- Tibo Sottiaux（OpenAI），关于Codex破坏性操作风险与整改措施的公开说明，2026年8月19日。
- OpenAI Codex官方文档入口：Codex，访问于2026年8月21日。