连最后一道确认都不要了：Claude Code 新开关让智能体删文件不再请示

Anthropic 在 10 月 27 日给 Claude Code 加了一个名字长得像警告标语的开关：只要把环境变量 CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS 设为 1，智能体再执行删除命令时就不再停下来请示。消息最先来自 Anthropic 技术员工 Daisy Hollman 的社交媒体发帖，随后由 The Register 在同一天报道。这不是默认行为的改动，也不是一次常规的功能发布，它更像是一次公开的表态：Anthropic 愿意把最后一道刹车也交到用户手里，前提是你真的清楚自己在做什么。

先把事实说准。这个开关出现在 Claude Code v2.1.311 里，针对的是 rm、rmdir 这类删除命令。Hollman 在帖子里先纠正了一个常见误解：“有意思的是，--dangerously-skip-permissions 其实并不会批准所有事，我们还是会拦下一些显而易见的操作，比如 rm -rf ~。”接着她给出新变化：“但今天的版本可以让你在确实想要的情况下关掉这个限制，只要设置一个新的环境变量 CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1。”因为变量名实在太夸张，第一批看到的人里有人以为是玩笑，Hollman 随后回应：“不是开玩笑！希望这能帮到你，也希望这个变量名足够好记。”

先理清权限阶梯，这个开关到底在第几层

要理解这个开关为什么值得专门写一篇文章，得先看 Claude Code 的权限阶梯。按 The Register 的梳理，Claude Code 有 default、acceptEdits、plan、auto、dontAsk 和 bypassPermissions 几种权限模式。其中 auto 模式名义上几乎什么都放行，但背后还跑着安全检查，并且在 8 月成了默认模式；bypassPermissions 同样名义上什么都放行，但连这些后台检查也没有，它由命令行参数 --dangerously-skip-permissions 开启，最早出现在 2025 年 6 月 9 日的 v1.0.18 里。

关键在于，即使开到 bypassPermissions 这一层，也还有例外。rm 和 rmdir 这类删除命令一直不在自动批准之列，执行前仍然要弹出确认。这道确认就是 Hollman 所说的“显而易见的操作”防线：它拦的不是普通的文件编辑，而是那种一旦执行就很难挽回的动作。新环境变量的作用范围就卡在这里，它关掉的正是这最后一道确认。换句话说，它不是从“处处请示”跳到“处处放行”，而是从“只剩删除还在请示”走到“连删除也不请示”。默认用户什么都不用做，什么都不会变；只有主动设置了这个变量的人，才会进入完全无人值守的删除模式。

为什么会有人想要这个开关

这个需求是真实存在的，而且不难理解。跑在无人值守环境里的智能体最怕的就是半夜卡在一个确认框上：一次批量清理、一次构建产物的轮换、一次测试环境的重置，只要其中一步涉及删除，整个流程就会停下来等一个人去点确认。对于本来就设计成用完即弃的沙箱来说，这道确认纯粹是摩擦。Anthropic 的选择是把决定权交给用户，而不是替所有人把这道确认焊死。从产品逻辑上讲，这和 --dangerously-skip-permissions 的存在理由是一致的：工具默认保守，但给明确知道自己在做什么的人留一条出路。

但“有人需要”和“你可以随便开”是两回事。删除命令的危险不在于它本身，而在于它和智能体的不确定性叠加在一起。模型可能误解任务范围，可能把路径拼错，可能在错误的目录里执行一条本意是清理缓存的命令。人类在终端里敲 rm -rf 之前还会犹豫一下，智能体不会犹豫，它只会执行。过去这道确认存在的意义，就是在模型犯错和灾难发生之间留一个人类干预的机会。关掉它，等于把这个机会也省掉了。The Register 在报道里也提醒，业界已经有不少智能体误删文件、造成数据丢失的案例，这不是理论风险。

什么人绝对不要碰它

先说最直接的结论：如果你在自己的主力开发机上跑 Claude Code，不要开这个开关；如果你的工作目录里有任何不能丢的东西，不要开这个开关；如果你还没搞清楚自己的项目里哪些目录是绝对不能删的，不要开这个开关。变量名里连着两个“dangerously”不是修辞，它就是字面意思。这个开关的合理使用场景只有一个：在一个可以随时销毁重建的环境里，比如一次性的容器或虚拟机，里面的数据丢了也不心疼，宿主机的真实数据根本不在它的可达范围之内。

还有一类场景要格外警惕：把这个开关写进长期有效的 shell 配置、CI 脚本或者团队共享的环境模板里。一次性的沙箱实验和长期的默认配置是两件完全不同的事。前者是你主动为某次任务承担风险，后者是让以后每一个接手的人、每一次自动触发的任务都在不知情的情况下继承这个风险。环境变量很容易被复制、被继承、被遗忘，等到出事的时候，往往没人记得它是什么时候加进去的。如果你确实要在某个流程里用它，让它只活在那一次任务的作用域里，用完即回收，不要让它变成基础设施的一部分。

如果你非用不可，五条硬规矩

