自动模式（Auto mode）让 Claude Code 在无权限提示下运行，但默认只信任工作目录和当前仓库远程。本文说明如何通过 autoMode.environment 告诉分类器哪些仓库、存储桶、域名是组织内部资源，避免日常操作被拦截。配置后可用 claude auto-mode config 查看生效规则，用 claude auto-mode critique 检查自定义规则是否合理。注意 auto mode 在 Bedrock/Vertex/Foundry 上不可用。

Claude Code 自动模式配置：信任仓库、域名与规则覆盖

分类器从哪里读取配置

分类器读取的 CLAUDE.md 内容与 Claude 本身加载的一致，因此在项目 CLAUDE.md 中写“永远不要 force push”这样的指令，会同时影响 Claude 和分类器。项目约定和行为规则从这里开始。

跨项目适用的规则（如受信任基础设施或组织级拒绝规则）写在 autoMode 设置块中。分类器从以下范围读取 autoMode：

范围	文件	用途
单个开发者	~/.claude/settings.json	个人信任的基础设施
单个项目+单个开发者	.claude/settings.local.json	项目特定的受信任存储桶或服务，会被 gitignore
组织级	托管设置	分发给所有开发者的信任基础设施
--settings 参数或 Agent SDK	内联 JSON	自动化场景的每次调用覆盖

分类器 不读取 团队共享项目设置 .claude/settings.json 中的 autoMode，因此检入仓库的配置文件无法注入自己的允许规则。

各个范围的条目会被合并。开发者可以向 environment、allow、soft_deny 和 hard_deny 添加个人条目，但无法移除托管设置提供的条目。因为 allow 规则的作用是作为分类器内部软阻止规则（soft block）的例外，所以开发者添加的 allow 条目可以覆盖组织的 soft_deny 条目：组合是累加的，不是硬性策略边界。

分类器是权限系统之后第二道门。对于无论用户意图或分类器配置如何都绝对不允许执行的操作，请使用托管设置中的 permissions.deny，它在分类器判断之前就阻止操作且无法覆盖。

配置受信任的基础设施

对于大多数组织，只需要设置 autoMode.environment。它告诉分类器哪些仓库、存储桶和域名是可信的：分类器用它来决定什么是“外部”，所以未列出的目标都是潜在的数据泄露目标。

默认环境列表信任工作仓库及其配置的远程。要在保留默认值的基础上添加自己的条目，在数组中包含字面字符串 "$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、制品库、内部包索引、事故处理工具
• 附加上下文：受监管行业约束、多租户基础设施或影响分类器风险判断的合规要求

一个实用的起始模板：填写方括号内的字段，移除不适用的行。

{
  "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。

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

1. hard_deny 规则无条件阻止。用户意图和 allow 例外不适用。
2. soft_deny 规则接下来阻止。用户意图和 allow 例外可以覆盖。
3. allow 规则然后覆盖匹配的 soft_deny 规则作为例外。
4. 明确的用户意图覆盖剩余的软阻止：如果用户消息直接且具体地描述了 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"，则替换该部分的整个默认列表。例如，没有 "$defaults" 的 soft_deny 数组会丢弃所有内置软阻止规则，包括强制推送、curl | bash 和生产部署。没有 "$defaults" 的 hard_deny 数组会丢弃内置数据泄露和自动模式绕过规则。

每个部分独立评估，因此只设 environment 不影响默认的 allow、soft_deny 和 hard_deny 列表。只有在打算完全接管列表时才省略 "$defaults"。安全做法：运行 claude auto-mode defaults 打印内置规则，复制到设置文件中，然后对照自己的管道和风险承受度逐条审查。

查看默认值与你当前的配置

三个 CLI 子命令帮助检查和验证配置。

打印内置的 environment、allow、soft_deny 和 hard_deny 规则为 JSON：

claude auto-mode defaults

打印分类器实际使用的规则 JSON（应用了你的设置，未设置的用默认值）：

claude auto-mode config

获取对你的自定义 allow、soft_deny、hard_deny 规则的 AI 反馈：

claude auto-mode critique

保存设置后运行 claude auto-mode config 确认生效规则符合预期，"$defaults" 会在相应位置展开。如果写了自定义规则，claude auto-mode critique 会审查并标记歧义、冗余或可能导致误报的条目。如果需要删除或重写某个内置规则而不是在它旁边添加，将 claude auto-mode defaults 输出保存到文件，编辑列表，然后将结果粘贴到设置文件中替换 "$defaults"。

查看拒绝记录

当自动模式拒绝一个工具调用时，该拒绝记录在 /permissions 下的“Recently denied”选项卡中。按 r 键标记被拒绝的操作以重试：退出对话框后，Claude Code 会发送消息告知模型它可以重试该工具调用并继续对话。

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

如需程序化响应拒绝，使用 PermissionDenied 钩子。

常见问题

如何将内部仓库加入自动模式信任列表？

在 autoMode.environment 数组中添加类似 "Source control: github.example.com/your-org and all repos under it" 的条目，并确保包含 "$defaults"。然后运行 claude auto-mode config 验证。

自动模式拒绝操作后怎么办？

在 /permissions 的“Recently denied”选项卡中按 r 键标记重试。如果重复拒绝同一目标，将其地址添加到 autoMode.environment。也可以使用 PermissionDenied 钩子编程处理。

claude auto-mode defaults 和 claude auto-mode config 有什么区别？

defaults 仅输出 Claude Code 内置的默认规则，不包含任何自定义配置。config 输出应用了当前所有设置（包括个人和组织级）后的最终生效规则，其中 "$defaults" 会展开为实际规则列表。