Claude Code Auto Mode 找不到、不生效怎么办？Bedrock/Vertex/Foundry 配置排查（v2.1.207）

在使用 Claude Code 编写代码时，其默认的权限控制策略相当保守：修改文件或执行 Bash 命令通常都会频繁弹出确认窗口。对于长周期的复杂任务，这些弹窗极易打断开发者的工作心流。部分用户会选择直接添加 --dangerously-skip-permissions 参数，虽然省去了确认步骤，但这也意味着将整个本地环境暴露在极高的安全风险之下。

Auto Mode 则提供了一个绝佳的折中方案：绝大多数安全操作可以自动放行，而具有潜在风险的操作则会首先交由一层独立的安全分类器（Classifier）进行审核。如果分类器判定风险过高，会主动进行拦截；若存在不确定性，才会退回人工确认环节。

本文将依据当前最新的版本迭代，详细说明如何开启和关闭 Auto Mode，并特别针对 Bedrock、Vertex AI 与 Foundry 等第三方云平台的适配情况进行说明。

在开始之前，请先确认您当前的 Claude Code 版本：

claude --version

强烈建议升级至 ≥ 2.1.207 版本。更早版本的配置方式存在明显差异（详情请参考下文的“版本更迭”章节）。

相关官方文档参考：

• Permission modes
• Configure auto mode
• Settings

一、全面理解 Auto Mode

Claude Code 提供了多种权限模式，在当前会话中可以通过 Shift+Tab 进行快捷切换：

需要明确的是，Auto 模式绝不是简单地关闭所有安全检查，而是引入了另一个独立的模型在执行前进行风险预判：评估该指令是否越权、是否在尝试访问未知的环境目标、以及是否存在典型的提示词注入（Prompt Injection）特征。

[!WARNING]

• Auto 模式旨在降低人工确认频率，但并不等同于绝对的安全。
• 启用该模式会带来少量的延迟增加以及额外的 Token 消耗。
• 如果分类器连续发生过多次拦截，系统将自动降级退回 Manual 模式以确保安全。

二、版本更迭：环境变量配置的废存

网络上的许多早期教程仍在使用或推荐以下配置方式：

export CLAUDE_CODE_ENABLE_AUTO_MODE=1

或者在 settings.json 中配置：

{
  "env": {
    "CLAUDE_CODE_ENABLE_AUTO_MODE": "1"
  }
}

实际上，这是 v2.1.158 ～ 2.1.206 版本期间，在使用 Bedrock、Vertex 或 Foundry 平台时的妥协做法。

如果您已经升级至 2.1.207 及以上版本，却依然照搬旧教程配置了该环境变量，虽然通常不会引发冲突，但这已经不再是必须步骤。一切请以官方的 Changelog 和您本机的实际行为为准。

三、如何正确开启 Auto Mode

1. 前置验证条件

只有在同时满足以下全部条件时，Auto 模式才会正常出现：

1. 客户端版本：建议升级至 ≥ 2.1.207（第三方云平台即可免除环境变量注入）。
2. 底层模型支持：
   • Anthropic 原生 API：官方文档要求使用较新的 Sonnet 或 Opus 模型（例如 4.6 及以上版本）。
   • Bedrock / Vertex / Foundry：常见的支持模型为 Sonnet 5、Opus 4.7、Opus 4.8 等；过于陈旧的模型将无法开启。
3. 订阅套餐与组织策略：
   • Team / Enterprise 用户：可能需要 Owner 在 Claude Code 管理后台 中全局授权。
   • 管理员也可能通过下发托管配置（Managed Settings）在全局范围内彻底禁用了该功能。
4. 服务提供方差异：
   • Anthropic 原生 API：支持向来最为直接。
   • Bedrock / Vertex / Foundry：207 版本后默认放开；旧版本必须依赖环境变量。

如果界面提示 Auto unavailable，请优先依据上述清单逐一排查，这通常是策略阻断而非临时性的网络故障。

2. 在会话中临时开启

进入 Claude Code 的交互界面后，直接按下：

Shift+Tab

在弹出的模式列表中循环切换，直至高亮停留在 Auto 即可。

当然，您也可以在终端启动时直接通过参数指定：

claude --permission-mode auto

3. 设为默认模式（强烈推荐写入用户级配置）

建议直接修改全局的用户级配置文件：

配置文件路径： ~/.claude/settings.json
（Windows 系统通常位于 %USERPROFILE%\.claude\settings.json）

