Claude Code 自动模式教程（2026）：如何在真实仓库里更安全地用 Auto Mode

快速答案

值得用，但前提是任务边界足够清楚，而且你愿意把这个仓库当成“允许 agent 在里面动手的隔离环境”，而不是高敏感主仓库。截至 2026-03-26，Anthropic 仍把 Claude Code auto mode 标为 research preview，先面向 Team 计划推出，需要管理员启用，也仍然建议在 isolated environment 里使用，而不是直接对敏感生产仓库开启。

最容易被忽略的一点是：auto mode 不只是“更快批准文件编辑”。按照 Anthropic 当前文档，它的默认 trusted environment 可能覆盖当前工作目录、直接子目录、当前分支、匹配的 git remote 域名、项目里已声明依赖对应的一部分包管理动作，甚至在你已登录匹配网站或 API 的前提下，把仓库 .env 文件里的凭据发往对应目标。所以真正安全的做法不是“先开 auto 再说”，而是：先 plan，检查 defaults，用 worktree 或容器隔离仓库，对真正不能碰的内容补 deny rules，然后再让 Claude 做一个边界明确的任务。

为什么现在值得补这篇

Anthropic 在 2026-03-24 发布了 Claude Code auto mode。这个更新之所以重要，是因为权限弹窗本来就是 coding agent 从“演示很好看”走向“日常真能用”的最大分界线之一。

在 auto mode 出来之前，很多团队基本只剩两种不太理想的选择：

• 每个关键动作都手动批准
• 直接用 --dangerously-skip-permissions 跳过权限

auto mode 的意义，在于它给了中间层：有些动作自动通过，有些动作会被阻止，有些动作要经过 classifier 判断，判断不了时再回到人工确认。真正应该问的问题，不再是“这个功能有没有”，而是“它默认信任什么，以及我该怎样把这个信任边界收窄到适合真实仓库的程度”。

现在到底变了什么，没变什么

项目	当前官方信息	为什么重要
发布时间与状态	auto mode 于 2026-03-24 发布，当前仍标为 research preview	这是新工作流，不是已经很成熟的默认能力
可用范围	Team 计划优先开放，且需要管理员启用；Enterprise 和 API 支持被描述为 coming soon	不是所有 Claude Code 用户现在都能看到
支持的产品表面	当前支持 Claude Code CLI、VS Code 扩展和 Claude Code desktop；官方文档没有把 Claude local 或 remote web-control session 列为 auto mode 可用表面	有些人“看不到 auto”可能不是操作错，而是入口本身不支持
支持模型	当前仅支持 Claude Sonnet 4.6 和 Claude Opus 4.6	较旧的默认模型和轻量模型不能用
不支持的接入方式	不支持 Haiku、Claude 3 系列，也不支持 Bedrock、Vertex、Foundry 等第三方提供方	如果团队不是直接用 Anthropic 托管版 Claude Code，这一点很关键
安全流程	Claude 会先检查显式 allow / deny 规则，再检查低风险默认项，再走 auto-mode classifier，最后才在必要时向你提问	auto mode 不是一个简单的“全部放行”开关
classifier 模型	Anthropic 当前说明 auto-mode classifier 使用 Sonnet 4.6	这意味着额外 token 成本和延迟是真实存在的
失败回退机制	连续 3 次 classifier block，或累计 20 次 block 后，Claude 会回到需要提示确认的状态	长会话仍然可能停下来，而这其实是保护机制

大多数人会漏掉的一点：Auto Mode 信任的不只是文件编辑

如果整篇只记住一个部分，建议记这一段。

按照 Anthropic 当前的 permission 文档，默认 auto-mode trust envelope 可能包括：

• 只读工具调用
• 当前工作目录及其直接子目录内的编辑
• 访问与你当前 git remote 同域名的页面
• 针对项目文件中已声明依赖的包管理和 registry 相关动作
• 对当前分支或 Claude 自己创建分支的操作
• 读取工作目录或子目录中的 .env 凭据，并在你已登录匹配 API 或网站时发送到对应目标

最后这一条尤其值得重视。如果你的仓库里放着真实凭据，那么即使任务看起来只是“改个 refactor”，auto mode 也可能不是合适选项。

还有两个细节要一起看：

• Anthropic 明确说明，进入 auto mode 后会移除危险的宽泛 allow 规则，包括 Bash(*) 这种 blanket shell access、Bash(python *) 这类解释器通配、Bash(npm run *) 这类宽泛包管理模式，以及任何 Agent allow rule。
• 像 Read(.env*) 这样的 deny rule，只会拦截 Claude Code 内建的文件读取工具，拦不住 Bash 里的 cat .env。如果你需要的是硬隔离，就不要只靠规则，应该用 sandboxing、devcontainer，或者根本不把这些 secrets 放进当前 worktree。

什么样的任务才适合 Auto Mode

只有当下面条件同时成立时，Claude Code auto mode 才是好选择：

• 仓库或 worktree 是本地、隔离、低 blast radius 的
• 任务步骤足够多，频繁确认会明显拖慢你
• 目标足够具体，Claude 能判断什么时候算完成
• 你愿意在最后自己检查 diff 和验证输出

