配置自动模式

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

自动模式通过分类器处理工具调用，使 Claude Code 无需显示常规权限提示即可运行。分类器会阻止不可逆、破坏性或针对环境外部的操作。拒绝规则和显式询问规则会先于分类器求值，因此仍会阻止操作或提示用户。请使用 autoMode 设置块告诉分类器组织信任哪些仓库、存储桶和域，使其不再阻止常规内部操作。

默认情况下，分类器只信任工作目录和当前仓库已配置的 remote。在将公司的源代码控制组织或团队云存储桶加入 autoMode.environment 之前，推送到这些目标或向其中写入内容等操作会被阻止。

有关自动模式的启用方法及其默认阻止的内容，请参阅权限模式。本页是配置参考。

本页介绍如何：

• 在 CLAUDE.md、用户设置和托管设置之间选择规则的配置位置
• 使用 autoMode.environment 定义受信任的基础设施
• 当默认规则不适合你的流水线时，覆盖阻止和允许规则
• 使用 autoMode.classifyAllShell 让所有 shell 命令都经过分类器
• 使用 claude auto-mode 子命令检查默认值和实际生效的配置
• 查看拒绝记录，了解接下来需要添加哪些内容

分类器从哪里读取配置

分类器会读取 Claude 本身加载的同一份 CLAUDE.md 内容，因此，项目 CLAUDE.md 中的“绝不强制推送”等指令会同时引导 Claude 和分类器。项目约定和行为规则应优先写在这里。

对于跨项目生效的规则，例如受信任基础设施或组织范围的拒绝规则，请使用 autoMode 设置块。分类器会从以下作用域读取 autoMode：

分类器不会从共享项目设置中读取 autoMode；此类设置位于 .claude/settings.json，因此提交到仓库的内容无法注入自己的允许规则。

各作用域中的条目会合并。开发者可以使用个人条目扩展 environment、allow、soft_deny 和 hard_deny，但不能移除托管设置提供的条目。由于允许规则在分类器内部充当软阻止规则的例外，开发者添加的 allow 条目可以覆盖组织的 soft_deny 条目：这种组合是累加关系，并不构成不可逾越的策略边界。

定义受信任的基础设施

对于大多数组织，autoMode.environment 是唯一需要设置的字段。它告诉分类器哪些仓库、存储桶和域可信。分类器据此判断“外部”的含义，因此任何未列出的目标都可能被视为数据外泄目标。

从 Claude Code v2.1.198 开始，claude auto-mode defaults 会输出三类环境条目。v2.1.195 之前的版本只会输出前五个信任槽位。

• 上下文槽位：描述组织、技术栈和安全状况，使分类器能够结合你的上下文理解其他规则。与另外两类不同，上下文槽位本身没有专门针对它们的规则。每个槽位默认显示 None configured，或采用旁边注明的保守假设：
  • 组织
  • Claude Code 的主要用途：默认为软件开发
  • 云提供商
  • 仓库可见性：除非 remote 主机和名称表明仓库是公开的，或者分类器读取到本次对话早些时候执行的可见性检查并确认其公开，否则会假定仓库为私有。分类器会读取你的消息和 Claude 运行的命令，但不会读取命令输出，因此证据必须是它能直接读取的内容，例如由你在消息中说明仓库为公开；仅运行 gh repo view 并产生输出，分类器无法获知结果。使用对话记录作为证据的检查需要 Claude Code v2.1.200 或更高版本
  • 内部共享/snippet 托管：在明确指定之前，公共 paste 和 gist 服务均被视为信任边界之外
  • 组织专用 CLI
  • 密钥管理
  • 默认/受保护分支：在指定其他分支之前，main 和 master 会被视为受保护分支
  • CI/CD 部署目标
  • 网络状况
  • 受保护的部署 namespace/环境：在明确指定之前，回退到“敏感远程目标”启发式规则
  • 数据保留/解密级
• 信任槽位：指定分类器将哪些内容视为信任边界以内。槽位包括 Trusted repo、Source control、Trusted internal domains、Trusted cloud buckets、Key internal services 和 Internal package registry。仓库和源代码控制条目默认为工作仓库及其已配置的 remote。其他信任槽位均默认为 None configured，因此只有显式添加后才会受到信任。 仓库可见性只决定机密材料的处理范围：私有仓库可以作为机密材料的目标，但将仓库设为私有绝不意味着可以把密钥、个人数据或受托数据写入其中；分类器还会将从工作仓库之外移植、重新定向或首次读取的内容视为不属于该仓库的工作。此范围规则需要 Claude Code v2.1.203 或更高版本。
• 敏感度槽位：指定保护规则应将哪些内容视为高风险。槽位包括 Sensitive data locations & audiences、Sensitive remote targets 和 Protected IaC scopes。每个槽位默认采用宽泛的启发式规则，例如将主机或 namespace 名称中带有 prod 或 production 的目标视为敏感远程目标，因此即使尚未配置，保护规则也会生效。在敏感度槽位中指定具体目标后，相关规则会针对指定目标，而不再使用启发式规则。

