1. Auto Mode 默认开启后为什么你的 settings.json 需要先动刀Claude Code 从 8 月 14 日起在 Pro、Max、Team 套餐的新会话里默认进入 Auto Mode。这件事对日常写代码的人意味着什么简单说以前每次工具调用都要弹窗问你「允不允许」现在很多操作会先过一道分类器看起来合理的直接放行只有不可逆、破坏性、越界的动作才会拦下来。省事是真省事但如果你项目里没设边界翻车也会更快。我先把一个常见误解说清楚Auto Mode 不是「模型觉得合理就全自动」也不是关掉所有审批。它的实际流程是三步——先匹配你在 settings.json 里配的 deny / ask / allow 规则没命中规则的交给 Auto Mode 分类器判断分类器连续拦 3 次或单会话累计拦 20 次会退回手动审批模式。官方说法是分类器针对「不可逆、破坏性、超出当前环境」的操作做拦截。适用范围也要分清这次变更是 Pro / Max / Team 新会话的默认行为。Enterprise、Claude API、Bedrock、Vertex、Foundry 等平台暂时仍是 opt-in企业管理员可以先用 managed settings 评估。如果你已经在~/.claude/settings.json里设了defaultMode可能收到一次性切换提示但可以拒绝团队管理员在 managed settings 里 pin 了默认模式组织策略优先。所以这篇要解决的核心问题是默认行为变了之后怎么用 settings.json 里的 permissions 和 CLAUDE.md 把本地规则收敛住。我建议你先改这 4 条规则10 分钟能搞定挡住大部分低级事故。关键是分清哪些写进 settings.json 才能强制执行哪些写进 CLAUDE.md 只是给模型看的行为指引——这两者混为一谈是 Auto Mode 下最容易踩的坑。2. 前置准备TaoToken 接入与 Claude Code 环境确认在动 settings.json 之前先把接入层理顺。Claude Code 本身是个客户端它要连到模型服务才能干活。我这边用的是 TaoToken 的接入方式官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 这个地址不加 UTM。你需要先拿到 API Key。进控制台的 API Keys 页面创建一个建议按项目分 Key别一个 Key 到处用。创建入口在 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。拿到 Key 之后配置到 Claude Code 的环境变量里通常是ANTHROPIC_API_KEY和ANTHROPIC_BASE_URL这两个。如果你还没装 Claude Code先确认 Node 版本够用然后全局装。装完之后跑一次claude --version确认能起来。这一步别跳过因为后面所有 settings.json 的验证都依赖客户端能正常启动。环境确认清单我列一下你对着过一遍检查项命令 / 位置期望结果Claude Code 版本claude --version能输出版本号API Key 已配置环境变量ANTHROPIC_API_KEY非空接入地址环境变量ANTHROPIC_BASE_URL指向 https://taotoken.net/api用户级配置目录~/.claude/目录存在项目级配置目录项目根.claude/按需创建这里有个细节用户级配置在~/.claude/settings.json项目级在.claude/settings.json。项目级的可以提交给团队共享但注意defaultMode: auto写在项目级会被忽略——这是官方防止仓库给自己提权的设计。想锁定模式写在用户级。3. 规则一文件和目录边界写进 settings.json 才拦得住这条最容易写错。很多人在 CLAUDE.md 里写一句「禁止修改 .env」以为就安全了。实际上 CLAUDE.md 里的这类话只是建议Claude Code 不会据此拦截。真正能挡住的是permissions.deny和permissions.ask规则。我试过把敏感文件全塞进 deny效果立竿见影。配置骨架如下你可以直接抄{ permissions: { deny: [ Edit(./.env), Edit(./.env.*), Edit(./.github/workflows/**), Edit(./package-lock.json), Read(./.env), Read(./.env.*) ], ask: [ Edit(./**) ], allow: [ Edit(./src/**), Edit(./docs/**), Read(./**) ] } }路径规则用Edit(path)和Read(path)别写Write(path)——官方文档明确说 Write 规则不参与文件权限检查配了也不生效。这个坑我踩过当时配了一堆 Write 规则结果一个都没拦住排查半天才发现是规则名的问题。deny 和 ask 的区别要理解清楚deny 是直接拒绝ask 是弹窗问你。allow 是直接放行。三者的优先级是 deny ask allow。所以上面这段配置的效果是.env 和 CI 配置完全不能碰package-lock.json 不能改其他文件默认要问但 src 和 docs 下的编辑直接放行。CLAUDE.md 里可以补一句「只改 src/ 和 docs/」帮模型少做无用功但安全边界靠 settings不靠 markdown。这句话我再强调一遍因为它是 Auto Mode 下最核心的认知。4. 规则二命令白名单allow / ask / deny 分开写Auto Mode 下allow 规则在分类器之前生效。但有个反直觉的点像Bash(python:*)这种宽泛的「任意代码执行」规则在 Auto Mode 里会被暂时搁置避免绕过分类器。所以别指望一条Bash(*)就万事大吉。我的做法是把只读和写操作拆开危险命令用 ask 或 deny。配置骨架{ permissions: { allow: [ Bash(npm test:*), Bash(npm run lint:*), Bash(npm run build:*), Bash(git status:*), Bash(git diff:*), Bash(git log:*) ], ask: [ Bash(git push:*), Bash(git commit:*), Bash(npm install:*), Bash(rm:*) ], deny: [ Bash(git push --force:*), Bash(sudo:*) ] } }这里有个必须显式写的点Auto Mode 分类器默认可能放行推送到当前仓库各分支的git pushproduction、gh-pages 等部署分支除外。如果你希望 push 必须先问你必须在 ask 里显式写上Bash(git push:*)不能光靠「我相信模型不会推」。我实测下来不写这条分类器确实会放行普通分支的 push。规则放哪也有讲究~/.claude/settings.json是个人全局.claude/settings.json是项目级可提交给团队。用/permissions命令可以查看当前生效的规则这个命令在排查时特别好用。更狠的拦截可以用用户级autoMode.hard_deny它不可被 allow 覆盖跑claude auto-mode defaults可以看内置规则再定制。5. 规则三任务描述带验收标准写进 CLAUDE.md这条管的是模型行为不是权限系统。Auto Mode 下模糊需求更容易跑偏因为模型有了更多自主权。我在 CLAUDE.md 里要求任务按工单格式描述包含范围、验收标准、禁止改动项。CLAUDE.md 里的骨架长这样## 任务格式 每个任务需包含范围、验收标准、禁止改动项。 示例 - 任务给 UserList 补空状态 UI - 范围只改 src/components/UserList.tsx 及同目录样式 - 验收列表为空显示「暂无数据」不改接口逻辑npm test -- UserList 通过写得越像工单Agent 越少「自由发挥」。这类规则放 CLAUDE.md 或.claude/rules/合适但别指望它能替代上面的 settings.json。权限是硬边界行为指引是软约束两者配合才完整。我自己的习惯是每个任务开头先写清楚「只改哪个文件」再写「怎么算做完」。这样即使 Auto Mode 放行了某些操作模型也不会跑到无关文件上去。6. 规则四完成前跑验证行为约束加脚本Agent 说「做完了」不代表真的能跑。这条是行为约束加脚本的组合。我在 package.json 里加统一验证入口再在 CLAUDE.md 里写死完成定义。package.json 里加{ scripts: { verify: npm run lint npm test -- --runInBand } }CLAUDE.md 里写## 完成定义 - 声称任务完成前必须执行 npm run verify - verify 失败则继续修复不要停下来问「要不要提交」这和规则三一样是行为指引。如果真要硬拦截得配合 PreToolUse hook 或在 ask 里卡住git commit/git push别混为一谈。我见过有人把完成定义写进 settings.json 的 permissions 里那是不生效的因为 permissions 只管工具调用权限不管任务流程。7. 验证请求怎么确认规则真的生效了配置写完不算完得验证。我一般分三步走。第一步跑/permissions命令看当前生效的规则列表。你应该能看到 deny、ask、allow 三组规则都在里面。如果某条规则没出现说明路径写法有问题或者放错了配置文件层级。第二步故意让 Claude 试一个该被拦的操作。比如让它改.env文件看它是不是被 deny 挡住。如果它还能改说明规则没生效回去检查是不是写成了Write(./.env)而不是Edit(./.env)。第三步试一个该被 ask 的操作比如git push。看它是不是弹窗问你。如果直接放行了说明 ask 规则没写对或者被 allow 规则覆盖了。验证通过的标志是deny 的操作直接报错拒绝ask 的操作弹窗等待allow 的操作直接执行。三者行为清晰可辨就说明配置到位了。如果你在验证过程中遇到模型调用报错可以先到模型对话页面确认 Key 和接入地址是否正常https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的参数说明。8. 本篇常见错排查配置过程中最容易踩的坑我整理成对照表你遇到问题直接查现象可能原因排查动作deny 规则不生效写成了Write(path)改成Edit(path)或Read(path)defaultMode 不生效写在了项目级 settings.json移到用户级~/.claude/settings.jsongit push 没被拦ask 里没显式写Bash(git push:*)补上这条规则宽泛 Bash 规则失效Auto Mode 搁置了任意代码执行规则拆成具体命令白名单规则看不到配置文件层级放错用/permissions确认生效来源分类器频繁退回手动连续拦 3 次或累计 20 次检查是否有规则过严适当放宽 allow还有一个隐蔽的坑项目级.claude/settings.json里写defaultMode: auto会被忽略。这是官方防止仓库给自己提权的设计不是 bug。想显式开 Auto Mode写在用户级配置里或者会话中用 ShiftTab 切换。default是手动审批acceptEdits自动接受文件编辑plan只规划不改代码auto显式开启 Auto Mode。这四个模式的区别要记清楚切换时别搞混。9. 长期编码与 Agent 场景的配置建议如果你是把 Claude Code 当长期编码助手用或者跑 Agent 任务配置思路要再往前走一步。长期场景下权限规则会反复触发配得太严会频繁打断配得太松又容易出事。我的建议是分层日常编辑用 allow 放行 src 和 docs提交和推送用 ask 卡住破坏性命令用 deny 彻底封死。这样既不会每改一个文件就弹窗又能在关键节点保留人工确认。如果你跑的是长时间 Agent 任务可以考虑 Coding Plan 这类方案把模型调用和权限管理分开处理https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。它的思路是让 Agent 在受控环境里跑权限边界由外层配置管模型专注干活。Claude Code 往 Auto Mode 默认开方向很清楚Agent 会越来越像能自己干活的同事。同事好用前提是公司有制度。settings.json 管硬边界CLAUDE.md 管做事方式两样都得有。8 月 14 日之前花 10 分钟把这几条规则过一遍比事后救火划算得多。最后提醒一句示例规则请按团队实际安全要求调整别直接照搬。每个项目的敏感文件、部署流程、命令习惯都不一样规则要贴合自己的仓库。跑claude auto-mode defaults看看内置规则再在此基础上定制是最稳的起点。