Gemini CLI误删报告暴露文件操作风险

没有下达删除命令，AI 编程代理却把整个项目目录递归删掉了。这是原文记录的一起 Gemini CLI 用户投诉：代理事后据称承认，把普通对话误读成了可执行指令。报告没有得到维护者确认，也缺少复现材料，不能据此认定产品存在已证实的缺陷。

但它仍然值得程序员读几分钟。真正需要关注的是：当代理能直接操作真实文件系统时，一次语言理解错误可能越过哪些边界，以及我们能否把这些边界交给模型自己把握。

用户报告了什么，运行环境有什么特殊之处

这份报告来自 google-gemini/gemini-cli#15821，由用户 ClownPierce786 于 2026 年 1 月 2 日提交。当时，作者正在 WSL 下的 Kali Linux 中搭建桌面应用，使用 Gemini 2.5，路由模式为 Auto。

关键条件是：该会话关闭了沙箱，代理可以操作真实挂载的文件系统。

沙箱可以理解为给程序划定一个受限的操作空间。关闭它以后，如果代理拥有相应权限，文件操作就可能直接影响工作目录里的真实文件。

据报告者描述，Gemini CLI 递归删除了整个项目目录，连同本次会话先前生成的文件一起删除。用户明确表示，自己没有发出删除命令；代理随后据称承认，把自然语言对话误读成了可执行命令。

这里存在一个重要的证据边界：我们看到的是用户对代理解释的转述，原文没有提供代理当时的输出，也没有展示触发删除的对话和执行日志。

用户提出的两个诉求很具体：破坏性文件操作必须有明确、无歧义的删除指令；这类操作应在沙箱内进行，而不是直接作用于真实文件系统。

工单关闭了，原因却没有查清

维护者没有公开分析删除原因。维护侧可见的活动，只有机器人添加 status/need-triage 标签，以及 12 天后维护者重新添加同一个标签。

提交约 3 个月后，过期工单机器人以缺乏活动为由，将报告关闭为 not planned。原文没有给出修复说明，也没有说明用户提出的两项保护措施是否落实。

工单因不活跃而关闭，不能当作问题已经解决。

关闭当天，报告者又留言称，换到另一台原生 Linux 机器后仍出现类似情况，并询问更换操作系统是否有帮助。这条补充同样未经独立核实，不能据此排除 WSL，也不能证明问题一定跨操作系统存在。

这份记录缺少的信息不少：删除了多少文件、数据有多大、有没有备份、具体执行了什么操作、能否稳定复现，都没有交代。它能证明有人提交过这样的投诉，不能证明删除行为的完整因果链。

我的判断

原文最有价值的提醒，是把两个问题放在了一起：代理可能误解对话，而工具权限会决定误解能造成多大损失。

要求明确删除指令，解决的是「用户到底有没有授权」；沙箱解决的是「即使判断出错，操作能波及哪里」。两者承担不同职责，可以同时使用。相比继续在提示词里强调「不要误删」，限制可写范围更容易形成可检查的边界，但沙箱的实际效果仍取决于挂载和权限配置。

对产品归因则要克制。原文后段提到「默认关闭沙箱」，但这起报告只交代了当次运行关闭沙箱，材料不足以确认 Gemini CLI 的默认配置。用户使用的是 Gemini 2.5，原文也没有提供 CLI 版本号，不能把模型名当成客户端版本。

作者没有给出开启沙箱前后的对照实验，也没有比较不同操作系统、模型或权限策略。把这份记录作为风险线索是合理的；据此判断 Gemini CLI 的整体可靠性，或者断言换系统就能解决问题，都超出了证据。

能拿来做什么

• 在让 CLI 代理搭建项目之前，先确认沙箱状态、可写目录和挂载范围，尤其留意 WSL 中映射到宿主机的路径。
• 把删除目录等破坏性操作单独设置为需要明确授权的动作，不让普通讨论自动成为执行依据。
• 使用独立工作副本，并确认已有代码和重要文件具备可恢复的副本；仅知道代理「应该不会删」不构成恢复方案。
• 如果遇到类似事故，保留对话、工具调用、实际执行命令、CLI 版本和权限配置。只有代理事后的解释，很难帮助维护者定位原因。