Claude Code 误删案例暴露目录联接风险

dev.to · AI#Claude Code#Windows#Agent安全

Editor brief · 编辑速览

文章转述一起 Windows 事故：Claude Code 在跳过权限确认的模式下清理项目，递归删除据称沿 NTFS 目录联接越出项目边界，波及用户目录。案例涉及 Git Bash、pnpm 生成的联接和脚手架重建流程。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

一次 Next.js + Payload CMS 项目的初始化，最后变成了 Windows 用户目录的数据丢失事故。按原文转述，Claude Code 为了重新搭建项目执行了一条删除命令，却经由 NTFS 目录联接越出了项目边界，报告者估计损失约 165.66GB 数据。

这件事值得看，不只是因为用了 rm -rf。它把三个容易被分开讨论的问题叠在了一起：Windows 文件系统的链接语义、Git Bash 的删除行为，以及关闭权限检查后，AI 编程工具能直接执行到哪一步。

GitHub issue #36339 提交于 2026 年 3 月 19 日。报告中的环境是 Windows 11、Git Bash 和 Claude Code v2.1.51，启动时启用了 --dangerously-skip-permissions。

任务起点很普通：生成一个 Payload CMS 网站模板。

pnpm dlx degit payloadcms/payload/templates/website aldaba-v2

这里要留意模板来源 payloadcms/payload/templates/website。生成后，独立安装遇到了 workspace:* 依赖问题，也就是模板中的依赖声明仍然依赖原工作区的上下文。Agent 选择删除目录，再重新开始。

它随后执行了这条清理命令：

rm -rf /c/Users/guido/aldaba-v2

要留意目标路径：命令写的是项目目录，事故报告描述的删除范围却扩展到了 C:\Users\guido。

原文给出的解释是，pnpm 在模板的 node_modules 中创建了 NTFS 目录联接（junction）。它看起来像目录，实际指向另一个位置。按照原文对事故的描述，Git Bash 的 rm -rf 沿着联接进入真实目标，其中一个联接指回用户目录，于是递归删除越过了项目边界。

原文称，相关问题在 PowerShell Core 6+ 中已经处理，但没有回补到 Claude Code 的 Bash 工具所调用的 Git-for-Windows 工具链。这里描述的是特定工具链的行为，不能据此认定所有环境中的 rm -rf 都会以同样方式处理链接。

命令里的目标路径，并不一定等于实际受影响的数据边界。

报告者估计，约 165.66GB 数据被删除，涉及 1,593,350 个文件和 276,382 个文件夹，包括个人文件、AppData，以及业务正在使用的数据。删除前后都没有出现警告或确认，用户是在发现桌面空了之后才察觉异常。

提交 issue 时，付费 NTFS 数据恢复仍在进行，尚未恢复出数据。原文没有给出最终恢复结果，因此不能把当时的状态写成永久无法恢复的结论。

issue 带有 bug、data-loss 和 has repro 标签，还关联了此前的 #29249、#29023。按原文统计，这是第三起同类故障形态的报告。但标签和关联工单并不等于独立验证：原文明确承认，没有在案的第三方复现记录。

约六周后，GitHub Actions bot 以 stale 和「not planned」关闭了工单。按原文记录，没有维护者回应，也没有修复交付。它说明问题没有在这张工单里获得处理，尚不足以证明每份报告的底层原因都已确认一致。

作者把文件删除问题和 Agent 的执行方式放在一起看，这个方向成立。即使由人手动执行，同样的工具链问题也可能造成损失；Agent 增加的风险，在于它可以把「安装失败，删掉重来」连续执行下去，而运行环境又允许它直接动手。

但这次启用了 --dangerously-skip-permissions。这个参数按设计就会关闭 Claude Code 自身的权限检查。原文没有说明正常模式下，这条命令是否一定会触发确认，因此不能直接得出「默认配置也会无提示删掉用户目录」的结论。

同样，普通的执行确认与删除范围检查是两回事。即便弹窗完整展示了命令，用户看到的仍然可能只有项目路径。要识别联接指向哪里，需要额外检查文件系统关系，原文没有证明 Claude Code 做过这一步。

我更看重这次事故暴露的工作边界问题：可随时重建的项目，应该放在可承受整体丢失的环境里。

这是基于事故机制的工程判断。原文没有比较权限确认、容器、虚拟机等方案的防护效果，也没有给出对照实验，不能替其中任何一种方案承诺绝对安全。

在 Windows 上处理 pnpm 项目时，递归删除前先检查 node_modules 中的 junction 及其目标；不要仅凭命令参数里的路径判断删除范围。
为 Next.js、Payload CMS 这类模板试验准备独立环境，例如专用虚拟机，并限制它能访问的个人和业务数据。不要把整个用户目录暴露给可丢弃的试验项目。
将「生成项目」与「删除已有目录」分开授权。遇到 workspace:* 安装问题，先定位依赖声明和工作区要求，再决定是否需要重建。
日常 AI 编程保留权限检查，谨慎使用 --dangerously-skip-permissions。同时给重要数据保留可恢复的备份，因为执行确认无法替代恢复能力。