配置 Auto Mode¶

告诉 auto mode 分类器哪些仓库、存储桶和域名是你的组织所信任的。设置环境上下文，覆盖默认的阻止和允许规则，并使用 auto-mode CLI 子命令检查生效配置。

Auto mode 让 Claude Code 无需常规权限提示即可运行。 它将工具调用路由到一个分类器，该分类器阻止任何不可逆、破坏性或指向你环境之外的操作。Deny 和显式 ask 规则在分类器之前评估，仍然会阻止或提示。使用 autoMode 设置块告诉分类器哪些仓库、存储桶和域名是你组织信任的，这样它就不会阻止常规的内部操作。

[!NOTE]
Auto mode 对所有提供商的所有用户可用，包括 Anthropic API、Claude Platform on AWS、Amazon Bedrock、Google Cloud's Agent Platform、Microsoft Foundry，以及已登录的 Claude apps gateway 会话。如果 Claude Code 报告 auto mode 对你的账户不可用，检查 完整要求（涵盖支持的模型和 Team/Enterprise 计划的组织级控制）。v2.1.158 到 v2.1.206，Amazon Bedrock、Google Cloud's Agent Platform、Microsoft Foundry 和 Claude apps gateway 会话需要设置 CLAUDE_CODE_ENABLE_AUTO_MODE=1；v2.1.207 移除了此要求。

默认情况下，分类器仅信任工作目录和当前仓库配置的远程。 push 到公司源码控制组织或写入团队云存储桶等操作会被阻止，直到你将它们添加到 autoMode.environment。

要了解如何启用 auto mode 及其默认阻止内容，参见 Permission modes。本页是配置参考。

本页涵盖：

• 添加人工检查点：用 permissions.ask 对 push 和 PR 进行检查
• 选择在哪里设置规则
• 定义可信基础设施
• 覆盖阻止和允许规则
• 将所有 shell 命令路由到分类器：使用 autoMode.classifyAllShell
• 检查生效配置
• 审查拒绝记录

常见边界¶

Auto mode 默认允许 push 到你工作仓库的任何分支（包括默认分支），以及创建 PR。 但非默认分支如果名字表明它是部署或发布目标（如 production、release、gh-pages），不在此默认范围内——分类器会单独判断这类 push 是否属于生产部署。push 的内容也会被检查，因此 force push、提交中含 secret、或可能在 CI/部署流水线运行时将 secret 发送到仓库外的变更仍然会被阻止。

[!INFO]
v2.1.211 之前，分类器仅允许 push 到你的工作分支、Claude 创建的分支，以及对默认分支的常规 push。

如果你希望在每次 push 或 PR 前都有人工检查点，添加权限规则：下面的配方在其他所有操作上保持 auto mode 开启。

添加人工检查点¶

最直接的机制是 permissions.ask。 内容范围的 ask 规则在分类器之前评估，即使在 auto mode 中也始终强制权限提示，因为显式 ask 规则表达了你要被提示的意图。在设置中添加：

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

根据边界的坚固程度选择机制：

分类器读取配置的位置¶

分类器读取 Claude 本身加载的相同 CLAUDE.md 内容。 因此项目 CLAUDE.md 中的指令（如 "never force push"）同时影响 Claude 和分类器。项目约定和行为规则从这里开始。

对于跨项目适用的规则（如可信基础设施或组织级 deny 规则），使用 autoMode 设置块。分类器从以下范围读取 autoMode：

分类器不从项目设置 .claude/settings.json 或 .claude/settings.local.json 中读取 autoMode。 这两个文件都位于仓库目录中，已提交的仓库或构建步骤可能注入自己的 allow 规则。v2.1.207 之前，分类器也读取 .claude/settings.local.json；请将该文件中的 autoMode 块移到 ~/.claude/settings.json。排除 .claude/settings.local.json 也关闭了仓库提交该文件或本地工具写入的情况。

