2026 年 8 月 29 日，开发者 Sebastien Guillemot 披露，Anthropic 的 Claude 在为其构建并测试一个沙箱机制时，直接在其 HOME 目录执行了 rm -rf，最终导致整个开发环境中的数据被删除。

Guillemot 直言：“坏消息，Fable 将我的整个开发机器干掉了。”

按照他的描述，Claude 为了验证自己正在开发的沙箱是否安全，选择直接拿真实 HOME 目录进行测试，结果沙箱没有成功阻止删除操作，“全没了”。

事情最初只是一次普通的磁盘清理需求。

Guillemot 表示，他平时会运行大量 AI Agent，这些 Agent 会不断向 Linux 系统的 /tmp 目录写入数 GB 的临时数据，并逐渐吃光磁盘空间。因此，他让 Fable 构建一套沙箱机制，为不同 Agent 分配独立、临时的 /tmp 空间，在任务完成后自动释放，以避免磁盘空间不断膨胀。(⁠Zamantika)

但 Claude 在实现和测试这一机制时，将原本应该被保护的 HOME 目录变成了真实测试对象。

rm -rf 是 Linux、Unix 系统中最危险的文件操作之一。

其中 rm 用于删除文件，-r 代表递归删除整个目录，-f 则意味着强制执行且不再确认。

一旦目标路径错误，可能直接清空大量文件。

开发者 Danny Willems 的第一反应是：“用 Docker Sandbox。”

也就是说，与其让 AI Agent 直接获得宿主机权限，不如把执行环境放进真正隔离的容器中，即使 Agent 出现错误，也很难伤及开发者本机文件。

另一名开发者表示，这类事故已经出现得足够多，自己准备开始每天夜间为开发电脑制作快照。这样即便某个 Agent 再次出现灾难性操作，也可以快速恢复系统。

开发者 Sebastian Nagel 给出了更激进的做法：HOME 目录每 15 分钟创建一次快照，每天执行 3-2-1 备份，同时使用 Bubblewrap 将 Claude 隔离，只向 AI Agent 挂载当前工作目录及其自己的 /tmp 空间。

Agent 从一开始就不应该拥有访问整个 HOME 目录的权限。

也有开发者认为，问题甚至不应该通过删除脚本解决。有网友提出，可以直接限制 /tmp 使用的内存或磁盘空间，或者通过 Linux Namespace、tmpfs 等机制为 Agent 创建独立的临时文件系统，从系统层面限制它能够访问和占用的空间。

还有网友提出一个更简单的保护措施：禁止 Agent 直接使用 rm，统一改用类似“垃圾桶”的可恢复删除方式。即使 AI 选错目录，也还有恢复文件的机会。

评论区里一个被反复讨论的问题，是 AI Agent 是否应该拥有如此高的本机权限。

Alex Pestchanker 认为，未来操作系统本身可能需要增加专门针对 AI Agent 的安全层，让系统能够主动限制、监督甚至阻止外部 Agent 执行可能造成灾难性后果的操作，并形成专门面向 Agent 的安全与隐私标准。

另一些网友则用黑色幽默总结了这次事故：“至少它成功证明了这个沙箱确实可以被突破。”

还有人调侃 Guillemot：“好消息是，你现在磁盘空间更多了。”

云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。