第一，只在用完即弃的环境里开。容器、虚拟机、临时沙箱都可以，前提是删错了也只损失这一次任务的产物，而不是你的代码仓库、照片、密钥或者客户数据。第二，事前做快照。跑任务之前先确认备份和快照是可用的、是最近的、是真的能恢复的，而不是“我以为有备份”。第三，收紧工作目录。让智能体只能在明确划定的目录里活动，不要给它整个 home 目录的自由。第四，管好上层限制。The Register 明确提到，托管设置等其他限制仍然可能生效，这意味着企业管理员仍然有最后的约束手段，不要指望一个环境变量就能绕过所有管控，也不要在受管设备上擅自试探这条边界。第五，跑完复盘删除记录。无人值守不等于无人复核，任务结束后看一眼它到底删了什么，是发现模型理解偏差最便宜的办法。

这五条里最容易被忽略的是第二条。很多人对“沙箱”的理解停留在“隔离了就安全”，但隔离防的是对外部的破坏，不是沙箱内部的数据丢失。如果智能体在沙箱里删错了你挂载进去的真实目录，隔离帮不上忙。挂载关系、卷映射、工作目录的边界，这些才是真正决定 blast radius 的东西。开这个开关之前，先把这些边界画清楚，再谈效率。

一个值得注意的透明度缺口

The Register 还记录了一个细节：这个变化没有出现在 v2.1.311 的更新日志里。这也是最初有人怀疑它是玩笑的原因之一。一个以安全为卖点的公司，在自家旗舰编程工具里加了一个移除安全确认的开关，却没有在更新日志里写明，这本身就值得追问。可能的解释有很多：发布节奏太快、日志遗漏、或者有意低调处理一个只面向极少数高级用户的选项。但无论原因是什么，结果都是一样的：用户无法只靠更新日志发现这个开关的存在，只能靠社交媒体帖子和媒体报道。这对一个涉及删除权限的改动来说，不是好的披露方式。

这个缺口也给所有使用者提了个醒：不要把更新日志当成唯一的信息来源，也不要把社交媒体帖子当成正式文档。如果你打算在生产流程里依赖这个开关，先在自己的环境里、在可丢弃的数据上实测它的行为，确认它在你的版本、你的运行方式下确实如描述那样工作，再决定要不要用。Anthropic 未来可能会在文档里补上正式说明，在那之前，任何超出 Hollman 帖子原话的推断都应该被当成未经证实。

这件事真正说明了什么

把视野拉开一点，这个开关是 10 月编程智能体竞争的一个缩影：各家都在比谁能让智能体跑得更自主、更少打扰人。更少的确认意味着更顺滑的自动化，也意味着更少的纠错机会。Anthropic 的做法是把选择权做得非常显眼：变量名本身就是警告，不读文档的人看到名字也会犹豫一下。这是一种诚实的设计，至少它没有把危险藏起来。但诚实不等于安全，名字再吓人，也拦不住复制粘贴。

对普通开发者来说，这件事的正确反应不是跟风去开，也不是恐慌。默认行为没有变，你的 Claude Code 今天和昨天一样工作。这个开关只影响那些主动去找它、主动去设置它的人。而对那些确实需要无人值守删除流程的人来说，它是一个值得认真评估的工具，前提是评估发生在沙箱里，而不是发生在装着真实数据的机器上。智能体越自主，人类对边界的定义就越重要。这个开关没有改变这条规律，它只是把这条规律推到了更极端的位置：当最后一道确认也被拿掉之后，剩下的安全措施就只剩下你事先划好的边界了。

从一个参数到一个变量：Anthropic 一贯的让步逻辑

把时间线拉出来看，这次的变化并不是突然冒出来的。2025 年 6 月，--dangerously-skip-permissions 参数第一次出现，它开启的 bypassPermissions 模式已经是在告诉用户：如果你嫌确认框烦，可以一口气全关掉。到了 2026 年 8 月，auto 模式成了默认模式，这个模式名义上同样几乎什么都放行，只不过背后还保留着安全检查。10 月 27 日的新变量，则是把 bypassPermissions 模式里最后剩下的那一点例外也拿掉了。三步走下来，方向始终没变：默认越来越顺滑，极端选项越来越彻底，而每一次让步都配了一个越来越直白的名字。

这种命名方式本身就值得琢磨。--dangerously-skip-permissions 已经够直白了，新变量又在前面加了一个 EVEN_MORE_DANGEROUSLY，等于在名字里连喊两遍危险。Anthropic 显然知道这个开关会被截图、被转发、被断章取义，所以它选择把警告写进名字，让任何复制这行配置的人都无法假装没看见风险。这是一种很聪明的沟通策略，但它也有明显的上限：名字只能警告第一次看到它的人，警告不了第二次、第三次经手它的人。配置一旦被写进脚本、文档、教程或者团队模板，名字里的警告就会迅速贬值，变成一行谁也不再细看的样板代码。真正的安全从来不靠名字吓人，靠的是边界和默认值，而这个开关恰恰是把默认值这道防线主动交了出去。

