Claude 应用下周起默认 auto mode，89% 拦截率仅适用于 Claude Code
Anthropic 10 月 22 日宣布下周起多数 Claude 应用默认 auto mode，可切回手动；89% 拦截率仅适用于 Claude Code。
Anthropic 在 10 月 22 日给一篇 8 月 7 日发布的博文补了一段更新：下周起，auto mode 成为「多数 Claude 应用」（most Claude apps）新会话的默认权限模式，覆盖 Pro、Max 与 Team 三档订阅。auto mode 是 Claude Code 今年 3 月开始测试的权限机制，把用户逐条点击批准换成一次自动检查，判定安全的动作直接执行，判定有风险的动作拦下，由 Claude 另找路径。同一篇博文写明，文中列出的实验数据只适用于 Claude Code。
要点
- 时间与范围：10 月 22 日宣布，下周生效。官方原文写「most Claude apps」，没有逐个点名网页、桌面或移动端；Pro、Max、Team 新会话默认开启，用户可随时切回手动，企业管理员会在默认生效前收到邮件。
- 一对数字：博文自述 1,053 名付费测试者中，人工复核只拦下 143 条危险命令（13.6%），auto mode 拦下 937 条（89%）。这组数据被明确限定在 Claude Code，不能直接外推到应用端。
- 缺的那一格：博文给了漏检率（Apollo Research 加固后从 12% 降到 7%）和有害动作发生率（生产严重度 7 以上，人工 6.3% 对 auto mode 2.4%），没有公布任何误报率。
变更内容
auto mode 的默认化改的是新会话的起点。此前 Claude 应用里每个工具调用要弹一次批准；切到 auto mode 后，一次自动检查先看这个动作，判定安全就直接执行，判定有风险就拦下，Claude 收到结果后换一条路径继续。用户想回到逐条批准，官方说随时可以切回手动。
Claude Code 那边的手动切换路径是现成的：命令行里按 Shift+Tab，桌面应用用模式下拉框。博文只把这两个入口写在 Claude Code 的段落里，应用端的切换控件没有单独说明。管理员侧有两个托管设置项，defaultMode 设组织默认模式，disableAutoMode 直接关掉 auto mode。
安全阀也有具体阈值：连续 3 次拦截，或一次会话里累计 20 次拦截，Claude Code 会把控制权交回用户。这条同样写在 Claude Code 的段落，应用端是否沿用同一阈值，博文没说。
企业客户不在这一批里。原文写「Enterprise admins will get an email before auto mode becomes the default」，先发邮件再改默认。Claude Enterprise、Claude API、AWS 上的 Claude Platform、Amazon Bedrock、Google Cloud 的 Agent Platform 和 Microsoft Foundry 目前仍是可选，官方称计划「in the coming month」把默认打开。
口径还有一个细节：Anthropic 官方 X 账号在 10 月 22 日同一时间的帖子里写的是「sessions across Claude web, desktop, and mobile apps」，比博文的「most Claude apps」更具体。两处指向同一批变更，博文正文没有点名三个端，成稿时以博文为准。
背景
auto mode 在 10 月之前就已上线。TechCrunch 的 Anthony Ha 在 8 月 9 日报道，Anthropic 今年 3 月先放出了测试版；8 月 7 日的博文宣布 Claude Code 从 8 月 14 日起对 Pro、Max、Team 默认开启。同一篇博文说，分类器每个工具调用多花几个 token，这笔开销 Anthropic 从 8 月 7 日起不再向这三档用户收取。
推动默认化的是审批疲劳的实测数字。博文写 Claude Code 用户批准了 97% 的权限提示，单条请求的拒绝率只有 3%，计划级批准被拒的比例是 39%。截至 2026 年 6 月，49.5% 的活跃 CLI 用户建过 Bash 允许规则，其中 5% 允许任意 shell 命令，43% 写了 Bash(python:*) 这类解释器规则；62% 用过 bypassPermissions 或在 Bash 上点过「不再询问」，25% 的交互会话一开场就处在绕过模式。
这套设计与 Claude Duet 的方向相反。Duet 把动作分成必须逐个批准的几类，另设硬禁区；auto mode 把默认权限交出去，只在判定有风险时拦。同一个公司，两套相反的默认值，取决于任务跑在你的眼皮底下还是云端。
数据边界
数据边界是这条新闻最容易被写错的地方。博文在 10 月 22 日更新之后紧跟着一句「The data in this article below is specifically for Claude Code」，把 89%、13.6%、97% 这些数字全部圈在 Claude Code 里。应用端是否复用同一套分类器，官方没有说明，也没有给应用端的任何测试数据。
实验本身的设计值得看清。1,053 名付费专业测试者由第三方研究供应商招募，在测试环境里干活；他们知道自己正在被评测，但按标准盲测设计，不知道被测的是哪一个行为；研究者把其中一个权限提示换成一条明显危险的命令，实际没有任何危险操作被执行。头对头的结果是：auto mode 拦下了 800 条人工放行的命令，人工只拦下 6 条 auto mode 放行的命令。人工的表现在会话早期是约 17%，超过 50 轮之后掉到约 5%，auto mode 的拦截率不随会话长度变化。
| 指标 | 人工复核 | auto mode |
|---|---|---|
| 危险命令拦截（1,053 条） | 143 条，13.6% | 937 条，89% |
| 交叉比对 | 放行 800 条 auto mode 拦下的命令 | 放行 6 条人工拦下的命令 |
| 会话早期检出率 | 约 17% | 未给，且不随会话变长衰减 |
| 50 轮以后检出率 | 约 5% | 同上 |
| 生产环境有害动作占比（严重度 7 以上） | 6.3% | 2.4% |
| 对抗攻击漏检率（Apollo 加固后） | 未测 | 12% 降到 7% |
| 误报率 | 未公布 | 未公布 |
误报率完全缺席。博文没有给任何「安全动作被误拦」的比例。Gusto 的口径是「自 5 月中起约 10% 的会话出现分类器拒绝」，这是拒绝率，与误报率不是一回事，不能混用。
第三方加固的数字来自 Apollo Research：两周红队演练，往真实编码轨迹里注入合成攻击，覆盖三个数据集。加固之后，auto mode 抓回了此前漏掉攻击的约一半，同时新漏掉约 2% 此前能抓到的；共享与留出攻击集上，漏检率从 12% 降到 7%。Trajectory Labs 测的是间接提示注入，72 个场景各跑 10 次共 720 次尝试，用 Claude Code v2.1.205 与 Codex v0.144.5（截至 2026 年 7 月 17 日的版本）：auto mode 下 Claude Fable 5、Opus 5、Sonnet 5 没有被攻破，Codex 全权限模式的成功率是 19.03%，auto-review 模式是 5.83%。这类外部演练今年在别处也出现过，METR 与 Redwood 在 OpenAI 内部的监控评估里找到多条绕过路径（我们 10 月 22 日的报道）。
各方说法
8 月那轮 Claude Code 默认化报道很多，The Register、InfoWorld、Mashable、Inc.com 等都写过；10 月这次应用端扩张则没有第二家跟进。我们按 Google News 检索核对：8 月条目数十条，10 月只有三条，且分别讲 Claude Duet、Claude 接入 Gemini 和 Sonnet 5.5 降价，与 auto mode 无关。所以 8 月可以说多家报道，10 月这次不行。
TechCrunch 的 Anthony Ha（8 月 9 日）基本照官方口径写：8 月 14 日生效、89% 对 13.6%、97% 的批准率，并引了 Claude Code 负责人 Boris Cherny 的一句「I couldn’t imagine going back to permission prompts!」。他没有质疑实验设计，也没有提误报率。
The New Stack 的 Frederic Lardinois（8 月 7 日）给了本期最实在的保留：auto mode「is a classifier, not a guarantee — it reduces risk, it doesn’t eliminate it」，生产基础设施仍然建议留一个人在环里。他点出这是厂商委托的评测，也披露了 TNS 母公司 Insight Partners 同时投资 OpenAI 与 Anthropic。这组对比博文自己就写了：全权限 19.03%、auto-review 5.83%；Lardinois 复述为 19% 与「just under 6%」。
两位作者都注意到 89% 与 13.6% 的对照，两篇都没有追问应用端会不会用同一套分类器。这个问题在 10 月之后才变得重要。
编辑判断
对每天把长任务丢给 Claude 的人，这次改的是新会话的起点。能力没有变，变的是你不再被逐条询问。剩下要决定的是哪些操作必须留在手动：生产环境的写操作、凭证读取、对外发送这三类，值得在动手前先想清楚要不要交给自动检查。博文没有展开应用端的细粒度控制，给出的管理开关只有 defaultMode 与 disableAutoMode，前者设默认，后者整个关掉；批量收紧某几类动作的能力，应用端是否具备，官方没有写。
最大的未知项在应用端。89% 来自 Claude Code 的命令行场景；Claude 应用面对的是一整段对话、文件上传和连接器调用，攻击面不一样。官方没有说应用端复用同一套分类器，也没有给应用端的误报率。打算把无人值守任务搬进 Claude 应用的人，可以等下周实际生效后自己测一轮：拿几条已知危险的命令和几个正常的大文件操作各跑一遍，看拦不拦、误不误拦，再决定把哪些权限交给它。
对企业管理员，邮件只说明默认值要改。defaultMode 与 disableAutoMode 两个开关在托管设置里，先把组织默认值定下来，再等应用端的分类器文档补齐。Anthropic 10 月 15 日公开过 Claude Code 团队的七层评审流程（我们的报道），那套流程审的是代码；auto mode 管的是执行前的权限，两者在不同的环节上。