1. 为什么 Claude Code 的命令权限值得单独治理Claude Code 在终端里跑起来之后最让人又爱又怕的一点就是它会主动执行命令。你让它「跑一下测试」它可能直接npm run test你让它「看看改动」它可能git diff加git status连着来。默认情况下这些命令大多会弹一次确认你按回车它才执行。可一旦你手快选了「一直允许」或者团队里有人图省事加了跳过确认的启动参数后面就会变成某些命令它自己就跑了你甚至没看清它到底执行了什么。这就是命令权限要解决的问题。Claude Code 的权限体系不是靠一个开关而是靠三层规则加两个配置文件叠出来的交互式的/permissions命令负责日常查看和增删settings.json负责项目级和用户级的持久化规则settings.local.json负责本机私有、不进 git 的那部分。三者配合才能做到「该自动的自动、该拦的拦、该问的问」。我试过在几个不同规模的项目里配这套东西最深的感受是权限规则写得好Claude Code 就像一个懂规矩的结对伙伴写不好它要么每步都烦你要么悄悄干了你不希望它干的事。这篇就按「先看懂规则从哪来 → 再动手配 → 最后验证生效」的顺序拆开讲配置片段都可以直接复制。适合谁看已经在用 Claude Code 做日常开发、想让自动执行更可控的人团队里要统一权限规范、又不想把个人偏好提交进仓库的人以及被--dangerously-skip-permissions坑过一次、想搞清楚规则到底怎么生效的人。先记住一个核心结论ask 的优先级高于 allowdeny 的优先级最高。也就是说一条命令即使同时命中 allow 和 ask它还是会问你只要命中 deny无论 allow 怎么写都不会执行。理解这个优先级后面所有配置都不会乱。2. /permissions 交互式查看与增删规则/permissions是 Claude Code 里管理命令权限最顺手的方式没有之一。你在对话里直接输入/permissions回车它会列出当前生效的所有规则按 allow、deny、ask 分组展示并且标注每条规则来自哪个配置文件。这一点很关键——当你发现某条命令行为不符合预期时第一件事就是来这里看它到底命中了哪条规则、规则又是从哪加载的。交互界面里你可以直接选中某条规则删除也可以新增。新增的时候它通常给你几个选项允许一次、允许这类命令、始终允许、拒绝。选「始终允许」时它会把规则写进合适的配置文件而不是只存在内存里。删除同理删掉之后这条命令会恢复成默认的询问行为。这里有个容易忽略的点/permissions展示的是合并后的最终规则集不是单个文件的内容。所以如果你在项目里配了 allow在用户级配了 deny界面上会同时看到并且能看出 deny 压过了 allow。排查「为什么这条命令不执行」时先看 deny 分组里有没有它。规则本身的写法是「工具名(匹配模式)」的形式。命令类权限基本都走Bash(...)括号里是命令前缀匹配。比如Bash(npm run test:*)匹配所有以npm run test开头的命令Bash(git status)精确匹配git statusBash(rm -rf:*)匹配rm -rf开头的危险命令冒号加星号:*是前缀通配表示「这个前缀后面接任何参数都算命中」。不带:*就是精确匹配整条命令。这个区别很实用Bash(git status)只放行git status本身Bash(git status:*)会连git status --short一起放行。日常操作建议这样走先用/permissions看现状发现某条常用命令每次都要确认就在交互界面里把它加进 allow发现某条命令不该自动跑就加进 deny 或 ask。改完不用重启规则即时生效。等你摸清了哪些规则该长期保留再考虑把它们固化到配置文件里让团队或未来的自己直接复用。需要提醒的是/permissions适合「边用边调」但它不负责版本管理。真正要跨会话、跨机器稳定生效的规则还是得落到settings.json和settings.local.json里。下一节就讲这两个文件的分工。3. settings.json 与 settings.local.json 的分层配置Claude Code 的权限配置分两个层级、三个文件位置理解它们的覆盖关系是配好权限的前提。用户级配置在~/.claude/settings.json对你本机所有项目生效。适合放那些「我走到哪都希望这样」的规则比如永远 deny 掉rm -rf、永远 allowgit status。项目级配置在项目根目录的.claude/settings.json只对当前项目生效通常会提交进 git让团队共享同一套规则。本地项目级配置在.claude/settings.local.json同样只对当前项目生效但不提交 git适合放个人偏好或者带敏感路径的规则。覆盖关系是这样的项目级会覆盖用户级里同名的规则settings.local.json又覆盖项目级。也就是说优先级从高到低是settings.local.json 项目.claude/settings.json 用户~/.claude/settings.json。但注意allow/deny/ask 三个数组是分别合并的不是整个文件替换。你在用户级 allow 了git status项目级 deny 了git status最终这条命令会被 deny因为 deny 优先级最高。下面是一份可以直接复制的项目级.claude/settings.json片段路径就是项目根目录下的.claude/settings.json{ permissions: { allow: [ Bash(npm run test:*), Bash(npm run lint:*), Bash(git status:*), Bash(git diff:*), Bash(git log:*) ], deny: [ Bash(rm -rf:*), Bash(git push --force:*), Bash(curl:* | sh) ], ask: [ Bash(git push:*), Bash(npm publish:*), Bash(docker:*) ] } }这份配置的意图很清楚测试、lint、只读的 git 查询自动跑删除、强推、管道执行远程脚本一律禁止推送、发布、docker 操作每次都要问。团队共享这份文件大家的底线就一致了。个人偏好放.claude/settings.local.json比如你本机有个特殊的构建脚本路径不想让别人也继承{ permissions: { allow: [ Bash(./scripts/local-build.sh:*) ], deny: [ Bash(rm -rf /Users/yourname/tmp:*) ] } }用户级~/.claude/settings.json则放跨项目的通用规则{ permissions: { allow: [ Bash(git status:*), Bash(ls:*), Bash(cat:*) ], deny: [ Bash(rm -rf:*), Bash(sudo:*) ] } }如果你用的是支持 TOML 的配置场景等价写法是[permissions] allow [Bash(npm run test:*), Bash(git status:*)] deny [Bash(rm -rf:*), Bash(sudo:*)] ask [Bash(git push:*)]配好之后如果你还要接第三方模型或网关来跑 Claude Code记得把三件套对齐Base URL、Key、Model ID。比如通过兼容 Anthropic 协议的接入方式时Base URL 填https://taotoken.net/apiKey 在控制台生成Model ID 按你选的模型填。这三者任何一个不对权限配得再细也跑不起来。生成 Key 的入口在 API Keys接入细节可以对照 接入文档。4. 用一次命令触发验证 allow 与 deny 是否生效配置写完不算完得验证。最直接的办法是构造一条同时能命中 allow 和 deny 的命令看 Claude Code 的实际反应。先验证 allow。在项目里对 Claude Code 说「跑一下测试」如果.claude/settings.json里配了Bash(npm run test:*)它应该直接执行npm run test不再弹确认。你可以在终端看到命令输出整个过程没有「是否允许」的提示。这就说明 allow 生效了。再验证 deny。让它执行rm -rf ./tmp因为 deny 里有Bash(rm -rf:*)它应该直接拒绝不会执行也不会问你。你会看到类似「该命令被权限规则拒绝」的反馈。这一步很关键——deny 是硬拦截不是询问所以不会有「要不要继续」的选项。最后验证 ask 的优先级。假设你 allow 里放了Bash(git push:*)ask 里也放了Bash(git push:*)让它执行git push origin main。按优先级ask 高于 allow所以它应该弹确认而不是自动执行。如果你看到确认提示说明优先级理解正确。验证时可以用一个对照表快速核对预期行为命令allow 命中deny 命中ask 命中预期行为npm run test是否否自动执行rm -rf ./tmp否是否直接拒绝git push origin main是否是弹确认git status是否否自动执行如果实际行为和预期不符先回到/permissions看合并后的规则确认没有更高优先级的文件覆盖了你的配置。常见情况是用户级 deny 了一条命令项目级 allow 了同一条结果还是被 deny——这不是 bug是优先级设计。验证通过后这套规则就可以稳定用了。团队协作时把.claude/settings.json提交进仓库.claude/settings.local.json加进.gitignore各人本机偏好互不干扰。5. 常见报错与排查401、local proxy failed、reading choices、OAuth权限配好之后实际跑起来还可能撞上几类报错。这些报错大多和权限规则本身无关而是接入层或认证层的问题但很容易被误判成「权限没配好」。401 未授权。典型表现是命令还没执行就报认证失败。这通常不是 allow/deny 的问题而是 Key 无效、过期或者 Base URL 和 Key 不匹配。排查顺序先确认 Key 是从控制台正常生成的再确认 Base URL 填的是https://taotoken.net/api注意不要多加路径最后确认 Model ID 是当前可用的。三件套里任何一个错位都会 401。如果你在settings.json里配了环境变量引用检查变量名有没有拼错。local proxy failed。这个报错一般出现在你本机有网络层拦截或端口占用时。先确认没有其他进程占着 Claude Code 要用的本地端口再检查系统代理设置是否干扰了本地回环地址。注意这里说的是本机网络配置排查不涉及任何跨境网络工具。把本地代理关掉或放行127.0.0.1通常能解决。reading choices 相关报错。这类报错往往出现在模型返回结构不符合预期时比如网关返回的响应格式和 Claude Code 期望的不一致。排查时先确认你用的接入方式兼容 Anthropic 协议再确认 Model ID 没有写成一个不存在的名字。如果换了模型后突然出现多半是模型名不对。OAuth 相关报错。如果你用的是需要 OAuth 的登录方式报错通常指向 token 过期或回调地址不匹配。重新走一遍授权流程确认回调地址和配置里写的一致。如果同时配了 API Key 和 OAuth注意两者不要混用选一种认证方式走通即可。排查时有个通用思路先看报错发生在「命令执行前」还是「命令执行中」。执行前报错基本是认证或接入问题执行中报错才可能是权限规则或命令本身的问题。用这个二分法能省很多时间。另外如果你在配置里同时用了settings.json和settings.local.json排查时记得两个文件都看。有时候是本地文件里一条旧规则在作怪而项目文件里已经改好了。/permissions界面会标注每条规则的来源文件善用这个信息。6. 把权限规则沉淀成团队规范权限治理的终点不是配一次就完事而是让它变成团队里稳定运转的一部分。我的做法是项目级.claude/settings.json只放那些「所有人都该遵守」的底线规则比如 deny 掉删除和强推、allow 掉只读查询和测试。个人偏好、本机路径、临时放行全部丢进.claude/settings.local.json并且确保它在.gitignore里。这样带来的好处是新同学 clone 项目后权限底线自动生效不用每个人重新踩一遍坑。而每个人又保留了自己的调整空间不会因为别人的偏好被迫改变习惯。如果你还在用 Coding Plan 做长期编码或 Agent 任务权限规则的价值会更明显——任务跑得越久、自动执行的命令越多一套清晰的 allow/deny/ask 就越像安全带。需要长期跑编码任务的话可以从 Coding Plan 了解适合的接入方式想先验证模型对话行为用 模型对话 试几条命令的权限反应也很直观。最后留一个实用习惯每次调整完权限规则用第 4 节那张对照表跑一遍四条命令确认 allow、deny、ask 的行为都符合预期。这个动作花不了一分钟但能避免「以为配好了、结果某条命令悄悄自动执行」的情况。权限这东西验证过才算数。