Claude Code 默认开启 Auto mode：团队上线前要改好的 6 个权限边界

Claude Code 即将减少一个长期困扰开发者的环节：反复点击权限确认。

Anthropic 宣布，从 2026 年 8 月 14 日开始，Pro、Max 和 Team 计划的新会话将默认使用 Auto mode。它不是“自动选择模型”，也不是无条件放开权限，而是把每次工具调用交给一个分类器判断：常规操作继续执行，不可逆、破坏性或指向当前环境之外的动作则被阻止。

这项变化值得欢迎，但不能被误解成“以后不用管权限了”。Auto mode 改变的是审批机制，不是责任边界。代码能推到哪里、哪些生产操作必须人工确认、什么数据不能外发、一次长任务最多花多少钱，仍然需要团队自己定义。

本文不讨论如何彻底关闭安全检查，而是给出一套上线前可以直接执行的治理清单。

为什么“每一步都确认”并没有想象中安全

传统权限提示依赖人持续保持注意力。长任务里，开发者会连续看到大量相似的读文件、运行测试和 Git 操作，确认很容易变成肌肉记忆。

Anthropic 在官方公告中披露了一项受控测试：1,053 名付费测试者面对一个被替换成明显危险命令的权限提示时，人工拒绝率为 13.6%，Auto mode 对同一批命令的拦截率为 89%。官方同时强调，Auto mode 依赖分类系统，不能消除风险；涉及生产基础设施的高风险变更仍建议人工审查。

这组数字说明的不是“机器判断永远比人可靠”，而是频繁弹窗并不等于有效复核。真正有用的设计应该是：低风险动作不中断，高风险边界稳定存在，少量人工确认发生在开发者能理解上下文的位置。

独立开发者 Simon Willison 对官方评测提出了一个重要补充：即使某项测试中分类器表现更好，也不能由此推导出提示注入问题已经被解决。恶意依赖包、被污染的网页内容和看似可信的安装命令仍可能诱导 Agent 执行危险动作。Auto mode 应被视为纵深防御的一层，而不是沙箱、最小权限和网络隔离的替代品。

1. 先决定哪些动作必须由人确认

Auto mode 默认允许在当前仓库执行较多常规 Git 操作，包括创建 Pull Request，以及向当前仓库分支推送。若团队要求任何推送或建 PR 前都必须有人确认，应使用持久化规则，而不是只在对话里说一句“先别推送”。对话指令可能在上下文压缩后丢失。

Claude Code 官方文档给出的做法是配置 permissions.ask：

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

可以按风险把动作分成三类：

动作	推荐机制	结果
推送、创建 PR、发布版本	permissions.ask	每次在执行前要求人工确认
读取密钥、向公网传代码、修改生产数据	permissions.deny	在分类器之前直接拒绝
运行测试、读取仓库文件、生成本地补丁	Auto mode 分类器	正常执行，异常动作再阻止

必须永远禁止的动作，优先放进组织托管的 permissions.deny。它在分类器之前生效，不能被模型判断或用户的一句临时授权绕过。

2. 明确“内部环境”到底包括什么

分类器默认只信任工作目录和当前仓库配置的远程地址。公司的其他代码仓库、内部制品库、对象存储、CI 服务和私有 API，如果没有声明，可能被视为外部目的地。

团队可以在用户设置或组织托管设置中补充 autoMode.environment：

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme and all repos under it",
      "Trusted internal domains: *.internal.example.com",
      "Trusted cloud buckets: s3://acme-build-artifacts",
      "Internal package registry: npm.internal.example.com",
      "Sensitive remote targets: production clusters and prod namespaces"
    ]
  }
}

这里最容易犯的错误，是为了减少误拦截而把整个公网或全部云资源写成可信。可信环境应该是最小集合：源码组织、确实需要的内部域名、明确的存储桶和制品库。生产命名空间、客户数据位置和密钥系统则应单独标为敏感目标。

还要注意配置来源。官方文档说明，autoMode 不读取仓库里的 .claude/settings.json 和 .claude/settings.local.json，以防克隆下来的项目给自己注入放行规则。团队级规则应放在组织托管设置中，个人规则放在 ~/.claude/settings.json。

3. 扩展规则时不要意外删除官方默认值

environment、allow、soft_deny 和 hard_deny 都支持加入自定义规则，但数组里必须保留字面量 "$defaults"，才能继承内置规则和后续更新。

例如，团队可以在默认规则之外禁止把仓库内容发给第三方代码审查服务：

