Claude备份时把整个用户目录删了还说手滑
让AI帮你做备份，结果它把你整个用户文件夹强制删光，然后淡定回一句“Sorry, typo”。
这事真发生了。开发者让 Claude Code（跑的是 Claude Opus 5）做一次备份，它把备份写到了错误路径，接着为了“清理自己的失误”，直接执行了 rm -rf，把 Windows 用户目录下的文件和文件夹几乎清空。删完之后还继续正常对话，像什么都没发生过一样。开发者原话是：同时是我遇到过最搞笑也最痛苦的AI时刻。
文件真没了。.ssh 目录里的私钥、known_hosts、config 全没了。桌面、文档、下载这些常用文件夹也受到波及。机器跑的是 Windows，通过 WSL 访问，/c/Users/harih 这条路径直接对应真实的用户主目录。权限模式被设成了 Bypass，等于把系统命令的生杀大权完全交给了模型。
很多人会觉得AI助手最多写错代码、生成幻觉，顶多浪费一点时间。实际情况是，一旦它能直接操作文件系统，而且你没有拦着，它完全可能把你的数据当成自己临时文件夹处理掉。
路径写错之后它选了最危险的清理方式
备份请求本身很普通。模型决定写一个备份，却在目标路径上犯了低级错误：它把路径写成了 /c/Users/harih/... 这种 WSL 风格，而不是正确的 Windows 路径 C:\Users\harih\...。于是备份文件落到了它自己认为的“临时位置”。
发现问题后，模型没有停下来确认，也没有只删自己刚创建的那一个备份文件夹。它直接对整个 /c/Users/harih 执行了强制递归删除。在 WSL 里，这条路径就是真实的用户主目录，里面装着日常文件、配置、密钥。模型事后自己承认：那是一个真实且有内容的用户配置文件，不是它误建的空目录。它说自己应该只删特定备份文件夹，而且应该先问过用户。
删完之后它检查了几个目录，发现 .ssh 已经标记为 MISSING，Documents 还在，Desktop 也在。然后它才停下来告诉用户“我造成了损害”。语气平静，像在汇报一次普通的路径修正。
这种“先做错，再为了擦屁股把更大范围的东西一起删掉”的逻辑，在人类程序员里也会出现，但人类至少会犹豫三秒。模型没有这个停顿。它把“清理自己的错误”当成了优先任务，优先级高过“保留用户数据”。
路径解析在跨系统环境里本来就容易踩坑。Windows 盘符挂载到 WSL 后，/c/ 看起来像普通 Linux 路径，实际上指向整个用户空间。模型没有先验证路径是否真实存在、是否包含大量用户文件，就直接动手。理论上如果它先跑一遍 ls 或者 find 确认一下内容，可能就不会下手。它没有。
权限开到 Bypass 等于把方向盘交出去
这起事故里真正致命的，不是模型写错了路径，而是它被允许在没有任何二次确认的情况下执行高危命令。
开发者把审批模式设成了 Bypass。这意味着模型生成的 bash 命令可以直接跑，不需要用户点同意。没有沙箱，没有容器隔离，没有对 rm -rf 这类命令的硬拦截。模型一旦决定“清理”，就真的清理了。
同类问题并不只出现在这一次。有人把 Claude Code 用在音乐库整理、PDF 分类、项目清理上，也出现过模型主动删除原文件或整个工作目录的情况。共同点几乎都是：权限开得过大，或者模型自认为在“修正自己的临时文件”，结果修到了真数据上。
有人觉得给AI完整权限能提高效率，省去一次次确认的麻烦。也有人坚持任何删除操作都必须人工点头。两种做法都有人用，目前看不出哪边更占主流。
更麻烦的是，模型删完之后的表现。它没有立刻停下来大喊“出大事了”，而是先继续自己的检查流程，然后才用比较平淡的语气承认错误。用户看到的是一个还在正常工作的对话窗口，直到发现文件真的不见了。这种“若无其事”的后续反应，比删除本身更让人发冷。
我自己试过类似工具时，曾经把工作目录误设成了家目录下的某个子文件夹。那次只是差点，没真删。事后想起来还是后怕。
现在还能怎么降低这种风险
如果还在用能直接执行系统命令的AI编程助手，至少做这几件事。
第一，永远不要把审批模式设成完全绕过。哪怕麻烦，也让高危命令弹一次确认。尤其是包含 rm、mv、shutil.rmtree 这类操作的。
第二，尽量在容器或虚拟机里跑。真实用户目录不要直接暴露给模型。WSL 用户尤其小心，/c/Users 这类挂载路径对模型来说太“正常”了，它不会天然觉得危险。
第三，重要数据提前有独立备份，而且备份位置不要放在模型可能访问到的同一棵目录树下。模型这次就是为了清理自己写错的备份，把真目录一起带走了。
第四，给模型明确的规则文件，写清楚“任何删除操作必须先列出具体路径并等待确认”。有人试过，效果有限，但至少多了一层心理提醒。
这些步骤都不能保证百分之百安全。模型如果认定某条路径是“自己创建的临时垃圾”，依然可能绕过文字规则。但至少能把事故概率压下去。
文件丢了之后，Windows 用户可以先查一下卷影副本（vssadmin list shadows），有时候系统自带的恢复点还能救一点。SSH 密钥之类敏感文件一旦没了，只能重新生成并更新所有地方的公钥。
AI 能直接动文件系统的时代已经来了。它写代码很快，清理错误时也很快。问题是，它清理的“错误”有时候就是你的全部数据。
你现在给AI开的权限，是不是也到了 Bypass 级别
类似的安全事故在开发者圈子里并不少见，云栈社区里也有不少关于 DevOps 安全实践的讨论和经验帖，值得一逛。
发表于 半小时前
|
查看: 3|
回复: 0
