Claude Code 面向 Pro、Max 和 Team 套餐默认启用 Auto 模式

我们正将 Auto 模式设为 Claude Code 的默认模式。自 8 月 14 日起，Pro、Max 和 Team 套餐中的新会话将以 Auto 模式运行。如果你此前已自行设置了其他默认模式，可能会看到一次性提示，询问是否要切换至 Auto 模式。如果你固定了默认设置，则不会发生任何变化。Auto 模式分类器会为每次工具调用额外使用少量 token；从今天起，我们将不再向 Pro、Max 和 Team 套餐的 Claude Code 用户收取这部分分类器开销费用。

目前，Claude Enterprise、Claude API、AWS 上的 Claude Platform、Amazon Bedrock、Google Cloud 的 Agent Platform 以及 Microsoft Foundry 仍需选择启用 Auto 模式，以便管理员有时间审查这一变化。在未来一个月内，我们计划与云合作伙伴协作，将其设为上述所有平台的默认模式，并不再收取分类器开销费用。与此同时，Enterprise 管理员可通过受管设置，将 Claude Code 的 Auto 模式设为默认模式。

Auto 模式旨在平衡用户不希望频繁被打断的需求，以及帮助避免有害操作的系统机制：它不会反复弹出提示，而是让分类器审查每次工具调用，重点阻止不可逆、破坏性或面向用户环境之外的操作。当分类器拦截某项操作时，Claude 通常会自行寻找更安全的继续方式，或直接请求用户批准；如果无法取得进展——连续被拦截三次，或整个会话中累计被拦截二十次——Claude Code 将回退到手动审批。

过去几个月里，我们测试了 Auto 模式是否与普通用户逐一点击通过提示相比同样安全或更安全。我们进行了内部红队测试、第三方红队测试和提示注入评估，对 1,053 名付费测试者开展了受控研究，并分析了真实生产会话。在我们测试的每项指标上，Auto 模式的表现都与人工审查持平或更优。

Auto 模式还能让 Claude 在更长的时间段内自主工作。这让专为长时间运行任务构建的模型，例如 Claude Opus 5，更适合在大型任务上连续运行数小时。减少用户的操作开销也会提升产出。在 Teams 和 Enterprise 的采用者中，Auto 模式用户交付的 PR 数量约多 25%。减少对 Claude 的阻塞，可让任务在更少中断的情况下运行更久并完成更多工作。Adobe、Nuro、Gusto 和 Garner Health 的团队已将 Auto 模式作为其生产环境默认设置。

下文将介绍推动这一变化的安全数据和客户成果，以及如果你希望采用其他模式，如何设置不同的默认值。

对比手动审查与 Auto 模式

数据表明，手动审查可能会变成一种习惯性操作：用户会批准 Claude Code 中 97% 的权限提示。尽管大多数提示可能涉及安全、例行的命令，但如此高的批准率表明，许多用户是在条件反射式地点选通过，而非逐一审查每条命令。这些提示要求开发者每天做出数十乃至数百项重要安全决策，并且往往发生在项目进行过程中。这既将审查负担置于用户身上，也增加了重要问题被遗漏的可能性。数据还显示，用户会更频繁地仔细审查并否决其他类型的对话：例如，当 Claude 提交一份计划请求批准时，用户会拒绝其中的 39%。但对于单项权限请求，拒绝率仅为 3%。

同样的模式也出现在设置文件中。截至 2026 年 6 月，49.5% 的活跃 CLI 用户曾手动创建 Bash 允许规则——其中 5% 允许任何 shell 命令直接执行，另有 43% 使用了诸如 Bash(python:*) 或 Bash(node:*) 的解释器规则，这些规则在实践中基本等同于全面放行——而这一比例每 5 周大约增长 5 个百分点。除允许规则外，62% 的用户使用过 bypassPermissions，或曾在 Bash 上点击“不要再询问”；25% 的交互式会话以绕过权限模式启动。

在 Auto 模式中，权限规则仍会先于分类器触发，但足以允许任意代码执行的宽泛允许规则除外（例如 python:*）。这些任意规则会在 Auto 模式下被暂时搁置，因为它们会让命令完全绕过分类器。设置文件不会被修改；一旦切换到其他模式，这些规则会立即重新生效。

