Claude Code 2.1.136：当 AI Agent 的安全阈门从‘相信’变成‘验证’

你让 Claude Code 在 auto mode 下跑一个长任务，回来发现它把你的 AWS credentials 写进了日志文件。或者更糟：它在你没看到的一个弹窗里点了 “允许”，然后把一个安全测试脚本推到了生产环境。

这不是假设。Anthropic 自己的数据说，Claude Code 用户手动批准了 93% 的权限提示。人们已经点习惯了。当一个工具每天向你请求几十次批准，你很快就不再看内容了。这就是为什么 2.1.136 里有两个安全改动值得重视：security-test 标签不再自动允许/拒绝，必须人工审批；新增的 hard_deny 让分类器规则可以无条件执行，无视用户意图。

这不是普通的 bug 修复。这是 AI agent 安全模型正在从“信任”偏移向“验证”的一个缩影。

为什么 93% 的批准率是个问题

Anthropic 在介绍 auto mode 时公开了这个数据：用户手动批准了 93% 的权限请求。听起来像是好事 — 用户信任这个工具。但问题在于，当批准率超过 90%，每一次弹窗都在消耗注意力，却没有增加实际安全性。用户在第三次点击 “允许”后就不再看内容了。

为了解决审批疲劳，Claude Code 提供了两个极端选项：

• 打开沙箱（sandbox）—— 安全但高维护，每个新能力都需要配置
• 使用 —dangerously-skip-permissions —— 零维护但毫无保护

Auto mode 是 Anthropic 给出的第三条路：用一个基于模型的分类器在后台审查每个操作，阻止任何超出用户请求、指向未识别基础设施或看起来被恶意内容驱动的操作。分类器运行在两个阶段：第一阶是快速单 token 过滤（是/否），第二阶只在第一阶触发时才启动链式思考推理。

但分类器不是人类。它会犯错。Anthropic 自己估计分类器的误拒率约 17% — 即 17% 被阻止的操作其实是安全的。这是一个明确的 trade-off：你在用效率换取安全边界。

2.1.136 的两个关键安全改动

security-test 标签不再自动处理

在之前版本中，带有 security-test 标签的操作会被自动授权或自动拒绝，不需要人工审批。现在这个自动化被彻底移除了：所有 security-test 相关操作都必须经过明确的人工审批。

这是一个重大的信号。安全测试是高风险操作的代表：它可能涉及渗透测试、权限提升、或者在生产环境中执行可能造成损失的命令。让一个自动标签决定这些操作是否执行，等于把高风险决策交给了一个无法负责的机制。移除自动化是正确的选择，但它也意味着你不能再在 auto mode 下无监睬地跑安全扫描任务了。

hard_deny：无条件阻止

新增的 settings.autoMode.hard_deny 是一个强力机制。它允许管理员配置一类分类器规则，这类规则会无条件阻止相关操作，无视用户意图、无视 allow 例外。

Auto mode 的权限模型分为三层：

• permissions.deny —— 在分类器之前执行，不可覆盖
• autoMode.soft_deny —— 分类器阻止，但可以被用户明确意图覆盖
• autoMode.allow —— 例外列表，可以覆盖 soft_deny

hard_deny 是一个新的层级，位于 soft_deny 和 allow 之间：它被分类器阻止，且不接受任何覆盖。用户即使直接要求执行这个操作，如果它触发了 hard_deny 规则，也会被拒绝。

这解决了一个真实问题：在某些组织环境中，有些操作是绝对不能执行的 — 无论用户觉得自己有多么充分的理由。例如 rm -rf /、生产环境部署、敏感数据库写入。过去，这些需要通过 permissions.deny 来配置，但 permissions.deny 运行在分类器之前，不会看到完整的会话上下文。hard_deny 让分类器可以基于完整上下文做出无条件拒绝。

还修了什么

2.1.136 有 52 个 CLI 改动和 2 个系统 prompt 改动。除了安全模型的重大调整，还有几个值得关注的修复：

• MCP servers 在 VS Code extension、JetBrains plugin 和 Agent SDK 中 /clear 后不再静默消失
• 多个 MCP server 并发 OAuth 刷新时不再丢失 refresh token
• 修复了并发 credential write 覆盖新轮转 OAuth token 造成的登录循环
• plan mode 现在正确阻止文件写入，即使存在匹配的 Edit allow rule

后两者特别值得注意。它们都是 race condition — 多个进程或会话同时操作凭证时的竞争条件。这说明 Claude Code 的用户规模已经到了单机并发都会出问题的地步，而 Anthropic 正在把这个工具从单用户 CLI 向多会话、多插件的生产级平台转化。

六种权限模式，你该用哪个

Claude Code 目前支持六种权限模式：

| 模式 | 什么可以自动执行 | 最适合 | | default | 仅读取 | 初次使用、敏感工作 | | acceptEdits | 读取、文件编辑、常见文件系统命令 | 代码迭代 | | plan | 仅读取（不写文件） | 探索代码库 | | auto | 所有操作，带后台安全检查 | 长任务、减少审批疲劳 | | dontAsk | 仅预先批准的工具 | CI 和脚本 | | bypassPermissions | 所有操作 | 隔离容器和 VM 专用 |