要在保留默认条目的同时加入自己的条目，请在数组中包含字面字符串 "$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 Code 的主要用途，例如软件开发、基础设施自动化或数据工程
• 源代码控制：开发者会向其推送代码的每个 GitHub、GitLab 或 Bitbucket 组织
• 云提供商和受信任存储桶：应允许 Claude 读取和写入的存储桶名称或前缀
• 受信任内部域：内部网络中的 API、控制面板和服务主机名，例如 *.internal.example.com
• 关键内部服务：CI、制品 registry、内部软件包索引和事件处置工具
• 内部软件包 registry：安装操作应通过的私有 npm、PyPI 或其他 registry，以便阻止绕过它、直接使用公共 registry 的安装
• 敏感数据位置和受众：保存个人数据、机密业务数据、凭据、受监管数据或类似敏感材料的存储桶、数据库或路径，以及各位置中数据可以共享给哪些受众。这样分类器会保护这些位置，而不必根据内容猜测。 Claude Code v2.1.195 到 v2.1.197 将此条目命名为 PII / regulated-data locations，仅涵盖保存个人或受监管数据的位置，不包含受众维度
• 敏感远程目标：视为生产环境的 namespace、主机或容器，因此对它们执行远程 shell 和端口转发需要你的明确批准
• 受保护 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}"
    ]
  }
}

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

无需一次填完所有内容。合理的推广部署方式是：先从默认值开始，添加源代码控制组织和关键内部服务，解决向自己的仓库推送等最常见的误判；接着添加受信任域和云存储桶；其余内容可在遇到阻止时逐步补充。

覆盖阻止和允许规则

另外三个字段可以替换分类器的内置规则列表：

• autoMode.hard_deny：无条件安全边界
• autoMode.soft_deny：可以由用户意图解除的破坏性操作限制
• autoMode.allow：软阻止规则的例外

每个字段都是由自然语言说明组成的数组，分类器会将其作为自然语言规则读取。对于在分类器之前执行、基于工具模式的强制阻止规则，请使用 permissions.deny。

在分类器内部，优先级分为四层：

• hard_deny 规则无条件阻止操作。用户意图和 allow 例外均不适用。
• soft_deny 规则其次执行。用户意图和 allow 例外可以覆盖这些规则。
• allow 规则随后作为例外，覆盖匹配的 soft_deny 规则。
• 明确的用户意图会覆盖其余软阻止规则：如果用户消息直接、具体地描述 Claude 即将执行的确切操作，即使匹配 soft_deny 规则，分类器也会允许该操作。

宽泛的请求不算明确意图。要求 Claude“清理仓库”并不授权强制推送，但明确要求 Claude“强制推送此分支”则构成授权。

如果分类器反复标记默认例外未涵盖的常规模式，可通过添加 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"
    ]
  }
}

每个部分单独求值，因此只设置 environment 不会影响默认的 allow、soft_deny 和 hard_deny 列表。

只有在打算完全接管列表时，才应省略 "$defaults"。为确保安全，请运行 claude auto-mode defaults 输出内置规则，将其复制到设置文件中，然后根据自身流水线和风险承受能力逐项评审。

让所有 shell 命令都经过分类器

默认情况下，Bash(npm test) 等范围较窄的 Bash 和 PowerShell 允许规则会沿用到自动模式，并在分类器运行前完成解析。自动模式只暂停授予任意代码执行权限的宽泛规则，例如 Bash(*) 或带通配符的解释器规则。这意味着范围较窄的规则仍可能让破坏性参数通过，而分类器无法看到它，例如规则前缀未预料到的脚本路径或标志。

将 autoMode.classifyAllShell 设为 true，可以在自动模式生效时暂停所有 Bash 和 PowerShell 允许规则，使分类器评估每一条 shell 命令，而不受允许列表影响。

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

这是用延迟换取覆盖范围：原本可由允许规则立即批准的命令现在需要等待分类器作出决定，而且每条 shell 命令都计为一次分类器调用。

此设置只在自动模式生效时应用；在其他权限模式中，允许规则仍按常规方式工作。

检查默认值和实际生效的配置

三个 CLI 子命令可以帮助检查并验证配置。

以 JSON 格式输出内置的 environment、allow、soft_deny 和 hard_deny 规则：

claude auto-mode defaults

以 JSON 格式输出分类器实际使用的内容：已设置的部分使用你的设置，其余部分使用默认值：

claude auto-mode config

让 AI 评审自定义的 allow、soft_deny 和 hard_deny 规则：

claude auto-mode critique

保存设置后，请运行 claude auto-mode config，确认实际生效的规则符合预期，并且 "$defaults" 已在原位置展开。如果编写了自定义规则，claude auto-mode critique 会进行评审，并标记含义模糊、重复或可能造成误判的条目。

如果需要移除或改写内置规则，而不只是添加新规则，请将 claude auto-mode defaults 的输出保存到文件，编辑列表，然后用结果替换设置文件中的 "$defaults"。

查看拒绝记录

自动模式拒绝工具调用后，该记录会显示在 /permissions 的 Recently denied 标签页中。在被拒绝的操作上按 r 可将其标记为重试：退出对话框时，Claude Code 会发送一条消息，告诉模型可以重试该工具调用，然后继续对话。

在 Claude Code v2.1.193 及更高版本中，分类器对每次拒绝给出的理由会随被阻止的工具调用一起显示在对话记录和拒绝通知中，也会显示在 Recently denied 标签页的每个条目下。可根据理由判断应添加 environment 条目、添加 allow 例外，还是在下一条消息中明确表达意图后重试。

对同一目标反复出现拒绝，通常表示分类器缺少上下文。请将该目标添加到 autoMode.environment，然后运行 claude auto-mode config 确认配置已经生效。

如需以编程方式响应拒绝，请使用 PermissionDenied Hook。

另请参阅

• 权限模式：自动模式是什么、默认会阻止什么，以及如何启用
• 托管设置：在组织中部署 autoMode 配置
• 权限：在分类器运行前应用的允许、询问和拒绝规则
• 设置：完整的设置参考，包括 autoMode key