Claude Code 默认自动审批如何配置

Claude Code 突然提示「Auto mode 已成为默认权限模式」，并不是配置丢了。按原文梳理，2.1.283 开始切换默认行为，2.1.284 覆盖所有账户：新建交互式终端和 VS Code 会话时，更多操作交给安全分类器审核，减少人工确认。

但少弹窗不等于取消检查。作者对照官方文档，并检索了 2.1.316 Windows 构建中的提示字符串，解释了默认值、配置优先级、拦截和计费。这篇最有用的地方，是帮你分清：哪些决定可以交给模型，哪些边界还得自己写进规则。

Auto 到底替你批准了哪些操作

Auto mode 引入第二个模型作为分类器（classifier），代替用户判断部分工具调用的风险。它与负责写代码的模型分工不同：一个提出操作，另一个审核操作。

执行顺序比「有模型审核」更重要。

首先处理已有的 allow、ask、deny 规则，匹配后通常直接得到结果，危险 rm 路径等情况有例外。其次，项目工作目录内的只读操作和文件编辑直接执行，不经过分类器。剩余的 shell 命令、网络请求、MCP 工具和子代理操作才进入审核。

Auto 是权限决策方式，不是文件隔离机制。

六种模式可以按自己的需求选择。Manual 主要自动放行读取；accept edits 再放行项目编辑，以及 mkdir、touch、rm、mv、cp、sed 等文件命令，测试和其他 shell 命令仍会询问。Plan 在计划获批前禁止编辑，探索命令可以使用分类器审核。dontAsk 只执行预先批准的工具，其余拒绝。

Auto 则让分类器接手更多确认。--dangerously-skip-permissions 对应的 bypassPermissions 跳过审核，但原文明确说 deny 规则仍然适用，不能理解成所有限制都失效。

被拦截后，Claude 会收到原因并尝试更安全的路径。用户可以在 /permissions 的 Recently denied 中找到调用，按 r 转为人工批准后重试。Auto 还会推动 Claude 持续工作、减少澄清提问，因此体感变化不只在弹窗数量上。

为什么配置了模式，启动结果却不一样

作者将变更核对到 2026 年 11 月 2 日的 2.1.316。默认值分两步推出：2.1.283 覆盖第三方提供商和关闭遥测的会话，2.1.284 扩展到所有账户。此前，默认启用还与 Pro、Max、Ultra、Team 套餐及功能标志获取情况有关。

终端启动时先看 --permission-mode 或 --dangerously-skip-permissions，再看设置里的 permissions.defaultMode，最后才使用内置默认值。已有显式配置不会被新默认值覆盖。

要让后续会话回到 Manual，可以把原文这段配置放进 ~/.claude/settings.json：

{
  "permissions": {
    "defaultMode": "default"
  }
}

这里要看 "default"：它是 Manual 的配置值，"manual" 也被接受为别名。只改当前会话，按一次 Shift+Tab 即可；之后依次切到 accept edits、Plan，再回到 Auto。

只想改变一次启动，原文给出的命令是：

claude --permission-mode default

要注意最后的 default，它选择 Manual；单次启用 Auto 则使用 claude --permission-mode auto。

配置位置还有几个容易踩坑的区别：

• 用户文件或 managed settings 可以设置 "defaultMode": "auto"；项目的 .claude/settings.json 和 .claude/settings.local.json 会忽略这个值。项目配置可以选择 default、acceptEdits、plan、dontAsk，并覆盖用户文件。
• VS Code 使用 claudeCode.initialPermissionMode，接受 default、acceptEdits、plan、bypassPermissions，不接受 auto。它不读取项目配置来决定启动模式，并会记住模式指示器中的选择。
• 从 2.1.302 起，claude -p 和 Agent SDK 默认使用 Manual。非交互脚本不会因为交互入口改了默认值，就自动接入分类器。
• 管理员设置 permissions.disableAutoMode 为 "disable"，会移除 Auto 选项；只设置 defaultMode，则仍允许用户自行切换。

哪些操作会被拦，审核又由谁付费