{
  "permissions": {
    "defaultMode": "auto"
  }
}

保存配置后，新开启一个 Session 即可生效（大多数涉及权限的底层配置都会支持热加载，但在新会话中测试最为稳妥）。

4. 企业组织的统一管控

如果是企业环境，应当通过 Managed Settings（如管理后台下发、MDM 推送或直接向宿主机写入 managed-settings.json）进行统一管控。如果企业出于合规考量需要彻底禁止 Auto 模式，应使用下文提及的 disableAutoMode 字段，而绝不能指望开发者在每个独立的代码仓库里自我约束。

5. 针对老版本（< 2.1.207）在云平台上的开启方式

如果您受限于某些原因仍停留在 2.1.158～2.1.206 版本，则必须在用户配置中进行显式声明：

{
  "env": {
    "CLAUDE_CODE_ENABLE_AUTO_MODE": "1"
  },
  "permissions": {
    "defaultMode": "auto"
  }
}

保存后，再次使用 Shift+Tab 才能顺利切入 Auto 模式。

[!NOTE] 在这些第三方提供方平台上，如果不配置 enable 变量，仅仅声明 defaultMode: "auto" 会被系统直接忽略。

四、如何彻底关闭：disableAutoMode

如果您希望在本机或整个研发团队中彻底封禁 Auto 模式，请在配置中添加：

{
  "permissions": {
    "disableAutoMode": "disable"
  }
}

生效表现：

• Shift+Tab 的循环列表中将不再出现 Auto 选项。
• 命令行传入 --permission-mode auto 将被明确拒绝。
• 该指令的优先级将直接覆盖旧版 CLAUDE_CODE_ENABLE_AUTO_MODE 的开启策略。

配置落地的推荐位置：

五、配置文件的作用域陷阱：为何项目级配置经常失效？

这是当前开发者群体中最容易踩坑的设计逻辑。

1. Settings 文件的层级划分

对于普通的配置字段，其解析优先级大致遵循：托管级 > 命令行覆盖 > 本地工作区 > 项目级 > 用户级。 然而，Auto 模式相关的所有配置均受特殊的安全约束，您不能套用常规的“项目级优先覆盖用户级”的思维定势。

2. defaultMode: "auto" 写入项目级配置为何无效？

自 v2.1.142 版本起，Claude Code 会直接忽略 存在于以下两个文件中的 defaultMode: "auto" 声明：

• .claude/settings.json
• .claude/settings.local.json

这意味着：任何代码仓库都无法通过提交一份恶意或随意的配置文件，来暗中为拉取代码的开发者开启 Auto 模式。 当您这么写时，系统不会抛出任何报错，但 Session 依旧会稳如泰山地从 Manual 模式启动——这看起来像是产品 Bug，实则是刻意设计的安全阻断策略。

正确的实践： 请将 defaultMode: "auto" 统一写入 ~/.claude/settings.json 或企业下发的托管配置中。

3. autoMode（分类器规则）同样拒读共享配置

决定信任哪些 Git 组织、内网域名以及云端存储桶的安全白名单，均被定义在 autoMode 字段下。官方严格限定安全分类器只能从以下安全源读取规则：

• ~/.claude/settings.json
• Managed Settings（企业托管配置）
• 启动时显式传入的 --settings 或 SDK 注入

系统坚决不读取可提交至代码库的 .claude/settings.json（这有效防止了仅仅因为 Clone 了一个恶意仓库，就导致本地的安全规则防线被全面撕裂）。

此外，从 v2.1.207 起：autoMode 字段也正式停止从 .claude/settings.local.json 中读取。 过去依赖 local 配置为单个项目添加 Trusted Bucket 的开发者，在升级后必须将这些白名单统一迁移至全局的用户配置中。

4. 核心配置规则总结矩阵

最终结论： 凡是涉及默认开启 Auto 模式、微调安全分类器白名单、或是试图彻底禁用 Auto 的核心安全配置，请统统沉淀至用户级或企业托管级配置文件中；切勿将其堆砌在代码仓库的 .claude/ 目录下并指望它们能够生效。

六、安全边界探究：分类器默认拦截什么，放行什么？

1. 简化的裁决链路