各范围的条目会组合。开发者可以用个人条目扩展 environment、allow、soft_deny 和 hard_deny，但不能移除 managed settings 提供的条目。因为 allow 规则在分类器内部充当 soft block 规则的例外，开发者添加的 allow 条目可以覆盖组织的 soft_deny 条目——组合是累加的，不是硬策略边界。

[!NOTE]
分类器是在 权限系统 之后运行的第二道门。对于无论用户意图或分类器配置如何都绝不应运行的操作，在 managed settings 中使用 permissions.deny——它在分类器被咨询之前就阻止操作，且不可被覆盖。

定义可信基础设施¶

对大多数组织来说，autoMode.environment 是你唯一需要设置的字段。 它告诉分类器哪些仓库、存储桶和域名是可信的：分类器用它来判断什么是"外部"的，因此未列出的目标都是潜在的数据外泄目标。

自 Claude Code v2.1.198 起，claude auto-mode defaults 打印三种 environment 条目（v2.1.195 之前的版本仅打印前五个信任槽位）：

• 上下文槽位（Context slots）：描述你的组织、技术栈和安全态势，让分类器在你的上下文中理解其他规则。不同于另外两种，上下文槽位没有直接针对它们的规则。各槽位默认为 None configured 或旁边标注的保守假设：
• Organization
• Primary use of Claude Code：默认 software development
• Cloud provider(s)
• Repository visibility：假设仓库为私有，除非远程主机和名称另外表明，或会话中更早的可见性检查显示为公开（需 v2.1.200+）
• Internal sharing / snippet hosting：公共粘贴和 gist 服务被视为信任边界外，直到你命名一个
• Org-specific CLIs
• Secrets management
• CI/CD deploy targets
• Network posture
• Protected deployment namespaces / environments：在你命名前回退到 Sensitive remote targets 启发式规则

• Data retention / declassification

• 信任槽位（Trust slots）：命名分类器视为信任边界内的对象。包括 Trusted repo、Source control、Trusted internal domains、Trusted cloud buckets、Key internal services 和 Internal package registry。repo 和源码控制条目默认为工作仓库及其配置的远程。其他所有信任槽位默认 None configured。仓库可见性仅限定机密材料的范围：私有仓库可接收机密材料，但设为私有不会将 secret 或个人/委托数据清入其中（需 v2.1.203+）。

• 敏感度槽位（Sensitivity slots）：命名保护规则视为高风险的对象。包括 Sensitive data locations & audiences、Sensitive remote targets 和 Protected IaC scopes。各槽位默认一个宽泛的启发式规则（如将名字含 prod 或 production 的主机/命名空间视为敏感远程目标），因此保护规则在你配置之前就是活跃的。命名具体目标会使规则应用于命名目标而非启发式规则。

[!INFO]
v2.1.211 之前，上下文槽位还包含 Default / protected branches 条目，将 main 和 master 视为受保护分支。v2.1.211 移除了它：push 到工作仓库的任何分支默认允许，无需配置受保护分支默认值。

要在默认值之上添加自己的条目，在数组中包含字面字符串 "$defaults"。默认条目会在该位置拼接进来，你的自定义条目可以放在前面或后面。

以下示例保留默认条目，添加组织的仓库、存储桶、域名和服务：

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

保存设置后运行 claude auto-mode config 确认生效规则包含你的条目。

条目是自然语言描述，不是正则或工具模式。 分类器将它们作为自然语言规则阅读。按照你向新工程师描述基础设施的方式编写。完整的 environment 部分涵盖：

• 组织：公司名称和 Claude Code 的主要用途（如 software development、infrastructure automation、data engineering）
• 源码控制：开发者 push 到的每个 GitHub、GitLab 或 Bitbucket 组织
• 云提供商和可信存储桶：Claude 应该能读写的存储桶名称或前缀
• 可信内部域名：网络内 API、仪表板和服务的主机名，如 *.internal.example.com
• 关键内部服务：CI、制品仓库、内部包索引、事件工具
• 内部包注册表：私有 npm、PyPI 或其他注册表，让绕过它使用公共注册表的安装被阻止
• 敏感数据位置和受众：存放个人数据、机密业务数据、凭据、受监管数据的存储桶/数据库/路径，以及每个位置数据可分享的受众
• 敏感远程目标：视为生产环境的命名空间、主机或容器
• 受保护 IaC 作用域：apply 或 destroy 时始终需要你确认的基础设施资源
• 额外上下文：受监管行业约束、多租户基础设施或合规要求