适合的任务：

• 按新的 lint、类型或格式规则统一修改代码
• 修一组集中在同一子系统里的测试失败
• 在边界清楚的目录内做文件或符号重命名
• 修改文档、示例或低风险内部工具，并设置明确 stop rules
• 做一个验证命令很明确的受限 refactor

不适合的任务：

• 当前工作树里有生产 secrets 的仓库
• 部署脚本、云基础设施、DNS、计费或权限变更
• 共享环境上的数据库 migration
• 你并不熟悉的仓库里的破坏性清理
• 任何一条错误 Bash 命令都会造成明显损失的场景

一套更安全的真实仓库工作流

第 0 步：先隔离工作副本，再谈权限隔离

最安全的 auto-mode 会话，不应该直接跑在你的主 checkout 里，而应该跑在一次性分支、git worktree 或 devcontainer 里。

例如：

git worktree add ../repo-auto-mode -b claude-auto-mode-safe
cd ../repo-auto-mode
claude

这样做的价值，是在 Claude 权限系统开始发挥作用之前，就先把 blast radius 缩小。如果你做不到环境隔离，至少也应该把 secrets 从当前工作目录移走，并把 deploy、billing 之类的路径排除在任务之外。

第 1 步：先用 /plan，不要一开始就让它自主改

Anthropic 当前的工作流文档仍然把 plan mode 定位为安全的 read-first 起点。你可以直接这样启动：

claude --permission-mode plan

如果你已经在 Claude Code 里，也可以先用 /plan，留在同一个 session 继续。

给 Claude 一个边界清楚的规划提示词：

Analyze this repository and propose the smallest plan to update the API client tests.
Do not edit files or run commands yet.

Tell me:
1. which files are likely to change
2. which commands you expect to run
3. which risky paths or secrets should stay off-limits
4. what the smallest verification command is

这一步才是真正的安全门。如果计划本身就已经很散，auto mode 只会让错误计划执行得更快。

第 2 步：开启 auto 之前，先看清它当前的默认信任范围

Anthropic 现在已经提供了比“靠猜”更稳的命令：

claude auto-mode defaults
claude auto-mode config

如果你准备改自定义规则，Anthropic 还提供了：

claude auto-mode critique "This task may need tests, a package install, and docs edits. Is my config too broad?"

当前文档里有两个很实用的细节：

• 一旦你设置 autoMode.allow 或 autoMode.softDeny，它们会直接替换默认值，而不是在默认值基础上 merge，所以这属于 expert setting。
• autoMode.environment 只会从用户设置和 .claude/settings.local.json 读取，不会从共享项目设置读取。这对安全是好事，因为仓库内被提交的配置无法悄悄扩大每个人的 auto-mode 信任边界。

第 3 步：把范围、停止条件和唯一验证命令写清楚

当任务形状足够窄时，auto mode 才更稳定。

可直接复制的提示词：

You are working in a supervised Claude Code auto-mode session.

Goal:
Update the API response parsing in src/api and fix the directly affected tests.

Allowed paths:
- src/api
- tests/api
- docs/api-migration.md

Forbidden paths:
- deployment/
- infra/
- scripts/release/
- .env*
- package.json
- lockfiles

Rules:
- Prefer the smallest possible change.
- Do not install or update packages.
- Do not push, deploy, or open unrelated network destinations.
- Run only one focused verification command unless I approve a broader one.
- If the fix requires touching more than 5 files outside the allowed paths, stop and ask.
- If the same category of action is blocked twice, summarize what is missing instead of improvising.

Return at the end:
1. files changed
2. commands run
3. verification result
4. remaining risks

这段提示词不花哨，但很实用，因为它同时给了 Claude 目标、边界和明确的停止点。

第 4 步：对真正“绝对不能碰”的内容，补 deny rules

如果某类路径或命令家族你是真的不想让它碰，就不要只把这层意思埋在自然语言里，应该直接写进 permissions。

值得考虑的例子：

• 禁止读取 .env 文件
• 禁止编辑 deployment/、infra/、terraform/ 等目录
• 禁止 git push
• 禁止安装依赖的命令

Anthropic 当前文档建议通过 /permissions 或 Claude Code settings 来管理这些规则。但也要记住上限：针对 Read 或 Edit 的 deny rule 并不能阻止任意 shell access。如果你需要 OS 级别的硬保护，那就把 permissions 和 sandboxing 或一次性环境一起用。

第 5 步：只让 Auto Mode 承担“中间那一段重复劳动”

当计划已经正确、边界已经写清之后，再启用 auto mode：

claude --enable-auto-mode

在 CLI 里，你也可以用 Shift+Tab 切换模式；在支持的 UI 表面里，也可以在规划后通过 mode selector 切过去。

比较健康的模式是：

1. 在 plan mode 里看仓库
2. 自己审一遍计划
3. 对一个边界明确的任务开启 auto mode
4. 让 Claude 编辑并跑一个有针对性的验证命令
5. 自己检查 diff

不健康的模式则是：