还有一个角度容易被忽略：这个开关的出现，说明 Anthropic 认为“完全无人值守”已经是一个值得正式支持的运行形态，而不是一种 hack。过去，无人值守往往意味着你要自己绕过各种确认，或者接受流程半夜卡住；现在，官方给了一个明确的、命名的选项。这对那些在沙箱里跑批量任务的团队是好消息，因为他们终于不用再靠一些半官方的变通办法来维持自动化。但对普通用户来说，这个信号也可能被误读：官方出了这个选项，不代表官方推荐你用它。Hollman 的原话里有一个很关键的限定词，“if you really want”，如果你确实想要。这个限定词才是整件事的正确姿势：它是一个为少数明确场景准备的出口，不是给所有人的新默认。

误删通常是怎么发生的：三种最常见的失败模式

第一种是目录搞错。智能体理解的“当前项目”和你以为的“当前项目”不一定是同一个目录，一次路径拼接错误、一次符号链接解析差异，就可能让清理命令落在错误的位置。人类在终端里输入删除命令之前，眼睛会扫一眼路径；智能体没有这个习惯，它对路径的信心来自上下文，而上下文是可能出错的。第二种是范围扩散。本来只想删几个临时文件，结果因为通配符、递归参数或者变量展开，删除范围悄悄扩大了一圈。命令行里这类“差一点”的故事实在太多了，而智能体在批量操作时尤其容易把“差不多”当成“就是”。第三种是内容误导。智能体读取的项目文件、日志、网页内容里可能夹带着有问题的指令或者误导性的描述，模型一旦照单执行，删除命令就可能出现在它本来不应该出现的任务里。这三种模式有一个共同点：它们都不需要模型“故意”破坏，只需要一次普通的理解偏差，就足以让一条删除命令变成灾难。

这也是为什么“最后一道确认”这个说法如此重要。它不是一个普通的确认框，它是整条权限阶梯上唯一一个专门针对不可逆操作的检查。普通的文件编辑错了可以改回来，代码写坏了可以回滚，唯独删除很难有低成本的后悔药。备份和版本控制当然能兜底，但它们都有自己的前提：备份得是最近的、是完整的、是真的能恢复的；版本控制只覆盖被追踪的文件，那些没进仓库的本地数据、下载文件、个人资料根本不在它的保护范围里。关掉删除确认，等于同时放弃了“事前拦截”和“事后低成本恢复”之间的那层缓冲，剩下的就只有你事先准备好的备份质量了。

对 vibe coding 的爱好者来说，这一点尤其值得单独提醒。很多人在自己的主力机上用智能体做原型，工作目录里混着代码、密钥、个人文件和各种来不及整理的资料，权限往往开得比较大，因为“先跑起来再说”。这种使用习惯和这个新开关是最危险的组合：你不是在沙箱里做实验，你是在真实生活里做实验。原型阶段的正确做法恰恰相反，先把权限收紧、先把重要目录划出工作区、先确认什么东西丢了会心疼，然后再谈效率。一个开关不会让你的原型跑得更快，它只会让一次失误的代价变得更大。

团队管理者现在应该做什么

如果你负责一个团队，这件事的重点不在你个人用不用这个开关，而在你的团队会不会有人在不知情的情况下用上它。第一步是明确表态：在团队的智能体使用规范里写清楚，这个变量只允许出现在一次性沙箱任务里，不允许出现在共享配置、CI 模板和新人上手文档里。第二步是检查现状：搜索团队的共享脚本和环境模板，确认里面没有已经埋下的类似配置，顺带也检查一下有没有人把 --dangerously-skip-permissions 写成了默认启动参数。第三步是利用管理手段兜底。The Register 提到托管设置等其他限制仍然可能生效，企业管理员应该确认这些管控在自己的组织里确实覆盖了删除类操作，而不是假设它们默认就生效。

第四步是把这件事变成一次具体的演练，而不是一封群发邮件。找一个可丢弃的环境，让团队成员实际看一次智能体在完全放行模式下会删什么、删多快、日志里留下了什么，比任何规范文档都管用。很多人只有在亲眼看到删除操作以机器速度执行的时候，才会真正理解“无人值守”四个字的分量。第五步是约定复核流程：任何跑在放行模式下的批量任务，结束后都要有人看一眼删除记录，确认删除范围和任务目标一致。这个复核不需要很重，但它必须存在，因为它是你发现模型理解偏差的最后机会。

最后回到一个更根本的判断。工具厂商会不断给你更顺滑、更自主的选项，这是竞争决定的，不会停下来。你的工作不是拒绝所有新选项，也不是照单全收，而是为每一次让步划出清晰的边界。这个新开关的边界其实很好划：只在可丢弃的环境里、只在单次任务的作用域里、只在备份已验证的前提下。边界划清楚了，它就是一个有用的效率工具；边界没划清楚，它就是一次等着发生的事故。10 月 27 日的这条新闻真正值得记住的，不是那个很长的变量名，而是它背后的提醒：当智能体不再向你请示的时候，你要比以前更清楚，哪些东西是绝对不能让它碰的。