OpenAI 承认 Codex 会误删用户文件，防护补在三个层面

OpenAI 披露，其编程代理 Codex 近期收到了少量报告：模型在执行任务时做出了超出用户要求的破坏性操作，其中最严重的一类，是原本用于清理临时文件的删除命令误伤了用户自己的文件。相关说明由 OpenAI 的 Tibo Sottiaux 在社交平台上给出。

这不是一条突然冒出来的新闻。早在 7 月中旬，就有外媒和 GitHub issue 陆续记录过类似情形——有用户贴出 Codex 主动建议运行 rm -rf / --no-preserve-root 的截图，也有人报告在开了 shell 权限的会话里，整个项目目录被 rm -rf * 清空。此前这些还只是零散的个案投诉，这次是官方第一次把成因和补救措施摆到台面上。

「清临时文件」是怎么变成「清主目录」的

关键在 full access 这个模式下 Codex 给自己准备工作区的方式。据多家技术媒体的复盘，代理在开工前会另起一个临时目录，做法是把 $HOME 这个环境变量重新指向那个临时路径；后续所有"在我的家目录里干活"的命令，就都落在临时区里，互不打扰。

问题出在这条链路不够硬。一旦改写没生效、或者被后面的步骤覆盖回原值，那条按 $HOME 拼出来的递归删除命令就会原样打在真正的用户主目录上。命令本身没写错，错的是它被展开成了另一个路径——这也是为什么受害者往往在事后才发现，因为过程中的每一步看上去都很合理。

触发条件也解释了为什么报告数量不多：需要同时满足开启完全权限、跳过沙箱、且没有自动审查拦截这几个条件。绝大多数人用默认配置跑 Codex 并不会碰上。

官方补的几道防护，分量并不一样

OpenAI 这次给出的措施是一组，而不是一条：

• 要求模型在执行删除前先检查目标是否是它以为的那个目录；
• 每次都新建全新的临时目录，不复用旧的；
• 不再依赖复用系统环境变量来定位工作路径；
• 高风险删除命令会被拦截并升级到更严格的审查，其中明确禁止 rm -rf $HOME 这类写法；
• 收紧 Full access 权限被误开启的门槛。

值得掰开看的是，这几条的可靠性差着一个量级。前三条本质上仍是"告诉模型该怎么做"，属于概率性约束——模型大概率会照办，但没人能保证它在某个长上下文的第 200 步依然记得。真正确定性的只有后两条：把危险命令拦在执行层，以及让用户没那么容易稀里糊涂地把完全权限打开。这两条不依赖模型的自觉。

社区其实早走在前面。GitHub 上已经有专门给 Codex 做的第三方护栏项目，思路就是在 shell 层拦下 rm -rf、危险的 git 操作和一部分远端写操作，每次拦截都记进审计日志，同时不牺牲代理在工作区内的自由度。官方现在做的事，方向和这些民间补丁是一致的，只是终于挪进了产品本体。

代理产品的权限设计正在被重新划线

把视角拉远一点，这件事的意义不在于某个环境变量的 bug，而在于一类产品设计假设正在被修正：编程代理最初的卖点之一就是"你把电脑交给它，它自己会想办法"，而完全权限模式正是这个卖点的极端形态。现在的共识变成了，代理的自主性和它能触碰的范围必须分开谈——放开前者可以，放开后者要付代价。

所以业界给出的建议高度一致：让代理跑在容器、虚拟机或 dev container 里，或者至少把可写范围锁死在某个项目目录内；个人主力工作机和生产环境不要开完全权限。这条建议听起来老生常谈，但它现在有了具体的事故背书，而不再只是安全洁癖。

对已经在用 Codex 的人

短期能做的很直接：检查一下自己是不是在某次图省事时点开了 full access，把它关回受限模式；重要目录做一份不在同一台机器上的备份。至于日常怎么把 Codex 稳定地跑起来——权限该给到哪一档、命令审查开到什么程度、连接和登录环节容易卡在哪些地方，我们在 Codex 稳定使用指南 里整理过一份可以照着抄的配置。

删文件这种事，事后追责没有意义，能救回来的只有备份和一开始就没给出去的权限。