如果你在用 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，一个比一个自主。但自主不等于可靠。下一次「清理临时文件」的命令指向你的主目录时，你准备好保护自己了吗？
用 Workspace-write，开版本控制，多备份。老生常谈，但常谈常新。