1. 首先匹配您在本地配置的 deny / ask / allow 规则（其中 deny 具有最高优先级）。
2. 对于只读操作、以及工作目录内的常规文件编辑：大部分操作将自动放行（但涉及特殊受保护的敏感路径除外）。
3. 剩余的所有指令将全盘移交至安全分类器（Classifier）进行深度审计。
4. 若分类器判定拦截，会将具体的风险原因返回给 Claude，促使其寻找替代方案；若连续拦截次数超过阈值，系统将主动退出 Auto 模式，降级回人工审批弹窗。

%% caption: 权限裁决链路：deny 优先级最高，只读/工作目录内操作大多直接放行，其余交分类器裁决，连续拦截触发降级回人工审批
flowchart TD
  A["指令"] --> B{"匹配本地<br/>deny / ask / allow？"}
  B -->|命中 deny| Deny["拦截"]
  B -->|命中 allow| Pass1["放行"]
  B -->|未命中| C{"只读操作 /<br/>工作目录内编辑？"}
  C -->|是，非敏感路径| Pass2["自动放行"]
  C -->|否| D["交给安全分类器裁决"]
  D -->|放行| Pass3["执行"]
  D -->|拦截| E["风险原因返回给 Claude<br/>寻找替代方案"]
  E -->|连续拦截超过阈值| F["退出 Auto 模式<br/>降级回人工审批弹窗"]
  class F keep
  classDef keep fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#0a0a0a

需要注意的是，当进入 Auto 模式后，过于宽泛的 allow 规则（例如暴力的 Bash(*)）会被系统暂时挂起并失效；但颗粒度极细的规则（例如 Bash(npm test)）依然会被保留执行。

2. 默认触发拦截的高危操作（不完全清单）

• 类似 curl | bash 这种典型的下载并执行脚本行为。
• 试图将本地敏感数据发送至外部不可信服务端。
• 执行生产环境的部署、架构迁移，或是涉及云端资源的大批量销毁。
• 篡改 IAM 角色配置、修改仓库核心权限或变更共享基础设施。
• 执行 Force push 强制推送、以及具备破坏性的 Git 操作（如危险的 reset --hard）。
• 试图执行 terraform destroy 等基础设施拆除命令。
• 未经代码审查直接强制合并代码，或向自动化 Bot 发送 /deploy 级别的提权指令。
• 试图向敏感环境反弹 Shell 或建立端口转发隧道。
• 在明文的对话记录中直接打印未经脱敏的真实密钥。

您可以在终端中运行以下命令，审查本机正在生效的完整默认规则：

claude auto-mode defaults
claude auto-mode config

3. 默认相对宽松的放行操作

• 严格限制在当前工作目录内的本地文件读写操作。
• 依据标准的 Lockfile 或 Package 文件声明执行的依赖包安装。
• 纯粹的只读类 HTTP 请求。
• 向启动 Session 时所关联的分支，或是由 Claude 自主新建的衍生分支进行代码推送。

请注意：远端代码仓库本身配置的 Branch Protection（分支保护）策略依然具有最高约束力，Auto 模式无法越权替您绕过远端的安全网关。

4. 极其克制的默认信任边界

在默认状态下，分类器仅仅信任：

• 您的当前工作目录。
• 在当前 Session 启动的那一刻就已经配置好的 Git Remote 远端地址。

对于公司的内部 GitHub Org、企业内网域名、CI/CD 专用的构建产物存储桶等，必须由您亲自将其声明至 autoMode.environment 字段中，否则它们一律会被分类器视为外部的未知威胁并加以拦截。

配置示例（必须写入用户级 ~/.claude/settings.json）：

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/your-org and all repos under it",
      "Trusted internal domains: *.corp.example.com",
      "Trusted cloud buckets: s3://your-build-artifacts"
    ]
  }
}

[!IMPORTANT] 请务必在列表中原样保留 "$defaults" 这一项！
如果缺失了这一声明，相当于您使用了自定义列表整体覆盖了官方精心维护的默认规则库，这无异于亲手拆除了系统的基础安全防线。

5. 其他进阶注意事项

