Copilot CLI恢复检查点导致1GB未跟踪文件被删

Copilot CLI 的Checkpoint Restore执行了git clean -fd，删除了1GB从未被Agent触碰过的数据

checkpoint/undo功能本该是那个"安全按钮"。然而在这个案例里，按下它却抹掉了整整1GB与该Agent毫无关系的数据。

GitHub issue #1675，提交至github/copilot-cli：用户在运行过程中按下Escape键，选择回滚到更早的checkpoint——这是CLI内置的undo功能，本意是仅还原Agent在该次会话中所做的变更。

然而回滚路径——SnapshotManager.rollbackToSnapshot()——执行了git checkout --force和git reset --hard来撤销已跟踪文件的变更，随后又对仓库根目录执行了git clean -fd。git clean -fd不会区分文件是谁创建的：它会删除仓库中每一个未跟踪的文件和目录。checkpoint系统的快照只记录Agent自身的修改，因此它既无法知晓、也无法饶过那些来自其他地方的未跟踪文件。

在这个案例里，约1GB的评估输出——output/目录下多个子目录中的.jsonl和.xlsx文件——被一并扫走。这些文件是另一个独立的Python脚本生成的，Agent在整个会话中只是读取过这些文件，从未创建或修改过。没有回收站，也没有恢复步骤；git clean -fd是直接删除文件的。

报告者提出了四个修复方案：只追踪并删除Agent真正创建的文件，而不是一刀切的清理；完全跳过git clean，因为快照机制本身就能单独还原文件；删除前弹出文件数量和大小的警告；或者把被扫掉的文件移到可恢复的回收位置，而不是直接删除。issue被关闭了，帖子中没有维护者的任何解释。

它没有确认的事

issue被关闭且未附带任何评论，因此无法确认这件事是否——或者如何——被修复了。这是报告者单方面的说法，并非独立复现的多用户案例，尽管该机制（一个调用git clean -fd的回滚例程）可以从描述的行为中验证，而且这正是那种在相同条件下可以可靠复现的bug：当checkpoint restore触发时，存在于仓库中但位于Agent工作集之外的未跟踪文件。

为什么值得了解

有趣的部分不是"Agent删除了文件"——而是安全功能本身造成了删除。checkpoint/rollback系统本该是当Agent运行跑偏时用来求助的那个东西。但这个功能的杀伤半径超出了它的设计保护范围：它只能追踪Agent自身的编辑，却清理了整个仓库根目录，所以任何以未跟踪状态存在于该目录中的其他东西——构建输出、生成的数据、脚本的结果——都暴露在危险之中，而快照系统没有办法识别出它们。如果你正在使用或构建一个会调用git clean的undo/checkpoint功能，这是你需要在下一次依赖它之前检查的范围失败。