一条命令搞崩Mac，Claude CLI“惹祸”执行rm -rf，瞬间清空电脑Home目录
在很多人眼里，AI 似乎能搞定一切。可现实是，当疯狂的需求像洪水一样涌来，工程师们手忙脚乱地用 AI 编程工具“扑火”时，这些工具偏偏又开始四处“闯祸”，让人越来越担心。
近日，一位网友在 Reddit 上发帖吐槽，称自己使用 Claude CLI 清理旧代码仓库时出了大问题，Mac 电脑的整个用户主目录被意外清空，损失惨重。帖子里，他无奈地写道：
“这到底是什么鬼？有人遇到过类似情况吗？我现在想知道这事还有没有可能恢复，真的丢了太多工作成果……”
Claude CLI 究竟干了什么？
据这位名为 LovesWorkin 的开发者回忆，当时他只是让 Claude CLI 清理旧代码库里的软件包，结果整台 Mac 的 home 目录被彻底清空。随后，他开始调查事故原因，也让 Claude 开启自查模式。
Claude 随即诚恳地给出了分析结果：
我找到了问题，而且问题非常严重。
查看你的执行日志后，可以看到当时跑了一条灾难级别的命令：
- rm -rf tests/ patches/ plan/ ~/
注意最后那个 ~/。它指向的是当前用户的整个 Home 目录。Claude Code 实例在生成删除命令时，误把 ~/ 一并包含了进去，这会导致以下内容被直接递归删除：
- 用户的整个桌面目录（~/Desktop）
- 文档、下载等所有用户文件
- macOS 的 Keychain 数据（~/Library/Keychains）
- Claude 自身的配置和凭据（~/.claude）
- 各类应用的用户级支持数据
- 本质上就是 /Users/<username>/ 下面的所有内容
这也解释了为什么你会看到：
- 桌面目录消失
- Keychain 数据被删除
- Claude 的本地凭据不见了
最后的错误提示显示：“当前工作目录已被删除”
本就有些崩溃的 LovesWorkin，在看到 Claude CLI 有理有据地给出分析后终于得知前因，顿时不知所措，这才发帖求助。
逐渐“失控”的 AI 程序员
殊不知，遇到 AI 编程工具给自己“挖坑”的程序员并非他一个。
此前，我们也报道过，一位希腊开发者在使用 Google 最新 AI IDE 时，本想清理缓存，结果 AI 直接将整个 D 盘清空，而且使用了跳过回收站的永久删除命令。
尝试多种数据恢复方法后仍收效甚微。为了证明自己没有夸大，他录制了完整对话并发布到 YouTube，反复强调：
“我真的没编造，Google 的 AI 真的删了我的硬盘。”
更久之前，国外一家公司 SaaStr.AI 创始人兼首席执行官 Jason 在其个人社交平台发帖称，他在连续 8 天使用 AI 编程工具 Replit 构建应用后，Replit 在他明确指示不要在未经许可的情况下更改任何代码的前提下，仍然删除了他的数据库。
如何防范 AI 编程工具“惹的祸”？
毋庸置疑，AI 频繁“翻车”，也暴露了当前大模型工具的共性问题：一方面，AI 对用户指令的理解存在偏差，容易将模糊或复杂的需求误判，进而执行错误操作；另一方面，部分 AI 工具在权限控制上存在漏洞，在未充分确认用户意图的情况下，就允许执行高风险操作，比如删除大量文件、修改系统关键设置等，最终导致“小需求”引发“大事故”。
就在 Claude CLI 清空 Mac 电脑上 home 目录的帖子下方，网友们的讨论也炸开了锅。
有人觉得这个问题不在于 AI，毕竟“手滑 多敲了一个 ‘ ~/’ 命令这种事，很多工程师都干过，而现在 AI 只是在复现人类工程师的 Bug 罢了。 ”
也有网友呼吁大家还是应该理性看待这些问题：
“不能因为几次失误就否定 AI 工具的价值，它们确实能提高效率，但关键是要明确使用边界。”
“大模型还存在‘幻觉’和逻辑判断漏洞，尤其在处理具体指令时容易忽略细节，未来需要在算法优化和安全机制上下功夫，比如增加操作确认步骤、设置权限分级等。”
此外，还有不少人开始出谋划策，建议道：
“我们公司有几位工程师也遇到过类似情况。我们 正在考虑把 Claude 放在 Docker 容器里运行。”
甚至有用户在看到后，迅速推出一款辅助工具来防护类似问题。一位名为 yksugi 的开发者表示，「我看到有人发帖说，他们的 Claude Code 执行了 rm -rf tests/ patches/ plan/ ~/，结果把整个 home 目录清空了。虽然很容易把这归结为程序员失误，但我不想自己犯同样的错误。所以我开发了 cc-safe——一个 CLI 工具，用来扫描 .claude/settings.json 文件中已授权的命令，拦截高风险操作。」
它能检测的命令包括：
sudo、rm -rf、Bash、chmod 777、curl | sh
git reset --hard、npm publish、docker run --privileged
还有更多操作，它能识别容器环境，因此会跳过 docker exec 命令
使用方法：它会递归扫描所有子目录，因此你可以把整个项目文件夹作为目标一次性检查。可以手动运行，也可以通过 Claude Code 用 npx cc-safe 来执行。
- npm install -g cc-safecc-safe ~/projects
- GitHub 仓库链接：https://github.com/ykdojo/cc-safe
不过，也有技术人将问题的根源归为使用了`--dangerously-skip-permissions` 参数，HN 上网友 orliesaurus 评论道：
我看到这些“恐怖故事”一点也不意外……
--dangerously-skip-permissions 这个参数字面意思就很清楚了：它会绕过所有保护措施，直接执行命令而不询问用户。我见过的一些指南强调，这个参数只能在沙箱环境中运行，而且里面不能有任何重要数据。
应该把每个 AI 代理都当作非人类身份，只给它完成任务所需的最小权限，并且监控它的行为。
我做得更严格：绝不让 AI 代理自行删除任何东西。如果它想清理某个目录，我会先查看它生成的命令，再自己手动执行。虽然很繁琐，但可以避免灾难发生。
另外，现在也出现了一些用于安全部署 AI 代理的框架，重点是可视化和风险控制。
现在这还只是起步阶段……但总比直接 YOLO（随意执行）好，尤其是这个参数名字里明明就写着 “dangerously”。
实际上，在使用 AI 编程工具时，一定要记得先备份，留下“回滚”的余地。再者就是不要轻易把任何权限交给 AI，以及在执行 AI 给出的命令或脚本前，一定要仔细检查。毕竟 AI 现在还存在大量的“幻觉”等问题。尤其在涉及数据安全、系统操作等关键场景时，用户必须保持清醒，做好风险防控。
再智能的工具，也无法完全替代人类的判断与把关。有人甚至担心：“未来几年，随着 AI 编程普及，可能会有互联网巨头因类似事故而引发影响全球的大规模问题。”对此，你怎么看？
本文来自微信公众号“CSDN”，整理：屠敏，36氪经授权发布。
