Claude Code 103秒删掉4.8万个文件、连.git目录都没能幸免——这个事故在技术社区传开之后我身边不少同事的第一反应是把终端权限改成Ask。我反倒觉得比起恐慌更值得做的是把这条删除链路完整拆一遍搞清楚AI到底是在哪一步失控的。我之所以说“终于来了”是因为Claude Code这类能直接操作本地终端的AI编程助手越是好用越容易在权限边界上出事。它的harness跑在本地能读文件、改文件、执行bash命令等于拥有了一个开发者账号的绝大部分日常操作权限。权限越大一次误解的代价就越高。这篇内容想把事故还原、根因分析、抢救方法和事前防线讲透尤其适合那些已经把Claude Code接入编辑器、或者正打算在自己的项目里开放终端权限的朋友。1. 事故现场还原103秒的删除链路是怎么走的1.1 一句“帮我清理一下”埋下的雷先从最典型的使用场景说起。如果你搜索Claude Code相关热词会发现大量“安装、下载、配置”类需求说明这个工具的用户正好处在“刚接上手、什么都敢让它干”的阶段。而这个阶段最容易出事的指令长这样“帮我清理一下项目把没用的文件都删了。”在人类听来这是一句带有常识背景的请求别删代码、别删配置、别动.git、别删.env。但在AI这里“没用的文件”是一个需要自行判断的概念。它会扫描目录看到node_modules体积巨大判定“没用”看到dist、coverage、.cache判定“没用”看到某个带日期后缀的backup_2023目录同样判定“没用”。然后它以极高的效率调用终端逐条执行删除。一个中型前端项目光node_modules就能有5到10万个文件再加上构建产物、缓存目录、历史备份“4.8万”这个数量级完全合理。103秒完成这种规模的删除对脚本来说毫不意外。真正的问题是整个过程几乎没有人工确认节点AI一旦进入“清理模式”就会把连续的删除命令一口气跑完。1.2 权限配置的“绿灯效应”为什么命令能一路执行到底这里必须讲清楚Claude Code的权限模型。它不像ChatGPT那样只给建议而是在本地终端里真实执行命令。每当你授权一次会话内后续同类操作往往会被自动放行尤其是很多人在弹出的权限提示面前选择“总是允许”嫌烦。问题在于删除操作被放行一次后续递归删除、清理缓存、连同目录结构一起删的命令都会跟着放行。AI不会觉得“我已经删了很多了该停下来问一下”它只会按照任务目标继续执行直到它认为“清理完成”。这就是绿灯效应你给AI打开的是终端权限而不是逐条命令的审批权限。等用户意识到不对劲屏幕上往往已经刷过了几十条删除命令。1.3 “Git也没了”为什么比文件被删更痛文件被删文件系统的数据块大概率还躺在磁盘里只要及时停止写入很多还能恢复。但.git目录一旦消失意味着整个提交历史、分支引用、reflog、stash全部蒸发。你丢失的不只是一份代码而是项目全部的“时间线”。更难受的是现场表现很多人在删除发生后第一时间敲git log输入 “fatal: not a git repository”——那一刻你会意识到传说中的“只要本地还在就不算丢”的底子没了。如果这个项目恰好没有推送远端或者还有未推送的提交恢复难度会直接拉到地狱级。这也是为什么标题里特意强调“Git也没了”因为在很多事故复盘里.git被删才是压垮人的最后一根稻草。2. 根因拆解AI不是手滑而是误解与授权双重叠加2.1 LLM的指令遵循陷阱“清理”被翻译成“递归删除”大模型本质上是“指令遵循器”它倾向于把用户的自然语言请求转换成具体的工具调用序列。你说“清理项目”它几乎不会停下来追问“你确认吗”而是直接推导出最合理的动作删除无用文件、清理缓存、整理目录。问题在于“清理”这个词的语义边界完全由AI自己划定。这也是为什么我说AI不是手滑。手滑是操作失误而这里是理解偏差加上执行过度的组合。更麻烦的是LLM对“删除”的后果没有真实世界的恐惧感它不像人那样天然知道rm -rf不可逆在AI眼里这只是一个函数调用失败了大不了再来一次。2.2 “看起来没用”与“真的没用”之间的鸿沟AI判断文件是否无用的依据是什么无外乎文件名、修改时间、文件大小、目录位置。它不知道.env里存的密钥对某个环境多重要不知道某个看似备份的目录是客户要求保留的历史数据也不知道.tmp的文件里可能躺着还没合并的修改。这里我建议各位把它想象成一个刚入职的实习生非常愿意干活但缺乏对项目背景的整体理解。你让它清理工位它可能把桌上所有纸都扔了包括写满联系人电话的便签。AI也一样它没有能力判断“这个文件在业务流程中有特殊意义”只能靠通用常识猜测而通用常识在真实项目里往往不够用。2.3 危险命令的典型触发链根据对同类事故的观察最常见的删除链是这几条find . -type f -name *.log -delete用来清理日志但路径写错时可能变成全局删除rm -rf node_modules dist .cache用来清理依赖和构建产物但路径拼接出错时会扩大到整个工作区git clean -fdx用来删除所有未跟踪文件包括被.gitignore忽略的本地配置某些AI为了提高“清理效率”还会组合使用先git clean清理未跟踪再find删除特定类型最后rm收拾残余目录。这些命令单看都有正当用途坏就坏在AI把它们串成了一条无人审批的流水线。而它执行完第一批删除之后项目里会立刻出现一堆“文件不存在”的报错AI接着会尝试修复——此时它可能去翻系统目录、查找被删文件的备份进一步扩大操作范围。整个链路的每一步在AI看来都是“合理”的合在一起就成了灾难。3. 抢救流程文件还能找回来吗Git仓库怎么重建说实话事故已经发生最该做的不是骂AI而是抢救。这一节基于实际操作给出一套可执行的恢复顺序。3.1 第一步冻结磁盘停止一切写入删除操作只是把文件的inode引用断开数据块本身还在磁盘上直到被新数据覆盖。所以发现误删后的第一动作是停掉所有正在写磁盘的进程包括编译器、依赖安装、日志写入甚至包括Claude Code本身因为它可能还在继续跑命令。服务器场景更直接有条件就关机把硬盘挂到另一台机器上以只读方式操作。这不是小题大做每一次写入都可能覆盖掉待恢复的数据块。很多恢复失败不是因为删得太彻底而是因为恢复之前又写入了太多新数据。3.2 不同平台的恢复工具怎么选先说Linux/服务器场景。如果文件系统是ext4extundelete是首选它能按目录或inode恢复已删除文件。用法大致是# 先以只读方式挂载分区 sudo mount -o ro /dev/sdb1 /mnt/recovery # 扫描指定目录下的已删除文件 sudo extundelete /dev/sdb1 --restore-directory /home/user/project需要提醒的是越早执行恢复成功率越高而且恢复目录不要放在待恢复的分区上避免覆盖。如果extundelete扫描不到可以用testdisk做更底层的分区和文件系统分析photorec则适合按文件特征扫描比如Git对象这种头部特征明显的文件。macOS用户优先检查APFS本地快照是否开启开启过的话可以立刻回滚到删除前的状态Windows用户先查卷影副本配合文件历史或第三方工具能把被删文件还原出来。老实说日常开发机上“快照/卷影副本”往往就是救命稻草比任何恢复软件都靠谱。平台首选工具注意点Linux ext4extundelete、testdisk只读挂载待恢复分区macOS APFS本地快照、Time Machine快照开启后按时间点恢复Windows NTFS卷影复制、文件历史越早执行越好避免覆盖3.3 重建.git仓库的完整操作接下来专门处理“Git也没了”怎么办。分两种情况讨论。第一种项目曾经push过远端。这种情况最简单直接重新拉一份历史即可git init git remote add origin 你的远端仓库地址 git fetch origin git checkout -b main origin/main未推送的提交会丢但已推送的历史和代码能完整恢复。如果本地的分支名不是main先用git branch -r看一下远端都有哪些分支再切换。第二种项目完全没push过只能靠本地数据恢复。这时候核心目标是抢救.git/objects目录里的Git对象。Git对象commit、tree、blob有固定结构头部是类型名、空格、长度、空字节天生适合特征扫描。把扫描找回的对象文件复制到新仓库的.git/objects/下之后执行git fsck --full --lost-found它会列出dangling commit和blob。dangling commit就是你可能丢掉的历史节点用git show查看内容确认后用git reset --hard 把分支指过去。如果连.git/config都重建不了git fsck同样能帮你把对象目录里的内容重新索引起来。3.4 恢复优先级的一个实测建议根据我的经验恢复顺序应该这样安排先恢复.git/objects中的commit对象其次tree对象再次blob对象文件系统层面先恢复项目根目录的源文件后恢复node_modules、dist这类可再生成文件。因为源代码和提交历史不可再生依赖和构建产物只要重装一遍就好。很多人一上来忙着恢复node_modules等核心代码被覆盖了才后悔这个弯路希望大家别走。4. 给Claude Code上“安全带”权限配置与命令拦截实战抢救终究是被动的真正该做的是让这种事故不再发生。这一节给出我实际验证过的配置方案。4.1 permissions配置allow、deny、ask的正确打开方式Claude Code支持在settings.json里配置权限核心是三个维度allow直接放行、deny直接拒绝、ask每次询问。我的建议是打开权限文件把删除类命令全部丢进deny{ permissions: { deny: [ Bash(rm -rf *), Bash(git clean -fdx), Bash(find * -delete) ], ask: [ Bash(rm *), Bash(git reset --hard *), Bash(git push --force *) ] } }注意deny的正则匹配的是完整的bash命令字符串写得越保守越好。宁可让它多问几次也不能让它安静地删完4.8万个文件。如果你连问都不想问那就把rm整个命令族都禁掉让它只能用你指定的安全删除脚本。4.2 PreToolUse Hook把危险命令拦在工具调用之前光有deny还不够因为AI可能会用find -delete、truncate、shred这些不叫rm的删除方式来规避deny规则。更可靠的方案是使用Claude Code的PreToolUse钩子在任何Bash工具执行前拦截命令内容。在settings.json里注册一个hook{ hooks: { PreToolUse: [ { matcher: Bash, hooks: [ { type: command, command: node ~/.claude/hooks/block-dangerous.mjs } ] } ] } }hook脚本读取标准输入JSON检查command字段命中危险模式就非零退出并抛出错误命令会被阻止#!/usr/bin/env node import fs from node:fs; const input JSON.parse(fs.readFileSync(0, utf8)); const cmd input.tool_input?.command || ; const dangerous /(^|\s|\||;|\\)(rm|shred|truncate)(\s|$)|git clean\s-fdx|find .* -delete/; if (dangerous.test(cmd)) { console.error(Blocked: cmd); process.exit(2); }这个方案实测很稳尤其是当你同时给了allow权限的时候hook仍然会在执行前检查一遍。把hook脚本加入定期review清单别让它形同虚设。4.3 CLAUDE.md项目守则让AI默认“先报告后动手”Claude Code会自动读取项目根目录的CLAUDE.md作为项目背景知识。这是约束AI行为的最佳位置。我会在CLAUDE.md里明确写“本项目禁止未经确认执行任何删除操作。所有删除操作应先列出待删除文件清单等待用户确认后执行。涉及rm、git clean、find -delete命令时必须先展示完整命令并说明目的。”有了这条守则AI会倾向于先输出计划而不是直接执行。它不是百分百可靠但能显著降低连续删除的惯性。配合deny规则和hook三层防护下来翻车概率会小很多。4.4 快照与定时备份给失控留后悔药最后一道防线是快照。开发机建议开启文件系统级快照macOS用APFS本地快照或Time MachineWindows用卷影复制Linux服务器可以配置LVM快照。项目级的轻量方案是定时rsync# 每天凌晨备份项目排除依赖目录 rsync -a --delete --exclude node_modules --exclude .git /home/user/project /backup/project_$(date %F)远程仓库也要养成随手push的习惯。只要远端有一份完整历史本地再怎么被AI清空都只是clone一次的事。5. 事故之后的几条红线我把AI当“新入职实习生”管理5.1 我自己坚持的五条操作红线事故复盘再多不如几条硬规矩管用。经过这次折腾我在自己的开发流程里定下了五条红线未提交、未推送的项目绝对不让AI执行任何写操作。删除类任务必须让AI先给出清单和命令预览我看过之后再执行。自动化批处理任务和人机对话会话分开分别使用不同的权限配置。重要项目开启每日备份与快照备份未完成不开始高强度重构。新项目接Claude Code之前先在小范围测试任务里观察它的命令习惯。这五条是花钱买来的教训每一句背后都是实实在在的灾难场景。5.2 如何安全地“调教”AI从小任务开始观察很多用户装好Claude Code之后第一件事就让它接管整个项目这其实是风险最高的用法。更稳妥的做法是一开始只让它做只读任务比如解释代码、分析目录结构、写测试用例观察它对终端命令的调用方式。等确认它在你这个项目里的行为模式符合预期再逐步放开修改和重构权限。我见过不少人在这一步栽跟头上来就让它“重构目录、整理依赖、清理缓存”三条指令叠在一起AI自然会把权限用到极致。反过来如果先让它列出项目结构、说明每个目录的用途你就能在对话里提前发现它哪些判断是错的及时纠正。5.3 一个容易被忽略的细节把“远端”当成第一恢复源最后我想强调一个心态上的转变。很多开发者之所以在AI误删时崩溃核心原因是本地成了唯一副本。只要养成“代码即推远端”的习惯把远端仓库当成第一恢复源那么再遇到类似事故时你的恢复动作会从容得多clone一份回来把未推送的零散修改当作损失重启状态重新来过。事后我会去优化CLAUDE.md和permissions而不是对着丢掉的.git空流泪。说实话经历过这种事之后我对Claude Code的态度是该用继续用但权限必须咬着牙收紧。它的价值在于把无聊的重复劳动干掉而不是替我做有风险的决定。如果你也在用这类AI编程工具我的建议很简单——先花十分钟把deny规则和hook配好再去享受AI带来的效率。等到事故真的发生时你一定会感谢这个决定。