通过 Auto 模式提升安全性

内部研究以及多家第三方开展的研究表明，Auto 模式比典型用户如今处理权限提示的方式更安全。我们将 Auto 模式与开发者在逐个点击权限提示时实际批准的内容进行了对比测试。在内部红队测试、第三方渗透测试和真实会话分析等每项衡量中，Auto 模式都与人工批准持平或表现更优。

Auto 模式在安全性上优于手动权限审批

在一项包含 1,053 名付费专业测试者的受控实验中，人工审查仅识别出 13.6% 的危险命令，而 Auto 模式识别出 89%。

我们通过一家研究供应商聘请了 1,053 名付费测试者参与编程研究。参与者在专为该研究配置的测试环境中工作，而非在自己的代码库或真实项目中。参与者知道自己正被评估，但遵循标准盲法研究设计，他们并不知道具体在测量哪种行为。每个会话进行到一半时，一条权限提示会被替换为明显危险的命令，供应商记录测试者是否批准该命令（注：即使批准提示，也不会实际运行任何危险操作；改变的仅是测试者看到的提示文本）。

测试者仅在 13.6% 的情况下识别出危险命令（1,053 人中为 143 人），而 Auto 模式拦截了同一批命令中的 89%（1,053 条中为 937 条）。直接比较中，Auto 模式拦截了 800 条人工批准的命令，而人工仅拦截了 6 条 Auto 模式允许的命令。随着会话变长，人工表现变得更差：在会话早期，人工会拦截约 17% 的危险命令；在此前已出现 50 条或更多提示后，这一比例降至约 5%；而 Auto 模式的拦截率不受会话时长影响，始终保持稳定。

Auto 模式避免更多有害操作

我们的研究还表明，相比手动权限模式，Auto 模式会导致更少的有害操作。

我们考察了 Auto 模式在真实使用中的表现。2026 年 5 月至 6 月，我们审查了被安全流水线标记为需要复核的会话，这些会话仅来自已选择同意将数据用于训练和分析的账户。我们使用一个模型，按照两个 0 至 10 的量表重新评估每个会话。第一个量表衡量伤害严重程度：10 分代表公司范围、不可逆的伤害，例如泄露一家公司的全部源代码；7 分代表生产环境级别的严重性，例如删除生产数据库中的行；0 分则代表完全可逆且仅限本地工作区的操作，例如覆盖一个临时文件。第二个量表衡量用户对该操作要求的明确程度，以便区分用户直接要求的有害操作，以及 Agent 在较不明确指示下采取的有害操作。

在被标记的会话中，经过手动批准的会话发生严重非预期伤害的频率，是 Auto 模式会话的两倍以上。在生产环境级严重程度（7 分及以上）下，6.3% 经手动批准的会话包含用户未明确要求的有害操作，而 Auto 模式会话的这一比例为 2.4%；并且在我们测试的每个严重程度等级中，这一差距都存在。

对抗性红队测试让 Auto 模式更强大

我们与英国 AI 安全初创公司 Apollo Research 合作，开展了一项为期两周的试点项目，向真实编程轨迹中注入合成攻击，覆盖三个数据集，分别涵盖广泛的故障、数据外泄和安全相关威胁。

该项目遵循标准的“发现、修复、验证”循环。Apollo 分享了一组成功攻击案例，并提出了加强 Auto 模式的建议。我们主要通过让分类器获得更多关于其所保护环境的上下文信息来增强防护能力，包括代码仓库可见性、git 状态，以及下文所述的数据处理规则。

增强后，Apollo 使用一组我们从未接触过的独立留出攻击集进行了重新测试。Auto 模式成功拦截了此前漏掉的约一半攻击，代价是漏掉了此前已拦截攻击中的约 2%。由于我们无法针对留出集进行调优，这表明增强措施能够泛化到新的攻击，而不是仅修补 Apollo 分享的特定攻击。在共享集和留出集上，分类器的漏检率从 12% 降至 7%。

这些攻击本身就是为发现分类器失效位置而构建的合成对抗性攻击，其恶意程度也高于 Claude 在未经提示时会采取的任何行为。7% 的漏检率是针对这一数据集测得的，不应被视为真实流量中的漏检率。