按原文列出的默认策略，分类器信任工作目录和会话启动时已有的 git remotes，其他基础设施按外部资源处理。它会拦截 curl | bash、生产部署和迁移、terraform destroy、git push --force，以及会丢弃未提交工作的 git reset --hard、git clean -fd、git checkout -- .。泄露凭证、删除会话开始前已有的文件、云存储批量删除，以及启动带 --dangerously-skip-permissions 的其他代理，也在拦截范围内。

相对地，项目内文件操作、安装锁文件声明的依赖、只读 HTTP 请求，以及向当前仓库普通分支推送，可以获准。production、gh-pages 等部署分支另作处理。完整默认列表可用 claude auto-mode defaults 查看 JSON。

这也解释了一个容易误判的地方：允许 Auto，并不代表每次 git push 都会询问你。

原文还列出三个边界。进入 Auto 后，Bash(*)、Bash(python*)、包管理器运行命令规则和 Agent 规则等宽泛许可会被暂时搁置，退出后恢复；Bash(npm test) 这样的窄规则保留。聊天里的「不要 push」会成为判断依据，但上下文压缩可能丢掉它。连续拦截 3 次或单会话累计 20 次，会暂停自动审核、恢复人工提示，阈值不可配置。

误拦截可从 /auto-mode-setup 入手：它读取项目和近期会话，生成环境配置供用户审核后保存。从 2.1.304 起，它还支持 Bedrock、Vertex、Foundry、Claude apps gateway 和关闭遥测的会话。autoMode.environment 描述可信基础设施，autoMode.allow 添加例外；自定义 allow 列表要带上 "$defaults"，否则会替换内置例外。

成本也有账户差异。原文称默认分类器是 Claude Sonnet 5，不随 /model 选择改变。Enterprise、Claude API、Claude Platform on AWS、Bedrock、Agent Platform、Foundry 的客户端分类器调用计入 token；Pro、Max、Ultra、Team 未列单独分类器费用。服务端随正常模型请求审核时，没有额外分类器调用，/status 显示 Auto mode server: Enabled。

不可用提示也不能只看字面。作者在构建中发现，auto mode is unavailable for your plan 对应会话熔断，并非套餐不支持；此外还有设置禁用、模型不支持，以及需运行 /fast off 的情况。若连 pwd 都被拦，可能是服务未返回安全判定，不能当成普通权限拒绝。

我的判断

这套思路合理：反复批准测试命令容易变成机械点击，让分类器处理常规操作，把人工注意力留给发布和数据变更，有实际价值。

但作者做的是文档与构建字符串核对，没有提供攻击对照、误报率或任务完成率数据。默认规则的描述可以帮助理解行为，不能据此证明它在一般团队里足够可靠。原文提到客户端分类器不直接读取工具结果，另有服务端探针检查可疑结果，这仍然不构成安全保证。

与 accept edits 相比，Auto 扩大了可自动执行的范围；如果你只嫌编辑确认太多，前者可能已经够用。与 bypassPermissions 相比，Auto 保留审核，更适合减少日常打断。无人值守任务仍需要沙箱或容器，尤其不能把「分类器应该会拦」当成部署权限管理。

另外，「计划不可用」实际指向熔断，是很容易误导排查的文案。作者没有给出完整可用性消息表，遇到其他提示仍应保留疑问。

能拿来做什么

• 给前端或 Node 项目跑长任务前，先提交已有工作，再明确哪些步骤允许自动执行；仅想减少文件编辑确认时，可以先选 accept edits。
• 希望每次推送都人工确认，就添加 permissions.ask 规则 Bash(git push *)；必须禁止的操作写进 deny，不要只留在聊天记录里。
• 内部 registry、存储桶或部署主机频繁被误拦时，先运行 /auto-mode-setup，逐项审核它生成的可信环境配置，再决定是否保存。
• 维护 claude -p 或 Agent SDK 脚本时，显式选择权限模式，并用 /status 排查审核服务状态；不要根据交互终端的默认行为推断脚本权限。