Internal package registry、Sensitive data locations & audiences、Sensitive remote targets 和 Protected IaC scopes 条目需要 Claude Code v2.1.195+。更早版本仍作为普通上下文读取但没有针对它们的内置规则。

实用起始模板（填入括号内字段，删除不适用的行）：

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}

提供的上下文越具体，分类器就越能区分常规内部操作和数据外泄尝试。

不需要一次性填完所有内容。合理的推进方式：从默认值开始，添加源码控制组织和关键内部服务（这解决最常见的误报，如 push 到自己的仓库）。然后添加可信域名和云存储桶。其余的在阻止出现时再补充。

覆盖阻止和允许规则¶

三个额外字段让你替换分类器的内置规则列表：

每个都是自然语言描述的数组。对于在分类器之前运行的工具模式硬阻止，使用 permissions.deny。

在分类器内部，优先级按四个层级工作：

1. hard_deny 规则无条件阻止。用户意图和 allow 例外不适用。
2. soft_deny 规则其次阻止。用户意图和 allow 例外可以覆盖。
3. allow 规则然后作为匹配 soft_deny 规则的例外覆盖。
4. 显式用户意图覆盖剩余的 soft block：如果用户的消息直接且具体地描述了 Claude 即将执行的确切操作，分类器即使 soft_deny 规则匹配也会允许。

一般请求不算显式意图。让 Claude "clean up the repo" 不授权 force-push，但让 Claude "force-push this branch" 可以。

使用建议：
- 要放宽：当分类器反复标记默认例外未覆盖的常规模式时，添加到 allow
- 要收紧：对默认遗漏的环境特定破坏性风险添加到 soft_deny，对绝不应越过的安全边界添加到 hard_deny

要在添加自己规则的同时保留内置规则，在数组中包含字面字符串 "$defaults"。默认规则在该位置拼接进来，你的规则可以放在前面或后面，且随着内置列表在版本间变化你继续继承更新。

以下示例保留所有四个列表的默认值，并向每个添加组织特定规则：

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

[!CAUTION]
在设置 environment、allow、soft_deny 或 hard_deny 时如果不包含 "$defaults"，会替换该部分的整个默认列表：
- soft_deny：所有内置 soft block 规则（包括 force push、curl | bash、生产部署和 auto-mode 绕过）
- hard_deny：内置的数据外泄规则

各部分独立评估，因此单独设置 environment 不会影响默认的 allow、soft_deny 和 hard_deny 列表。

仅在你打算完全掌控列表时才省略 "$defaults"。要安全地这样做，运行 claude auto-mode defaults 打印内置规则，将它们复制到你的设置文件，然后根据你的流水线和风险容忍度审查每条规则。

将所有 shell 命令路由到分类器¶

默认情况下，窄范围的 Bash 和 PowerShell allow 规则（如 Bash(npm test)）会带入 auto mode，在分类器运行前解析。 Auto mode 仅暂停授予任意代码执行的宽范围规则（如 Bash(*) 或通配解释器）。这意味着窄规则仍可能让分类器看不到的破坏性参数通过。

设置 autoMode.classifyAllShell 为 true 可在 auto mode 活跃时暂停所有 Bash 和 PowerShell allow 规则，让分类器评估每个 shell 命令：

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

这以延迟换取覆盖：allow 规则本可立即批准的命令现在等待分类器决定，每个 shell 命令计为一次分类器调用。

该设置仅在 auto mode 活跃时生效，其他权限模式下 allow 规则正常工作。