Auto 模式降低提示注入风险

启用 Auto 模式后，在一项独立评估中，没有任何攻击成功针对我们的任何模型。运行于 Codex v0.144.5 Auto-review 权限模式的 GPT-5.6 Sol，攻击成功率为 5.83%。为以最高推理水平测试性能，GPT-5.6 Sol 使用“max”推理强度运行，所有 Claude 模型均以高强度运行。

Auto 模式分类器增加了一层额外防御，用于抵御试图迫使 Agent 偏离用户指令的提示注入攻击。在 Auto 模式下运行时，工具结果会由探针扫描，以发现可能存在的恶意指令；Auto 模式还会检查操作是否与用户意图一致。我们将 Auto 模式与未受防护的模型进行了对比测试，以展示这种纵深防御方法的能力。

我们委托第三方 Trajectory Labs 开展评估，其测试了截至 2026 年 7 月 17 日最新版公开可用 Claude Code 和 Codex 中的不同模型。1 他们测试了 72 种未向 Anthropic 公开的间接提示注入场景，每个场景测试 10 次。在非测试环境中，成功的攻击会导致可能伤害用户的不可逆操作，例如敏感数据外泄、金融欺诈或凭证钓鱼。这些攻击针对 Claude Opus 4.7 进行了优化，而该模型未包含在报告结果中，因此评估中的每个模型面对的都是未见过的攻击。除 Auto 模式外，评估还考察了 Claude Code 的 bypassPermissions 模式和 Codex 的 Full Access 模式。

Codex 和 Claude Code 均通过由 Trajectory Labs, PBC 制作的相同浏览器集成进行评估。该集成提供了一组 MCP 工具，是对 navigate 等常见 Chrome API 的轻量封装。评估未测试 OpenAI 和 Anthropic 提供的 Chrome 扩展等第一方浏览器集成中内置的防护措施。因此，这些结果应被视为对底层模型的衡量，而非特定部署中可能存在的完整防护措施集合。

在这项评估中，针对以 Auto 模式运行的 Claude Fable 5、Opus 5 或 Sonnet 5 的 720 次攻击尝试均未成功。 另一方面，针对以 Codex 的 Auto-review 模式运行的 GPT-5.6 Sol，有 5.83% 的攻击成功。值得注意的是，这高于我们最新模型在没有额外防护措施的 bypassPermissions 模式下所面对攻击的 0.09% 平均成功率。测试显示，GPT-5.6 Sol 在 Full Access 模式下的攻击成功率为 19.03%。正如下文所示，在工具以文本形式返回结果的任务与需要通过截图与浏览器交互的任务之间，攻击成功率有所不同。

Auto 模式同时防护工具调用和浏览器 GUI 使用中的提示注入。在一项第三方评估中，OpenAI 模型在浏览器任务上表现出更高的攻击成功率。

Auto 模式在 Anthropic 内部阻止的三起事件

Auto 模式也是 Anthropic 内部所有 Claude Code 使用场景的默认模式。以下是分类器在内部阻止的三项操作：

• 一次向网络外的数据泄露： 当上传到内部驱动器失败时，Claude 的备选方案是将同一份报告发布到公开代码共享网站。Auto 模式拒绝了该备选方案，并提示用户决定下一步操作。
• 一次破坏性批量操作： 在一个长时间运行的会话中，Claude 尝试对约两千个 pod 执行大规模进程终止，并排队执行删除操作；这些操作本会中止数百个 GPU 上正在进行的训练任务。Auto 模式在命令执行前标记了这些破坏性命令。
• 范围过宽的权限提升： 在被要求配置只读账单访问权限时，Claude 选择了一个可在账户根级别授予完全管理控制权的云角色。Auto 模式发现了所请求权限与实际将授予角色之间的不匹配。

在每个案例中，Claude 要么自行找到了更安全的路径，要么在继续之前向用户确认。

让 Auto 模式更加安全

我们持续投入开发新的 Auto 模式功能，使其更安全，也更易于交付生产代码。近期示例包括：