{
  "autoMode": {
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ],
    "soft_deny": [
      "$defaults",
      "Never modify production Terraform files without an explicit request naming the target"
    ]
  }
}

如果漏掉 "$defaults"，对应列表会被整体替换。对 hard_deny 而言，这可能连内置的数据外泄防护一起丢掉；对 soft_deny 而言，则可能移除强制推送、curl | bash 和生产部署等默认限制。

hard_deny、soft_deny 和 allow 是分类器理解的自然语言规则。若某个命令必须在任何情况下被拦截，仍应使用基于工具模式的 permissions.deny，不要只依赖自然语言分类。

4. 让所有 Shell 命令都经过分类器

默认情况下，较窄的 Bash 或 PowerShell 放行规则可能在分类器之前生效。例如团队原本允许 Bash(npm test)，但脚本参数、生命周期钩子或被替换的依赖可能产生超出预期的行为。

从 Claude Code 2.1.193 起，可以启用：

{
  "autoMode": {
    "classifyAllShell": true
  }
}

它会让 Auto mode 下的所有 Shell 命令进入分类器，即使已有允许规则。代价是每个命令多一次分类判断，带来额外延迟。对于能访问私有代码、云凭据或生产环境的团队，这通常是合理交换；纯本地、低风险项目则可以先保持默认，再根据拒绝日志调整。

5. 把权限治理和成本治理分开

Auto mode 负责判断工具动作是否安全，不负责替团队决定任务预算。长时间运行的编程代理会不断读取上下文、调用模型、执行工具和派生后续步骤；权限合规不代表成本可控。

Anthropic 表示，Pro、Max 和 Team 用户不再承担 Auto mode 分类器本身的额外 token 开销，但正常模型调用和长任务消耗仍然存在。Claude Code 的近期变更记录还加入了网关消费上限提示：达到网关设置的限额时，可以显示上限、重置时间和运营方说明。

因此，统一模型网关至少应记录以下维度：

• user、team、repo 和 session，用于定位谁发起了哪次任务；
• 实际模型、输入/输出 token、缓存命中和工具调用次数；
• 单次会话、单仓库和团队周期预算；
• 达到预算后的停止、降级或转人工策略；
• 分类拒绝、模型错误、重试和 fallback，避免把失败循环算成正常产出。

权限层回答“这一步能不能做”，网关回答“这次调用能不能发、花了多少、失败后去哪里”。两层组合起来，才能同时约束操作风险和账单风险。

6. 先小范围观察拒绝，再扩大默认范围

规则上线后，先运行以下命令确认实际生效内容：

claude auto-mode defaults
claude auto-mode config
claude auto-mode critique

defaults 查看内置规则，config 展开合并后的最终配置，critique 检查自定义规则是否模糊、重复或容易误判。Auto mode 拒绝的动作还可以在 /permissions 的 Recently denied 中回看。

建议选择没有生产写权限的仓库先运行一周，按拒绝原因分类：

1. 内部域名或制品库未声明，补进 environment；
2. 合法的固定流程被持续误拦截，增加足够具体的 allow；
3. 生产、密钥或数据外发边界不够严格，增加 permissions.deny 或 hard_deny；
4. 同一任务反复失败和重试，在网关侧设置次数与预算上限。

不要看到一次误拦截就加入宽泛允许规则。先确认分类器缺少的是目的地、操作意图还是组织上下文，再做最小调整。

上线前检查清单

• 高风险动作是否已经用 ask 或 deny 固化，而不是只写在对话里？
• 源码组织、内部域名、对象存储和制品库是否按最小范围声明？
• 自定义数组是否保留 "$defaults"？
• 需要严格保护的环境是否开启 classifyAllShell？
• 是否能按用户、仓库、会话和模型查看成本与拒绝记录？
• 达到调用次数、预算或连续失败阈值后，任务是否会停止或转人工？
• 生产基础设施变更是否仍保留人工复核？

Auto mode 的价值，不是把人从流程里彻底拿掉，而是把人的注意力从大量低价值确认中释放出来，集中到真正改变权限、数据和生产状态的动作上。团队在默认开启前把这些边界写清楚，自动化才会同时变得更快、更可控。

参考来源

• Anthropic：Auto mode is now the default in Claude Code for Pro, Max, and Team plans
• Claude Code 文档：Configure auto mode
• Claude Code 官方变更记录
• TechCrunch：Anthropic is turning Claude Code’s auto mode on by default
• Simon Willison：Auto mode is now the default in Claude Code