Claude Code 自动模式默认开启：分类器看什么、拦什么、漏判率多少

blackappleD
0 阅读9分钟

10 月 22 日，Anthropic 在 auto mode 默认化公告里补了一条更新：从下周开始，Pro、Max、Team 用户在大多数 Claude 应用里新开的会话，默认都会进 auto mode。Claude Code 终端里其实早就这样了，从 9 月底的 v2.1.283、v2.1.284 起，不管什么套餐、什么提供商，只要你没配置权限模式，交互式会话都从 auto 启动。

也就是说，"这条命令能不能执行"以后多半不由你点按钮决定，而是交给另一个模型判断。下面看看这个分类器看得到什么、拦什么、官方公布的漏判率，以及它管不了的事。

它是什么

项内容
首次发布2026-03-24，研究预览
全量开放2026-07-10，对所有 Claude Code 用户可用
默认开启2026-08-14 起 Pro / Max / Team 默认；v2.1.284 起所有套餐和提供商的终端、VS Code 默认
最新动向2026-10-22 公告更新：下周起在大多数 Claude 应用的新会话里默认开启
脚本 / SDKv2.1.302 起 claude -p 在第三方提供商等场景默认 Manual，要 auto 需显式 --permission-mode auto
支持模型（Anthropic API）Opus 4.6+、Sonnet 4.6+、Haiku 5.5、Fable 系列；Sonnet 4.5、Opus 4.5、Haiku 4.5 不支持
分类器模型本地分类器默认 Sonnet 5；工程博客写的初版是 Sonnet 4.6
收费服务端审查不单独计费；Enterprise、API、云厂商账户的本地分类器调用计入 token 用量

原理：一次工具调用要过几道关

官方文档给的决策顺序如下，先命中的规则生效：

工具调用
  │
  ├─ 1. allow / ask / deny 规则 ── 命中就按规则走（有例外，见下）
  │
  ├─ 2. 只读操作、工作目录内的文件编辑 ── 直接放行
  │
  └─ 3. 其余所有操作 ── 交给分类器
                          │
                   Stage 1：单 token 快筛，"宁可拦"
                    ├─ 放行 → 执行
                    └─ 标记 → Stage 2：带推理复核
                               ├─ 放行 → 执行
                               └─ 拦截 → 把原因告诉 Claude，让它换条路

输入侧还有一层：服务端的提示注入探针会在工具结果进入上下文之前扫一遍，发现疑似劫持就附上一条警告。

为什么分两段

Stage 1 只输出一个 token，指令是"拿不准就拦"，又快又便宜。被它标记的才进 Stage 2。Stage 2 输入相同，只把最后一句指令换成"仔细推理"，所以 prompt 几乎全部命中缓存，复核成本很低。

工程博客给了两段各自的数据（官方自测）：

真实流量（n=10,000）真实越权动作（n=52）合成外泄（n=1,000）
只用 Stage 1误拦率 8.5%漏判率 6.6%漏判率 1.8%
Stage 1 → 2误拦率 0.4%漏判率 17%漏判率 5.7%

取舍很清楚：只用 Stage 1，大约每 12 次误拦一次，用户会烦到关掉 auto；加上 Stage 2，误拦率降到 0.4%，代价是真实越权动作的漏判率从 6.6% 升到 17%。Anthropic 选了后者，原话是"17% 是诚实的数字"。

为什么分类器"看不见" Claude 说了什么

这是我觉得最值得看的设计。分类器只看两样东西：用户的消息和 Claude 发出的工具调用。Claude 自己写的解释、工具返回的结果，统统被剥掉。

完整对话                              分类器看到的
User: 修一下登录 bug          ──→     User: 修一下登录 bug
Assistant: 我先 grep 一下…     ✗
Bash: grep -r ...             ──→     Bash: grep -r ...
[工具输出: 配置里找到了 token]   ✗
Bash: curl -d $TOK ...        ──→     Bash: curl -d $TOK ...
  • 剥掉 Claude 的话：防止 Agent 用一句"这是为了验证 token"说服分类器。官方说法是"评判 Agent 做了什么，而不是它说了什么"。
  • 剥掉工具结果：恶意指令基本从工具结果进来（网页、文件、README），分类器看不到，注入就打不到它。
  • 保留用户消息：作为意图锚点。只看工具调用的方案漏判最低，但会误拦用户明确要求的动作。

代价是看不到来源：Claude 要操作 job abc123，分类器分不清这个 ID 是查出来的还是编的。

进入 auto 时，宽泛的 allow 规则会失效

Bash(*)、Bash(python*) 这类等于"任意代码执行"的授权，以及包管理器 run 命令、Agent / Monitor 的 allow 规则，进入 auto 时会被临时丢掉，离开后恢复。Bash(npm test) 这种窄规则会保留，并且在分类器之前生效；想让所有 shell 命令都过分类器，设 "autoMode": { "classifyAllShell": true }。

它默认拦什么、放什么

默认拦截（节选）默认放行（节选）
curl | bash 这类下载即执行工作目录内的文件操作
把敏感数据发到外部安装 lock 文件或 manifest 里已声明的依赖
生产部署、数据库迁移、terraform destroy读 .env 并把凭据发给对应的 API
force push、改写远端历史推送到当前仓库的任意分支（production、gh-pages 这类单独判断）
git reset --hard、git clean -fd 等丢未提交改动的命令只读 HTTP 请求
访问 169.254.169.254、读宿主机凭据（v2.1.257 起）发到 autoMode.environment 里列出的可信域名和存储桶