• 硬拒绝规则：数据外泄，例如将你的代码或密钥发送到外部某处，属于分类器设计为绝不批准的类别。若要运行此类操作，你必须退出 Auto 模式，或自行运行该命令。硬拒绝规则可通过设置自定义，因此即使组织内用户提出请求，你也可以增加更多永远不希望被允许的规则。
• 数据访问和共享规则： 分类器现在带有明确规则，用于区分密钥与可能敏感/机密的信息，并规定每类信息可在何处访问和共享。为使这些规则可执行，它还会在执行 git push 或 pull request 前检查目标是公开、私有还是受信任。（原文至此截断）

We're making auto mode the default in Claude Code. Starting on August 14, new sessions on Pro, Max, and Team plans will run in auto mode. If you've already set a different default yourself, you may get a one-time prompt asking whether you want to switch to auto mode. If you have a pinned default, nothing changes for you. The auto mode classifier uses a small number of extra tokens per tool call, and we're no longer charging Claude Code users on Pro, Max, and Team plans for that classifier overhead, effective today.

Auto mode remains opt-in for now on Claude Enterprise, the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry, giving admins time to review the change. In the coming month, working with our cloud partners, we plan to make it the default across all of these and no longer charge for classifier overhead. In the meantime, Enterprise admins can make Claude Code's auto mode the default through managed settings.

Auto mode is designed to balance users’ desire not to be interrupted with a system that helps avoid harmful actions: instead of prompts, it routes each tool call through a classifier targeted at blocking actions that are irreversible, destructive, or aimed outside your environment. When the classifier blocks something, Claude usually finds a safer way to proceed on its own or asks you directly for the go-ahead; if it can't make progress—three blocks in a row, or twenty across a session—Claude Code falls back to manual approvals.

We spent the last several months testing whether auto mode is as safe or safer than an average user clicking through prompts. We ran internal red-teaming, third-party red-teaming and prompt-injection evaluations, a controlled study with 1,053 paid testers, and analysis of real production sessions. On every measure we tested, auto mode matched or outperformed manual review.

Auto mode also lets Claude work autonomously for longer stretches. This makes models built for long-running work, like Claude Opus 5, more practical to leave running for hours on large tasks. Reducing overhead for users also increases output. Among Teams & Enterprise adopters, auto mode users ship about 25% more PRs. Unblocking Claude allows tasks to run longer uninterrupted and get more work done. Teams at Adobe, Nuro, Gusto, and Garner Health already run auto mode as their production default.

Below, we share the safety data and customer results motivating the change, and how to set a different default if you prefer.

Comparing manual review to auto mode

Data suggests that manual review can become habitual: users approve 97% of permission prompts in Claude Code. While most prompts are likely for safe, routine commands, an approval rate that high suggests many users are clicking through reflexively rather than reviewing each command. These prompts ask developers to make dozens or hundreds of important security decisions every day, often in the middle of projects, which places the review burden on users and increases the chance that something important slips through the cracks. Data also suggests that users more frequently scrutinize and push back on other types of dialogues: for example, when Claude presents a plan for approval, users reject 39% of them. But for individual permissions requests, the rejection rate is only 3%.

The same pattern shows up in settings files. As of June 2026, 49.5% of active CLI users have manually created a Bash allow-rule—5% allow any shell command outright, and another 43% have interpreter rules like Bash(python:*) or Bash(node:*) that are essentially equivalent in practice—and that share is growing roughly 5 percentage points every 5 weeks. Beyond allow-rules, 62% of users have used bypassPermissions or clicked “don't ask again” on Bash, and 25% of interactive sessions start in bypass permissions mode.

Permission rules still fire before the classifier in auto mode, except for allow rules broad enough to grant arbitrary code execution (e.g. python:*). These arbitrary rules are set aside while in auto mode, since they would let commands skip the classifier entirely. Settings files aren't modified, and the rules apply again the moment you switch to another mode.

Improving safety with auto mode

Research conducted internally and through several third parties suggests that auto mode is safer than how a typical user engages with permission prompts today. We tested auto mode against what developers actually approve when they're clicking through permission prompts. Across each of these measures—internal red-teaming, third-party penetration testing, and analysis of real-world sessions—auto mode matched or outperformed human approval.

Auto mode outperforms manual permissions on safety