• 您在对话框中口头叮嘱的“先别 push”、“等我 Review 后再执行部署”等意图确实会被大模型参考，但在发生上下文历史压缩后，这些口头约束存在丢失的风险。对于不可逾越的硬性安全红线，请务必通过严格的 permissions.deny 规则进行物理固化。
• 安全分类器主要审计的是用户的输入消息、模型下发的工具调用指令以及 CLAUDE.md 规范，它默认不去审查工具调用返回的原始输出（此举主要为了防御恶意网页或潜藏文件引发的注入攻击，避免干扰审计决策）。
• 诸如 .git 目录、.claude 配置目录（Worktrees 除外）、核心 Shell 配置文件以及 .mcp.json 等受保护的系统级路径，即使在 Auto 模式下也依然会被强制送交检查，无论您是否下发了宽泛的 allow 规则。
• 再次重申：Auto 模式绝不等同于 bypassPermissions。后者会野蛮地放行几乎所有操作，仅推荐在完全隔离、用后即焚的沙盒环境中使用。

七、开箱即用的配置模板

模板 1：个人日常开发默认开启 Auto 模式

配置文件路径：~/.claude/settings.json

{
  "permissions": {
    "defaultMode": "auto"
  },
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: YourCo. Primary use: software development",
      "Source control: github.com/your-org"
    ]
  }
}

模板 2：个人或团队统一封禁 Auto 模式

{
  "permissions": {
    "disableAutoMode": "disable"
  }
}

模板 3：允许 Auto 运行，但一票否决所有高危指令

{
  "permissions": {
    "defaultMode": "auto",
    "deny": [
      "Bash(terraform apply *)",
      "Bash(terraform destroy *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  },
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/your-org"
    ]
  }
}

配置修改完毕后，请务必运行以下命令进行自检：

claude auto-mode config
claude doctor

八、常见疑难排查 (FAQ)

Q：为什么我在 Shift+Tab 列表里找不到 Auto 选项？
请依次排查：本地客户端版本是否足够新？当前所选的底层模型是否支持？如果您处于 Team/Enterprise 组织，是否已被管理员在云端全局封禁？本地是否误配了 disableAutoMode？如果使用的是 Bedrock / Vertex / Foundry 且版本号 < 2.1.207，请务必检查环境变量是否已注入。

Q：我在 Settings 里明确写入了 "defaultMode": "auto"，为何启动依然是 Manual？
极大概率是因为您将这段配置写在了项目级的 .claude/settings.json 或本地工作区的 settings.local.json 中。自 2.1.142 起，这两处的 auto 声明均会被强制屏蔽，请将其迁移至 ~/.claude/settings.json。

Q：为何向内部网段 Push 代码或上传公司私有 Bucket 时总是被无情拦截？
您必须在用户级或托管级配置中手动补全 autoMode.environment 白名单，并切记保留 "$defaults" 项。完成后执行 claude auto-mode config 验证策略是否如期生效。

Q：自从我升级到 2.1.207 后，原本写在 local 里的 autoMode 突然罢工了？
这是正常的系统行为。自 207 版本起，引擎已不再从 .claude/settings.local.json 中拉取 autoMode 白名单，请统一整合至 ~/.claude/settings.json 中。

Q：互联网上早期的教程让我 export CLAUDE_CODE_ENABLE_AUTO_MODE，现在还能删掉吗？
如果您已经升级至 ≥ 2.1.207 版本，在 Bedrock / Vertex / Foundry 等平台上完全不再需要该环境变量。只有那些依然停留在老旧版本的设备才受此掣肘。

Q：为何发生几次拦截后，系统突然变成每一步都要我手动确认了？
这是符合预期的防御降级行为（例如连续遭受约 3 次拦截或累计约 20 次拒绝后将触发系统回退）。正确的解法是：补全 Environment 白名单、在提示词中将任务步骤阐述得更加具象，或者针对个别特殊操作使用 /permissions 进行定向豁免，而不是试图去寻找一个所谓的“关闭回退”的隐藏魔改开关。

九、高频操作备忘录

最终结语：
在 2.1.207 版本发布之后，针对 Bedrock / Vertex AI / Foundry 平台的 Auto Mode 配置终于摆脱了繁琐环境变量的束缚；通过优雅的 Shift+Tab 或用户级 defaultMode 配置即可轻松驾驭。如需执行彻底的封禁合规，请认准唯一的抓手：disableAutoMode。

最后，请永远铭记：项目目录级的配置文件绝对无法为开发者自身开启 Auto 模式，也完全不具备充当企业级安全治理工具的资格——这并非您配置不当，而是产品本身不容越界的安全底线设计。

随着版本的持续快速迭代，所有的字段语义和默认规则请务必以您本机的 claude --version、官方 Changelog 以及终端输出的 claude auto-mode defaults 为准。