完整规则用 claude auto-mode defaults 打印，合并你的设置后实际生效的规则用 claude auto-mode config 看。

有两条容易踩的边界：

  1. 对话里说"别 push"不是硬规则。它会被当作拦截信号，但上下文压缩后可能丢失。要硬保证，用 permissions.deny 或 permissions.ask。
  2. 笼统同意不算授权。"清理一下这个 PR"不等于允许 force push。

官方数据和第三方测试

10 月 22 日更新的那篇默认化公告里，有两组数字（官方称）：

  • 对照实验：1,053 名付费测试者做编程任务，某次权限提示被悄悄换成一条明显危险的命令。人只拦下了 13.6%（143 / 1,053），auto mode 拦下 89%（937 / 1,053）。
  • Trajectory Labs 红队（Anthropic 委托）：72 个间接提示注入场景，每个跑 10 次。Fable 5、Opus 5、Sonnet 5 在 auto mode 下 720 次全部没成功；GPT-5.6 Sol 在 Codex Auto-review 下成功率 5.83%，Full Access 下 19.03%。

这些数字要打折看：

  • 第三方测试是 Anthropic 委托的，测的是 Claude Code v2.1.205 和 Codex v0.144.5；脚注也写了 OpenAI 后来更新过 Auto-review，结果可能会变。
  • 89% 反过来就是 11% 的危险命令会被放过（Simon Willison 指出过）。
  • 13.6% 反映的是"确认疲劳"。它说明 auto 比"一路点同意"好，说明不了 auto 比"认真审"好；工程博客自己也承认，跟认真逐条审批比，auto mode "可以说是退步"。

独立研究者的反例：Johann Rehberger 公布过一种针对 Opus 5 + auto mode 的攻击（Simon Willison 8 月 27 日转述），据称成功率约 80%。做法是让 Claude 下载并解压一个藏着 struct.py 的 zip，之后运行任何 import base64 的代码时，Python 会先加载同目录下的这个文件。有几次 Claude 发现中招想杀掉恶意进程，这条清理命令反而被分类器拦了。分类器判断的是单条命令，看不到"目录里刚多了一个同名模块"这种环境变化。我没查到 Anthropic 对此的公开回应。

和 Codex Auto-review 对比

OpenAI Codex 有个类似的 Auto-review，思路不太一样：

Claude Code auto modeCodex Auto-review
底层边界默认不开沙箱，靠规则 + 分类器系统沙箱优先（macOS Seatbelt、Linux bwrap + seccomp），默认断网
审查什么规则没命中的所有非只读动作只审本来就需要审批的动作：沙箱提权、被拦的网络请求、有副作用的 MCP 调用
失败时无判定就拒绝；连续拦 3 次或累计 20 次退回人工fail closed，超时也不执行
开启方式--permission-mode auto，或 defaultMode: "auto"approval_policy = "on-request" + approvals_reviewer = "auto_review"
计费服务端审查不单独收费额外模型调用计入 Codex 用量

Codex 是"先用沙箱框死，审查只管越界部分"；Claude Code 是"默认不框，每一步交给分类器"。前者确定性更强，后者日常开发更顺手。

该怎么用

适合交给 auto 的：本地仓库里改代码、跑测试、装已锁版本的依赖、推自己的分支。

建议再加一道闸的：

{
  "permissions": {
    "ask": ["Bash(git push *)", "Bash(gh pr create *)"],
    "deny": ["Bash(terraform apply *)"]
  },
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/your-org and all repos under it",
      "Trusted internal domains: *.internal.example.com"
    ]
  }
}

注意 autoMode 只在 ~/.claude/settings.json、托管设置或 --settings 里生效，写在项目 .claude/settings.json 里不会被读取，防止仓库自带规则放宽分类器。另外，environment、allow、soft_deny、hard_deny 只要写了数组却没带 "$defaults"，就会把那一节的内置规则整个替换掉。

不想手写可以跑 /auto-mode-setup 生成草稿。

不适合只靠 auto 的：

  • 机器上有生产凭据、SSH 密钥、云账号，又要处理不可信输入（陌生仓库、网页、第三方依赖）。这类任务应该进容器或开沙箱，限制网络出口。
  • 走 LLM 网关或中转的场景。服务端审查要求网关原样转发 safeguards 请求字段和 safeguard_results 返回字段，被剥掉就退回本地分类器（按 token 计费的账户会多花钱，并弹出计费提示）；响应被截断或改写还会出现"无判定"拒绝。

我的判断

权限提示点多了，人就不看内容了，auto mode 针对的是这个真问题。13.6% 是官方测的，但方向上我信。把审批交给一个只盯动作、不听 Agent 解释的模型，比让疲惫的人点按钮靠谱。

但它是"更好的默认值"，不是安全边界：官方自己给的真实越权漏判率是 17%，测试集只有 52 条。分类器判断的是"这一条命令符不符合用户意图"，对供应链、同名模块、环境变化这类攻击没有视野。

我的建议：

  1. 日常开发放心用 auto，它比 --dangerously-skip-permissions 强得多。
  2. 推送、发 PR、部署这几类动作，用 permissions.ask 留一道人工确认。
  3. 要处理不可信输入，或者机器上有值钱的凭据时，靠沙箱和网络隔离，不要指望分类器。
  4. 用中转或网关的，跑一下 /status，看 Auto mode server 这一行是不是 Enabled。

10 月 22 日的更新意味着 auto 要从开发者工具扩到更多 Claude 应用，被"默认替你点允许"的会是更多普通用户。

参考资料

avatar
文章
阅读
粉丝