Claude Code 的自动模式是为了解决一个具体烦恼：不用每步都点允许，又不能像跳过权限那样一路放行。它的办法是把每次工具调用先交给分类器判断：不可逆、破坏性、或者指向你环境之外的操作会被拦住，常规内部操作则直接放行。问题是，分类器一开始只认得两样东西：当前工作目录，和当前仓库已经配置好的远端。于是你自己的公司仓库、内部域名、团队云存储桶，在它眼里一律是“外面”，常规操作也会被反复拦下。

2026 年 10 月 19 日的官方更新日志里，Anthropic 给出了向导命令 /auto-mode-setup：它读项目和最近会话，起草一份 autoMode.environment 清单，你审一遍再决定是否写进设置。下面按官方文档顺序走一遍：它读什么、草稿怎么审、写进去怎么验证、被拦了怎么修。

一、先记清判断顺序：自动模式不是全部放行

判断分三层。第一层是 permissions.deny 和 permissions.ask：明确拒绝和明确要求提问的规则先于分类器生效，分类器改不了它们。第二层才是分类器：按 autoMode 的环境描述判断目的地算不算“内部”，再按内置规则放行或拦住。第三层是你的即时意图：只有当面、具体地说出要做的那件事，才可能覆盖一次软拒绝，泛泛的“把仓库收拾一下”不算数。

写在 permissions.allow 里的宽泛规则（例如 Bash(*)）在自动模式下会被挂起，跑完向导还会问你要不要删掉它们。强制推送、把密钥写进提交的操作，内容检查仍然会拦。默认允许推送到当前仓库任何分支、创建拉取请求，但 production、release、gh-pages 这类名字本身就是部署目标的分支不在默认覆盖范围内，分类器会按生产部署单独判断。

二、跑向导之前：先确认版本，再进项目目录

向导要在交互式终端会话里跑，云会话里跑它会直接告诉你这个环境不可用。跑之前先确认版本：

claude --version

官方文档说明：在关闭特性标志获取的会话里（如部分第三方服务商、关闭遥测的会话），/auto-mode-setup 在 v2.1.304 之前不可用，需更新到 v2.1.304 或更高版本。刚装完或刚升级完第一次进会话就提示未知命令时，先退出、开一个新会话再试。

存放位置也有坑：分类器只从用户设置 ~/.claude/settings.json、组织托管设置和 --settings 内联 JSON 里读 autoMode，不读项目目录下的 .claude/settings.json 或 .claude/settings.local.json——项目文件可能被提交、被构建步骤改动，不能让它给自己加放行规则。以前写在项目设置里的，先挪到用户设置里。

三、跑一遍向导：它读什么，草稿怎么审

在项目目录里打开 Claude Code，在提示符处输入：

/auto-mode-setup

向导会先问你这个项目是怎么用的，再给你两个可选扫描：shell 历史里每条命令的第一个词，以及你主目录下各个仓库的远端主机和仓库名。两个都是可选的，不想给就不选；选了也只是多一个线索来源，不会把完整命令历史或消息内容交给分类器。

不论选不选，向导一定会读三类来源：项目里的 CLAUDE.md、README.md、配置文件和 git 远端；已有的 autoMode 和 permissions.allow 设置；以及最近几次本项目会话中 Claude 实际跑过的命令所涉及的主机、存储桶和命令名。官方文档特意写明：它读命令名和目的地，从不读你的消息内容。所以 CLAUDE.md 里写清“平时往哪里推、用什么内部服务”，比事后补规则更管用。

如果用户设置里已有 autoMode 条目，向导会先问追加还是替换，手写规则都会保留。草稿一次性展示，接受或丢弃是整份算的：先整份接受，再打开 ~/.claude/settings.json 逐条微调。

四、写进去之后，用两条命令验证真的生效了

接受草稿不等于生效。官方文档给的验证命令是：

claude auto-mode config

它打印的是分类器实际会用的生效配置，也就是你的设置叠加默认值之后的结果。只看设置文件不够，因为默认值、组织托管设置和你自己的条目是合并在一起算的。想先看内置规则长什么样，可以再跑一条：

claude auto-mode defaults

自己手写条目后，可用 claude auto-mode critique 审一遍含糊、重复、易误拦的写法；改错了用重置命令回到内置默认值，它会先汇总、确认后再清掉用户设置里的 autoMode 一节。不想总打开设置文件，也可以在 /permissions 的 Auto mode 标签页改规则（需 v2.1.246+，托管条目只读）。

五、被拦了怎么办：先看拒绝记录，再决定补哪类规则

最常见的后续场景是：某个内部域名、包仓库或存储桶还是被拦。处理顺序应该是先看记录、再补规则，而不是先把规则放宽。打开 /permissions，切到 Recently denied 标签页，就能看到分类器拒绝过的每次操作；在被拒的操作上按 r 可以标记为重试，退出对话框后会话会告诉模型可以重试这次工具调用。

补规则前先分清被拒的是什么：整个任务都要去的目的地（内部包仓库、域名、仓库主机），补 autoMode.environment；以后都不想再被问的命令，加 allow 规则；只这一次想做，说清具体意图、让 Claude 重试即可。同一个目的地被反复拒绝，通常说明分类器缺的不是权限，而是上下文——这时再跑一次 /auto-mode-setup，或者直接把那个目的地写进环境清单，效果比放宽规则更好。

六、给推送和发布留一个人工检查点

自动模式开起来之后，最值得单独留检查点的就是推送和发布。官方文档给的最直接做法，是用 permissions.ask 写内容范围的提问规则，分别匹配以 git push 和 gh pr create 开头的命令：这类规则在自动模式下也一定会先弹提示，分类器不能替你放行。但要注意匹配边界：换一种写法写的推送命令，例如 git -C <dir> push 或 git -c <key>=<value> push，就匹配不上这条规则了。如果这条边界必须严丝合缝，就不要只靠内容匹配，改用 PreToolUse 钩子去检查完整命令文本。

分工可以这样定：环境清单交给向导维护，常规内部操作交给分类器，推送、发布、生产目标操作单独留给提问规则或钩子。最后跑一次 claude auto-mode config 确认生效，再跑一次平时最常被拦的任务验证。

参考来源