Claude Code 2.1.311 新增环境变量：设一个值，AI 删文件连「危险命令」保险也不问了
Claude Code 2.1.311 新增环境变量，rm -rf ~ 在 bypassPermissions 下不再弹任何确认，官方文档要求隔离环境使用。
Anthropic 的命令行编程工具 Claude Code 在 10 月 26 日发布的 2.1.311 版里加入了一个新环境变量 CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS，官方 permission-modes 文档的专节写明：把它设为 1，在 bypassPermissions 模式下，rm -rf ~ 这类针对关键路径的删除命令可以不经任何确认直接执行。The Register 在 10 月 28 日率先报道（据 IT之家 10 月 29 日的转述），变量名直白到有人怀疑是玩笑，Anthropic 技术人员随后回应「不是玩笑」。文档同时给了使用边界：只能在内容可以丢弃的隔离环境里用。
要点
- 变量与版本：
CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1要求 Claude Code 2.1.311 及以上；该版本 npm 发布时间为 2026-10-26 19:47 UTC。本站核对了同系列 2.1.310 的二进制，其中没有这个字符串，2.1.311 的二进制里出现 13 处。 - 作用范围：只放开 Bash 和 Monitor 工具里被关键路径检查拦下的
rm/rmdir，只在 bypassPermissions 模式生效，plan 模式无效；连解析不了的删除命令也会直接放行。 - 退出条件比开关本身长：官方文档列出的失效情形有九类——从 deny 规则、PermissionRequest 钩子到 VS Code 面板和嵌套会话，任何一条命中，删除就回到原来的确认流程。
背景
Claude Code 原有的「全放行」开关是 --dangerously-skip-permissions，它等价于 bypassPermissions 模式：工具调用不再逐条询问，但不是无条件放行。文档把删除命令单独设了一层关键路径检查——文件系统根目录、家目录、工作目录及其上级、挂载盘——命中即弹确认，这条检查在 bypassPermissions 模式下照样生效。换句话说，以前的 YOLO 模式删得掉项目文件，删不掉家目录。
新变量拆掉的就是这最后一层。围绕它，Anthropic 今年秋天实际上在两条线上走：一条是收紧——10 月 22 日起多数 Claude 应用把 auto mode（自动审批）设为新会话默认，我们当时的报道记过，那篇博文还特意写明 89% 的拦截率数据只适用于 Claude Code；另一条就是这种给高级用户留的后门，命名都懒得含蓄。
事实部分
官方 permission-modes 文档的专节（2026-10-29 读取）给出了可核对的使用条件：
| 项目 | 文档口径 |
|---|---|
| 变量与取值 | CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 |
| 版本要求 | Claude Code 2.1.311 及以上 |
| 读取位置 | 只读启动环境（shell 或 SDK 的 env 选项），settings 文件的 env 块里写了会被忽略 |
| 生效模式 | 仅 bypassPermissions 模式，plan 模式无效 |
| 放行对象 | Bash 与 Monitor 工具中命中关键路径检查的 rm/rmdir，包括无法完整解析的命令 |
| 验证方式 | 启动时打印一行状态：is set, so dangerous rm commands can run without a prompt 等 |
| 官方警告 | 「你会失去破坏性删除的安全确认，rm -rf ~ 可以不经询问直接执行；只在内容可以丢弃的隔离环境中设置」 |
失效情形文档列了九类，工程上值得记住的是这几种：deny 或 ask 规则一旦覆盖 Bash，哪怕会话中途删掉规则也要重启才恢复；VS Code 聊天面板和桌面应用里跑的会话一律不生效，得回终端启动；claude 套在另一个会话里（比如从某个 agent 的 Bash 工具里启动）不生效——文档还特意补了一句「别把这个嵌套限制当安全边界」；管理员 managed settings 读不到时也会保持拦截。启动行的三种文案就是给排查用的。
各方说法
The Register 是最早报道的媒体（10 月 28 日），IT之家 10 月 29 日转述时补了 Anthropic 的回应口径：该功能需用户主动设置，组织管理员施加的限制仍然可能生效，并非默认取消所有安全措施——这句与文档的失效清单对得上。因为变量名过于直白且 CHANGELOG 的 2.1.311 条目没有列出它，社区一度怀疑是恶作剧；据 IT之家转述，Anthropic 技术人员明确回应「不是玩笑」。
开发者社区的跟进更快。AshikNesin 在 10 月 28 日的 TIL 里把它称为「真正的 YOLO mode」，给出了两行用法（export 变量加 --permission-mode bypassPermissions），并引用官方文档锚点；社区文档镜像 ericbuess/claude-code-docs 的 env-vars 词条也已收录，标注「2.1.311+」「settings 的 env 块里被忽略」。两处与官方文档一致。值得注意的是，社区记忆里上一个同系列变量 CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT（2.1.281 起）只是取消确认弹窗的时间限制，这次是整个不问了。
编辑判断
对在 CI 容器或一次性虚拟机里跑无人值守任务的人来说，这是个合理的妥协：无头会话本来没人点确认，--dangerously-skip-permissions 遇到删除命令还是要人工兜底，现在终于能全自动跑完。文档的验证行设计得也克制——变量是否生效，启动时一行字就能确认，不至于误以为开了保险。
但别把它当成普通的效率开关。三个理由：一是它只对 bypassPermissions 生效，而Anthropic 正在把 auto mode 推成默认——auto 模式有分类器兜底，这个变量没有；二是有前科可查，本站 10 月 22 日报道的 LiteLLM 窃密事件里，攻击者用三名被攻破工程师的 GitHub 令牌污染发布链，把恶意代码混进一次正常更新，装了就自动执行，带这个变量跑不受信代码等于把家目录的钥匙递出去；三是文档警告的原文用的是「内容你可以承受丢失的环境」，措辞比任何评测都直白。家用机器、连着生产网关的工作机，都不满足文档对隔离环境的定义——这种开关出事几乎都出在设完忘记上。好在退出条件这么多，随手一条 deny 规则就能把它压回去。