Claude 再次出现高风险误操作。一名开发者原本想让 AI 帮忙写一个避免误删文件的清理脚本，结果在 Claude Code 的安全审查流程里，模型误删了其整个项目主目录，涉及约 700GB 数据。
据 MarsBit 转引微信公众号「机器之心」报道，开发者 Guillemot 平时频繁使用各类 AI 编程代理辅助开发，但这些 Agent 在任务结束后常常不会清理现场，会在 /tmp 目录下留下大量临时文件。
为了解决这个问题，他让 Claude Fable 5 编写一个脚本：为每个 Agent 在 /tmp 下创建独立沙盒目录，并在任务完成后自动清理。这个脚本的关键要求是，不能删除仍在被其他进程使用的文件。
从清理脚本到安全审查
Fable 5 随后给出了一套方案，加入了检测运行中 Agent 并延迟删除的逻辑。Guillemot 查看后认为代码过于复杂，于是要求模型简化。
问题出在后续的安全审查阶段。由于脚本涉及硬删除操作，Fable 发起了一次「对抗性审查」，即调用新的模型实例检查自己生成的代码是否安全。这一步触发了 Anthropic 在 Claude Code 中内置的安全机制。
按照这套机制，当系统判断任务涉及敏感操作时，模型会自动从高能力版本切换到更保守的版本。报道提到，这类敏感操作包括网络安全、生物技术，以及本次案例中的文件删除。其设计目的，是降低高风险场景下模型执行激进行为的可能性。
模型从 Fable 5 连续降级至 Opus 4.8
在这次事件中，系统先把模型从 Fable 5 降到 Opus 5，之后又进一步降到 Opus 4.8，由 Opus 4.8 执行安全测试。
测试逻辑本身并不复杂：删除脚本会将目标路径与 /tmp 目录和用户主目录进行比对，以确认不会误删这些关键位置。测试结果显示，这两个路径都被正确识别为危险目标，不应删除。
真正的问题出现在测试完成后的清理步骤。Opus 4.8 复用了测试阶段的同一个变量名，而该变量此前被赋值为用户主目录路径。进入清理阶段后，模型直接对这一变量执行了删除操作。
结果是，系统前一刻刚确认「主目录不能删」，下一刻就把主目录删掉了。
700GB 数据被清除，/tmp 目录反而未受影响
开发者发现异常后立即终止了进程，但损失已经发生。报道显示，约 700GB 数据被清除，一周的工作成果就此丢失。
与最初的任务目标形成反差的是，原本计划清理的 /tmp 目录并没有被删掉。
社区早已质疑安全降级机制
报道还提到，Claude Code 的模型安全降级机制此前已在社区内引发大量投诉。开发者集中反映的几个问题包括：
- 降级触发条件过于敏感，正常编码任务也可能被误判；
- 模型降级后能力明显下降，但任务复杂度并不会同步降低；
- 降级具有持续性，一旦触发，往往会贯穿整个会话，即便后续操作已经不再敏感。
有开发者甚至专门编写 hook 脚本，在检测到模型被降级时自动暂停会话，以避免较低能力的模型继续执行高风险任务。
按照文中描述，这起事故暴露出的矛盾在于：系统判定任务风险过高，于是将其交给更弱的模型处理；但能力更弱的模型，在变量作用域、文件路径等需要精确处理的环节里，反而更容易出错。
本文来自微信公众号「机器之心」（ID：almosthuman2014），作者为冷猫。