1. 修测试
2. 顺手清理一堆无关 warning
3. 顺手升级依赖
4. 顺手改配置
5. 再“顺便优化一下 build”

auto mode 解决不了任务含糊的问题。它只是让已经定义清楚的任务，在执行阶段少一些打断。

如果你还是觉得 Auto Mode 太宽，怎么办

有时正确答案不是“把 auto mode 调得更严”，而是“换一种 permission mode”。

当前最值得一起比较的是 dontAsk。Anthropic 当前文档把它描述成：Claude 只会在现有 allow rules 允许的范围内行动，其余情况直接不问。如果你的环境已经有明确命令规则，这种模式有时反而比不断放宽 auto mode 更安全。

如果你需要的是更硬的保证，比起单独相信 classifier，更稳的做法是组合使用这些手段：

• plan：只读地理解仓库
• acceptEdits：处理少量文件修改，不给它更广泛的自主空间
• dontAsk：适合基于预批准规则的受控工作流
• sandboxing、devcontainers 或 worktrees：提供真正的环境隔离

快速决策表

情况	更合适的模式	原因
刚开始理解一个新代码库	plan	只读探索依然是最安全的起点
只改一两个本地文件	acceptEdits	比默认模式更快，但没有 classifier 额外开销
在隔离 worktree 里做中等规模 refactor	auto	弹窗更少，但仍受规则和 classifier 约束
已有明确 allow rules 的受控流程	dontAsk	当策略比灵活性更重要时，它比 auto 更稳
一次性容器或 scratch repo	bypassPermissions，且仅在你完全理解风险时使用	最快，但保护最少

FAQ

auto mode 和 acceptEdits 是一回事吗？

不是。acceptEdits 主要是减少文件编辑时的确认摩擦；auto mode 则更进一步，会自动批准一部分动作，对另一部分动作交给 classifier 判断，在规则和 classifier 都无法解决时才重新提问。

为什么有些人根本看不到 auto mode？

因为它当前仍是分阶段开放。Anthropic 目前把 auto mode 描述为 Team 先行的 research preview，需要管理员启用，而且只支持特定的 Claude Code 表面和模型。如果你在用 Haiku、Claude 3、Bedrock、Vertex、Foundry，或者 Claude 的 web-control session，那么没有 auto toggle 都可能是正常情况。

只靠 deny rules 就能保护 secrets 吗？

不能完全依赖。像 Read(.env*) 这样的规则只能帮助你限制 Claude Code 的文件工具，拦不住 Bash 里的 cat .env。如果 secrets 真的必须不可见，更稳的做法是把它们移出当前工作目录，或者直接使用不包含这些凭据的隔离环境。

auto mode 会更贵吗？

会。Anthropic 明确说明 classifier checks 会增加 token usage 和 round-trip latency，而 classifier 当前运行在 Sonnet 4.6 上。通常只有当它确实能帮你减少大量“提示词 + 权限确认”中断时，这个额外成本才值得。

什么时候应该直接跳过 auto mode？

当仓库里有敏感凭据、任务本身很模糊、命令面涉及部署或基础设施动作，或者一条错误 shell 命令的代价很高时，就应该直接跳过。

最终结论

Claude Code auto mode 当然有用，但更准确的心智模型不是“可信任的自动驾驶”，而是“我先定义边界，再让 classifier 辅助执行”。

如果你只想记最短版本，可以按这个清单来：

1. 用 worktree、分支或容器隔离仓库
2. 先用 /plan
3. 检查 claude auto-mode defaults
4. 对真正不能碰的内容加 deny rules
5. 只让 Claude 做一个边界明确的任务
6. 最后自己检查 diff 和验证输出

这套流程当然比无脑放权更慢，但它比持续人工弹窗更高效，也更不容易让你最后收获一个仓库事故。

核验说明

已于 2026-03-26 核验。

• 对照 Anthropic 官方 auto mode 发布说明，确认 2026-03-24 发布时间、research preview 状态、Team 优先开放、需要 admin enablement、支持模型，以及 isolated environment 建议：https://claude.com/blog/auto-mode。
• 对照 Anthropic 官方 permission-mode 文档，确认当前支持的产品表面、不支持的提供方、动作评估顺序、classifier 模型、被移除的宽泛 allow rules，以及连续 3 次 / 累计 20 次 block 后回退到提示确认的行为：https://code.claude.com/docs/en/permission-modes。
• 对照 Anthropic 官方 permissions 文档，确认 trusted infrastructure 默认范围、.env 凭据行为、deny rules 对 Bash 的限制、autoMode.environment 的读取位置、/permissions，以及 claude auto-mode critique：https://code.claude.com/docs/en/permissions。
• 对照 Anthropic 官方 CLI reference，确认 claude --enable-auto-mode、claude auto-mode defaults 和 claude auto-mode config：https://code.claude.com/docs/en/cli-reference。
• 对照 Anthropic 官方 common workflows 与 sandboxing 文档，确认 /plan、模式切换、worktree 指引、devcontainers，以及把 sandboxing 作为 defense in depth 的建议：https://code.claude.com/docs/en/common-workflows 和 https://code.claude.com/docs/en/sandboxing。