auto 模式是唯一一个在安全与效率之间寻找平衡的选项，但它也是唯一一个依赖模型判断的选项。其他模式都是确定性的：default 总是问，bypassPermissions 总是执行。auto 模式却在你不知道的时候做出了一个概率性判断。

Anthropic 自己的建议是：auto 模式是为那些之前在用 —dangerously-skip-permissions 的人准备的，不是为那些每个提示都仔细审查的人准备的。如果你对高风险基础设施操作保持警惕，手动审批仍然是更安全的选择。

适用场景

需要长时间自主运行的任务

自动化代码迁移、大规模重构、或者需要跑几十个测试用例的场景。这些任务涉及成百上千次文件读写和命令执行，手动批准会完全打断流。auto 模式让这些任务可以无间断运行。

多人协作的团队环境

hard_deny 和 managed settings 允许管理员在组织层面定义绝对不能执行的操作。每个开发者都可以在这个框架内工作，不需要担心某个人的 Claude Code 实例意外删除了生产数据库。

需要审计跟踪的企业场景

auto mode 的每个拒绝都记录在 /permissions 的 Recently denied 标签下。可以用 PreToolUse hooks 和 PermissionDenied hooks 自定义审计逻辑，比如把所有拒绝写入 SIEM 或发送给安全团队。

踩过的坑

分类器不是完美的

17% 的误拒率意味着 auto 模式会阻止一些安全的操作。如果你的工作流重度依赖某个被误拒的模式，你需要在 autoMode.environment 或 autoMode.allow 中添加例外。但添加太多例外会削弱分类器的保护价值。

不要在生产环境用 bypassPermissions

—dangerously-skip-permissions 的命名不是吓人的。它完全禁用了所有权限提示和安全检查，包括对 .git、.claude、.vscode 等保护路径的写入。只有在隔离容器或 VM 中才应该使用。管理员可以通过 managed settings 完全禁用这个模式。

沙箱和权限是两个独立层次

很多人误以为开启了沙箱就不需要配置权限规则。事实上，沙箱只管控 Bash 命令，不管控 Read/Edit 工具。如果你只配置了 sandbox.denyRead 来保护 SSH 密钥，Claude 的 Read 工具仍然可以读取它。需要同时在两个层次配置相同的路径。

记得加 “$defaults”

如果你在 autoMode.allow、soft_deny 或 environment 中设置了自定义规则但忘记包含 “$defaults”，内置的所有规则都会被替换掉。这意味着 force push、数据泄露、curl | bash 等默认阻止规则全部失效。只有当你真的打算完全自己控制规则列表时才应该省略 “$defaults”。

配置示例

一个典型的团队级安全配置：

{
  "defaultMode": "auto",
  "autoMode": {
    "environment": [
      "\$defaults",
      "github.com/my-org",
      "s3://my-org-bucket"
    ],
    "hard_deny": [
      "\$defaults",
      "deploy to production",
      "modify production database",
      "access AWS credentials"
    ],
    "allow": [
      "\$defaults",
      "run tests in CI environment"
    ]
  },
  "permissions": {
    "deny": [
      "Bash(rm -rf /)",
      "Bash(rm -rf ~)",
      "Read(~/.ssh/*)",
      "Read(~/.aws/*)"
    ]
  }
}

# 查看当前生效的分类器配置
claude auto-mode config

# 查看内置默认规则
claude auto-mode defaults

# 让 AI 审查你的自定义规则
claude auto-mode critique

什么时候别用 auto 模式

• 你在操作含有金融数据、医疗记录或 PII 的代码库 — 分类器的 17% 误拒率不是唯一的问题，更大的风险是它可能错误地允许了某个不应该执行的操作
• 你的团队没有安全评审流程 — auto 模式不是无人监睬的免费通行证，它是一种需要配置和监睬的权限模型
• 你只是偶尔用一下 Claude Code — 对于短任务，default 或 acceptEdits 模式的审批负担完全可以接受

总结

Claude Code 2.1.136 的安全改动传达了一个清晰信号：AI agent 不再被视为可以“信任但验证”的工具，而是需要“验证再信任”的系统。security-test 的自动授权被移除是因为高风险操作不应该由任何自动化机制决定。hard_deny 的引入是因为有些边界不应该被用户意图覆盖。

这些改动的意义超出了 Claude Code 本身。它们是整个 AI agent 生态的警示灯：当 agent 被赋予越多自主性，安全模型必须同步收紧。否则我们得到的不是更高效的开发者，而是更多的安全事故。

你的 agent 是在一个有安全边界的沙箱里运行，还是在一个有全部权限的终端里自由行动？这个问题的答案决定了你能不能在生产环境里用它。

GitHub: https://github.com/anthropics/claude-code 文档: https://code.claude.com/docs/en/auto-mode-config