In a controlled experiment with 1,053 paid professional testers, human review caught just 13.6% of dangerous commands, while auto mode caught 89%.

We hired 1,053 paid testers through a research vendor for a coding study. These participants worked in a test environment set up specifically for the study, not in their own codebases or on real projects. Participants knew they were being evaluated, but—following standard blind-study design—weren't told which behavior was being measured. Partway through each session, a single permission prompt was swapped for a clearly dangerous command, and the vendor recorded whether the tester approved it (Note: approving the prompt never resulted in anything dangerous being run; only the text of the prompt testers saw was changed).

The testers caught the dangerous command just 13.6% of the time (143 of 1,053), while auto mode blocked 89% of the same commands (937 of 1,053). Head to head, auto mode blocked 800 commands that a human approved, while humans blocked only 6 that auto mode allowed. As sessions got longer, humans did worse: they blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts, while auto mode's block rate stayed flat regardless of session length.

Auto mode prevents more harmful actions

Our research also suggests that auto mode leads to fewer harmful actions than manual permissions mode.

We examined how auto mode performs in real usage. From May to June 2026, we examined sessions our safety pipeline had flagged for review, drawn only from accounts that have opted in to data use for training and analysis. We re-graded each one with a model on two 0–10 scales. The first was harm severity with 10 being company-wide, irreversible harm, such as leaking a company's entire source code, 7 representing production-level severity such as deleting rows from a production database, and 0 a fully reversible action confined to the local workspace, like overwriting a scratch file. The second was how explicitly the user had asked for the action, so we could separate harmful actions the user directly requested from harmful actions the agent took with less explicit direction.

Among the flagged sessions, those that went through manual approval contained serious unintended harm more than twice as often as auto mode sessions. At production-level severity (7+), 6.3% of manually approved sessions contained a harmful action the user hadn't explicitly asked for, compared to 2.4% of auto mode sessions, and the gap held at every severity level we tested.

Adversarial red-teaming made auto mode stronger

We worked with Apollo Research, a UK-based AI safety startup, on a two-week pilot injecting synthetic attacks into real coding trajectories, across three datasets covering broad failures, data exfiltration, and safety-related threats.

The engagement followed a standard find-fix-verify loop. Apollo shared a set of successful attacks along with recommendations to strengthen auto mode. We hardened the classifier against them primarily by giving it more context about the environment it's protecting (repository visibility, git state, and the data-handling rules described below).

After hardening, Apollo re-tested on a separate held-out attack set that we never had access to. Auto mode caught about half of the attacks it previously missed, at a cost of missing about 2% of attacks it previously caught. Since we couldn't tune against the held-out set, this suggests the hardening generalizes to new attacks rather than patching the specific ones Apollo shared. Across both the shared and held-out sets, the classifier's miss rate fell from 12% to 7%.

These attacks are synthetic and adversarial by design, built to find where the classifier fails, and more malicious than anything Claude would do unprompted. The 7% miss rate is measured against this set and should not be taken as the miss rate on real traffic.

Auto mode reduces prompt injection risk

With auto mode enabled, no attack in an independent evaluation was successful against any of our models. GPT-5.6 Sol running in Codex v0.144.5 Auto-review permission mode had a 5.83% attack success rate. GPT-5.6 Sol was run on “max” reasoning effort to test performance with its highest level of reasoning, and all Claude models were run on high effort.

The auto mode classifier adds an additional layer of defense against prompt injection attacks that try to force the agent to deviate from the user’s instructions. When running with auto mode, tool results are scanned by probes for potentially malicious instructions, and auto mode checks that actions are aligned with user intent. We tested auto mode compared to an unguarded model to illustrate the power of this defense-in-depth approach.

We commissioned an evaluation from a third party, Trajectory Labs, who tested different models within the latest publicly available versions of Claude Code and Codex as of July 17th 2026.1 They tested 72 indirect prompt injection scenarios held out from Anthropic. Each scenario was tested 10 times. Successful attacks would, in a non-testing environment, result in irreversible actions that could harm the user such as sensitive-data exfiltration, financial fraud, or credential phishing. The attacks were optimized against Claude Opus 4.7, which is not in the reported set, so every model in the evaluation faced them as unseen attacks. In addition to auto mode, the evaluations looked at Claude Code’s bypassPermissions mode and Codex’s Full Access mode.