[!NOTE]
autoMode.classifyAllShell 需要 Claude Code v2.1.193+。更早版本忽略此键，继续将窄 shell allow 规则带入 auto mode。

检查默认值和生效配置¶

claude auto-mode 子命令帮助你检查、验证和重置配置。

打印内置的 environment、allow、soft_deny 和 hard_deny 规则（JSON 格式）：

claude auto-mode defaults

要读取某条规则的完整措辞而不用管道通过 jq，传递 --label 加上规则标签的开头，如 claude auto-mode defaults --label 'Git Destructive'。匹配对每个规则标签做大小写不敏感的前缀匹配。需 v2.1.208+。

打印分类器实际使用的规则（JSON 格式），你的设置应用在设置的位置，其他位置用默认值：

claude auto-mode config

defaults 和 config 都将四个规则列表打印为单个 JSON 对象，每条规则是一个散文字符串。截断示例：

{
  "allow": [
    "...",
    "Test Artifacts: Hardcoded test API keys, placeholder credentials in examples...",
    "..."
  ],
  "soft_deny": [
    "Git Destructive [named+specifics]: Force pushing (`git push --force`), deleting remote branches...",
    "..."
  ],
  "hard_deny": ["..."],
  "environment": [
    "...",
    "**Trusted repo**: The git repository the agent started in...",
    "..."
  ]
}

获取 AI 对你自定义规则的反馈：

claude auto-mode critique

保存设置后运行 claude auto-mode config 确认生效规则符合预期（"$defaults" 已展开）。如果你写了自定义规则，claude auto-mode critique 会审查它们并标记模糊、冗余或可能导致误报的条目。

如果你需要移除或重写内置规则而非在其旁边添加，将 claude auto-mode defaults 的输出保存到文件，编辑列表，然后将结果粘贴到你的设置文件中替代 "$defaults"。

要丢弃自定义配置并恢复内置默认值，运行 reset 子命令（需 v2.1.212+），它从你的用户设置文件中移除 autoMode 部分：

claude auto-mode reset

该命令在写入前会总结将移除的内容并询问 Reset auto mode configuration to defaults?；传递 --yes 跳过确认。Reset 仅修改 ~/.claude/settings.json：来自 managed settings 或 --settings 标志的 autoMode 规则仍然生效。

审查拒绝记录¶

当 auto mode 拒绝一个工具调用时，拒绝会记录在 /permissions 的 Recently denied 标签页中。 对被拒绝的操作按 r 标记为重试：退出对话框时，Claude Code 发送消息告诉模型可以重试该工具调用并恢复对话。

用 allow 规则、environment 条目或重试修复拒绝¶

Claude Code 在拒绝出现的地方（转录、拒绝通知、Recently denied 标签页）显示被阻止的工具调用。根据调用试图访问或执行的内容选择修复方式：

• Claude 在任务中持续需要的目标（如包注册表、内部域名、仓库主机）：添加到 autoMode.environment
• 你希望以后不经审查就能运行的命令：添加 allow 规则
• 你确实打算执行的一次性操作：在下一条消息中说明该意图，让 Claude 重试

大多数会话中显示的原因是固定文本 Blocked by classifier（v2.1.208+）：分类器对每个操作按内部严重度评分而不写解释。某些会话运行的分类器模型会写短解释（v2.1.193+）；出现时，将其视为关于分类器缺少哪个目标或意图的提示。

修复重复拒绝¶

反复出现的同一目标拒绝通常意味着分类器缺少上下文。将该目标添加到 autoMode.environment，然后运行 claude auto-mode config 确认生效。

要以编程方式响应拒绝，使用 PermissionDenied hook。

另请参阅¶

• Permission modes：auto mode 是什么、默认阻止什么、如何启用
• Managed settings：在组织中部署 autoMode 配置
• Permissions：在分类器运行之前适用的 allow、ask 和 deny 规则
• Settings：完整设置参考，包括 autoMode 键