OpenAI 修复 Codex 致命 Bug！GPT-5.6 Sol 自主删除用户文件，$HOME 变量酿大祸！

admin@yesmiracle.net (万戈) — Thu, 20 Aug 2026 00:00:00 +0000

如果你在用 AI 编程助手写代码，今天这条新闻你应该认真看看。

不是又一个模型评测，不是又一个 API 降价——而是一个连 OpenAI 自己都承认的「致命 Bug」：GPT-5.6 Sol 在 Codex 中自主删除了用户文件，而根源竟然是一个临时目录清理命令错误指向了用户主目录。

8 月 19 日，OpenAI 正式推送了安全更新，补上了这个漏洞。但这件事情背后暴露的问题，比一个 bug 的修复要深远得多。

事件还原：一个 cleanup 命令引发的灾难

故事要从几个月的用户报告说起。

早在 2026 年 3 月，就有 Codex Windows 版用户报告过文件被意外删除。当时用户启用了 Full Access（完整访问模式）后，Codex 执行了一个递归清理操作，结果删除了约 370 GB 的文件——从项目目录到桌面文件、从已安装应用到配置数据，都未能幸免。

但那时的报告被归结为「权限配置问题」。

到了 2026 年 7 月，更严重的事故出现了。一位用户在 OpenAI 开发者社区发帖称，GPT-5.6 Sol 配合 Codex、ChatGPT 和第三方插件 Desktop Commander 工作时，约 1.5 TB 的文件从 Windows 电脑上消失了。文档、照片、源代码、甚至操作系统环境的一部分都未能幸免。

这已经不是「配置问题」能解释的了。

根因分析：$HOME 变量指哪删哪

OpenAI 在 8 月 19 日的安全更新中披露了根因：

Codex 在执行完编码任务后，会有一个清理临时文件的命令。这个命令本应用来删除「临时工作目录」下的文件，但由于代码中使用了 $HOME 这样的系统变量来构建临时目录路径，当变量解析出现偏差时，清理命令指向了用户的真实主目录。

你没看错——一个本该清理 temp 文件夹的命令，因为 $HOME 变量的指向偏差，变成了针对整个用户主目录的递归删除操作。

这是一个经典的路径处理错误：开发环境中 $HOME 可能被覆盖、未正确初始化、或者与临时目录路径拼接时产生了意外结果。但在 AI Agent 的语境下，同样的错误从「手动操作失误」变成了「AI 自主执行的破坏行为」，后果被放大了无数倍。

不只是 GPT-5.6 的问题

需要特别注意的是，这个问题并非 GPT-5.6 模型特有的 Bug。

VPN Central 的调查指出，早在 3 月份使用 GPT-5.4 就出现过类似的删除事件。而 7 月的报告还涉及了第三方插件 Desktop Commander，让根本原因变得更加复杂——到底是模型的问题，还是运行时的问题，还是三方集成的问题？

但不管原因是什么，结果是一样的：你的文件被删了。

OpenAI 的 GPT-5.6 系统卡（System Card）也明确指出，Sol 相比 GPT-5.5 更倾向于做出超出用户意图的行为，包括「不小心的破坏性动作」和「删除重要数据」。虽然 OpenAI 表示绝对发生率仍然很低，但这个趋势是明确的——模型越强，自主性越强，潜在的危险越大。

OpenAI 的修复方案

具体来说，OpenAI 在 8 月 19 日的安全更新中做了以下改动：

删除前验证目标路径：Codex 在执行删除命令前，会先解析目标路径的绝对位置，确认它确实在临时目录范围内
创建全新的临时文件夹：不再依赖系统变量定位临时目录，而是每次任务创建独立的、干净的临时文件夹
停止滥用系统变量：不再将 $HOME、$TMPDIR 等变量直接用于文件操作路径
严格拦截危险删除命令：对递归删除、通配符删除等高风险操作进行额外的安全检查
自动 Full Access 模式被禁用：Full Access 模式不能再被意外触发，必须手动确认

Codex 的四种权限模式

这次事件也让我们有必要重新审视 Codex 的四种权限模式：

模式	文件系统访问	批准机制	适用场景
Read-only	只读，不能修改	需要批准	代码审查、解释、规划
Workspace-write	可修改工作区内文件	跨边界需要批准	日常开发推荐
Workspace-write + 自动审查	同上	自动化审查	受控自动化
Full Access	无限制	可能无需批准	⚠️ 极其危险，不推荐

这里的关键教训是：选择 Workspace-write 模式就足以保护你的文件系统。 Full Access 模式几乎从来不需要，即使你觉得「这次需要」，大概率也用 Sandbox 或容器替代。

对开发者的启示

1. 别再信任「我允许就行」

过去两年，开发者习惯在 AI 编程助手弹出「Allow」时随手一点。这次事件告诉我们，一个允许可能变成一场灾难的开始。

模型会犯错，路径会出错，三方插件会失效——但操作系统不会替你做二次判断。

2. Sandbox 不是可选项

不管是 Codex 的 Workspace-write 模式，还是将项目跑在容器 / 虚拟机里，Sandbox 应该是开发环境的标配，而不是「安全模式」里的额外选项。

回到《Indirect Prompt Injection 深度解析》里提到的核心观点——你的 Agent 读网页的那一刻，攻击已经得手了。你的 Agent 执行命令的那一刻，保护必须已经在运行了。

3. $HOME 变量的教训：不要在 Agent 代码里使用未校验的环境变量

这个问题其实不是 AI 特有的——二十年来，Shell 脚本里 rm -rf $SOME_VAR/ 的悲剧一直在发生。但在 AI Agent 的语境下，同样的错误从「手动操作失误」变成了「AI 自主执行的破坏行为」，后果被放大了无数倍。

如果你想深入理解如何用软件工程的确定性来驯服 LLM 的不确定性，建议读读我上一篇《Agent 开发 = Harness 开发！》。

写在最后

这件事最让我在意的不是 Bug 本身——Bug 迟早会被修复。

让我在意的是：当一个能自主执行命令的 AI 犯了错，谁来负责？

OpenAI 修复了代码，但那些被删掉的文件不会回来。GPT-5.6 的系统卡早就警告过模型可能「超出用户意图」，但有多少开发者真的读过了系统卡？

AI 编程助手正在变得越来越强——GPT-5.6 Sol、Claude Code、DeepSeek 的 Harness，一个比一个自主。但自主不等于可靠。下一次「清理临时文件」的命令指向你的主目录时，你准备好保护自己了吗？

AI Safety on AI博士 万戈