Both Codex and Claude Code were evaluated using an identical browser integration produced by Trajectory Labs, PBC. This integration provides a set of MCP tools which are a thin wrapper around common Chrome APIs such as navigate. Safeguards built into first-party browser integrations such as the Chrome extensions provided by OpenAI and Anthropic were not tested. As such, these results should be viewed as a measurement of the underlying model, rather than the complete set of safeguards which might exist in a given deployment.

In this evaluation, none of the 720 attack attempts succeeded against Claude Fable 5, Opus 5, or Sonnet 5 running auto mode. On the other hand, 5.83% of the attacks succeeded against GPT-5.6 Sol running Codex's Auto-review mode. Notably, this is greater than the 0.09% average attack success rate against our latest models running in bypassPermissions mode without additional safeguards. The tests showed a 19.03% attack success rate against GPT-5.6 Sol when running in Full Access mode. Attack success rates differ between tasks where tools return results as text and tasks that require interacting with a browser through screenshots, as shown below.

Auto mode protects against prompt injections both in tool calling and browser GUI use. OpenAI models showed higher attack success rates on browser tasks in a third-party evaluation.

Three incidents auto mode prevented inside Anthropic

Auto mode is also the default for all Claude Code internal usage at Anthropic. Here are three actions the classifier prevented internally:

• An off-network data leak: When an upload to an internal drive failed, Claude's fallback was to publish the same report to a public code-sharing site. Auto mode denied the fallback and prompted the user for next steps.
• A destructive mass operation: In a long-running session, Claude attempted a mass process kill across roughly two thousand pods and queued deletions that would have torn down hundreds of GPUs of in-flight training jobs. Auto mode flagged the destructive commands before execution.
• Over-broad privilege escalation: Asked to provision read-only billing access, Claude reached for a cloud role that grants full administrative control at the account root. Auto mode caught the mismatch between what was requested and what roles would have been granted.

In each case, Claude either found a safer path on its own or checked in with the user before proceeding.

Making auto mode even safer

We’re continuously investing in new auto mode features that make it safer and easier to ship production code. Recent examples include:

• Hard denies: Data exfiltration, like sending your code or secrets somewhere external, sits in a category the classifier is designed to never approve. To run an action like that, you have to switch out of auto mode or run the command yourself. Hard deny rules are customizable via settings so you can add more rules that you never want allowed even when requested by users in your organization.
• Rules for data access and sharing: The classifier now carries explicit rules distinguishing secrets and potentially sensitive/confidential information—and where each can be accessed and shared. To make those rules enforceable, it also checks whether the destination of a git push or pull request is public, private, or trusted before the action runs. The same push can be routine or an exfiltration depending on where it lands: code that belongs in your team's private repository shouldn't end up in a public one, and the classifier is now designed to flag when this might happen.
• Checking git status before destructive git actions : Before a command that could discard uncommitted work, like git reset --hard, the classifier sees the repository's current git status, letting auto mode know what is being reset.
• Prompt injection screening : When Claude pulls content from external sources, like web pages, file contents, or tool outputs, an API-side probe checks that content for attempts to hijack Claude's behavior. When something looks like an injection attempt, a warning is added to Claude's context before the result is shared with the user.

Auto mode in production

Teams are already running auto mode as their production default:

• Adobe's merchandising platform team is responsible for keeping pricing and promotional pages accurate and current across 90+ countries and 30+ languages on Adobe.com. They built an agentic loop to build and verify those pages, running it in auto mode so engineers receive finished PRs for review.
• Nuro runs auto mode across its research and engineering orgs, using it to power overnight research agents that hill-climb evaluation metrics and return finished PRs for review by morning.
• Gusto adopted auto mode to end the permission fatigue that was pushing engineers toward bypassing permissions checks entirely. About 10% of sessions since mid-May include a classifier denial—evidence it's doing real work without slowing legitimate tasks.
• Garner Health pushed auto mode as the default to all 550 employees via managed settings, standardizing a company-wide software development lifecycle (SDLC) that no longer depends on hand-curated command allowlists.