2026-04-08 /permissions 白名单：比 Auto 更细的一层权限控制

今晚主题

/permissions 白名单：比 Auto 更细的一层权限控制。

完整学习原文

核心一句话

把高频且低风险的操作提前授权，Claude Code 才能少打断你，但边界仍然在你手里。

原文

今晚主题：/permissions 白名单：比 Auto 更细的一层权限控制。

昨天讲的是“Plan 之后接 Auto 会更顺”，那再往前走一步，就是把常做、低风险的动作提前放进白名单。这样 Claude Code 不会因为跑测试、改文档、执行常见 npm 脚本一遍遍打断你；但像删远程分支、乱翻凭证这种高风险动作，边界还是留在你手里。它的感觉有点像：不是把钥匙整串交出去，而是只配几把常用钥匙。

最小例子就是在 /permissions 里加：Bash(npm run *)、Bash(npx vitest *)、Edit(/docs/**)。这样日常开发会顺很多，尤其是测试—改代码—再测这一串循环。

今晚记住的一句话：Auto 是“让它更省心”，/permissions 是“让省心发生在你画好的边界里”。

教程整理版

1. 先理解它解决的不是“能不能做”，而是“要不要每次都问”

/permissions 的价值，不在于给 Claude Code 更多能力，而在于把已经确定安全、而且会反复发生的动作提前授权。这样做的结果是：

• 常见测试命令不用反复确认；
• 文档类改动不用频繁被打断；
• 日常开发链路更顺，尤其是“改一点 → 跑一下 → 再改”的高频循环。

所以它更像一套低风险动作白名单，不是一键放权。

2. 和 Auto 模式的关系：一个偏省心，一个偏边界

可以这样理解：

• Auto：更像“执行时尽量少打扰你”，重点是流程顺滑；
• /permissions：更像“你先画好边界，再允许它在边界里顺滑执行”；
• 逐次确认：最稳，但摩擦最大；
• 完全跳过权限：风险高，不适合日常默认使用。

如果你已经接受了 Auto 的工作方式，那下一步就该学会用 /permissions 把“省心”限制在自己认可的范围内。

3. 最适合放进白名单的动作

判断标准就三条：高频、低风险、结果可预期。

典型适用场景：

• 重复执行的测试命令；
• 常见的构建/校验脚本；
• 某些固定目录下的文档编辑；
• 团队里人人都会执行、且已经形成共识的安全操作。

如果一个命令虽然常见，但一旦出错代价很大，比如删除远程资源、发布生产环境、读取敏感凭证，那就不应该因为“经常用”而直接放进白名单。

4. 配置思路：先小后大，不要一口气放太宽

更稳妥的做法是：

1. 先从最常用的一两类操作开始；
2. 观察几天是否真的减少了打断；
3. 确认没有误放权后，再逐步补充；
4. 任何涉及敏感资源的规则，宁可继续手动确认。

这套策略的核心不是“尽量多配”，而是“只配那些值得配的”。

5. 常见误区

误区一：为了省事，把范围写太大

例如把 Bash 权限写得过于宽泛，短期看少了弹窗，长期看等于把原本该审一眼的动作也放过去了。

误区二：把低频高风险动作混进去

像远程删除、发布、生产库相关操作，即使偶尔会重复，也不建议纳入白名单。

误区三：把“打断我”误判成“这个动作就安全”

有些动作让人烦，不代表它真的适合自动通过。真正该放行的是稳定、可预期、可复盘的操作。

代码/命令示例

最小可复盘示例

/permissions
Bash(npm run *)
Bash(npx vitest *)
Edit(/docs/**)

这个示例在表达什么

• Bash(npm run *)：允许执行常见 npm 脚本；
• Bash(npx vitest *)：允许反复跑测试；
• Edit(/docs/**)：允许改动 docs 目录下的文档文件。

这类配置适合“前端/Node 项目 + 文档频繁维护”的常见开发节奏。

一个实用的落地原则

先只放你最近 3 天里最常重复、且你几乎每次都会点允许的动作。不要一开始就想着“把以后可能用到的全配上”。

今晚记住的一句话

Auto 是“让它更省心”，/permissions 是“让省心发生在你画好的边界里”。