旧教程常用 Bash(npm run *) 演示规则，但这个范围也会匹配项目里的发布脚本。减少弹窗之前，应先看将被允许执行的脚本内容。
从当前规则开始，不要直接覆盖文件
在 Claude Code 中输入 /permissions，查看已有规则及各自来源。个人只在当前项目使用的配置可放 .claude/settings.local.json；需要团队共享的非秘密设置放 .claude/settings.json。手工创建本地文件时，把它加入 .gitignore。已有文件则合并 permissions 字段，保留其他配置。设置文件说明
本例在一个没有重要文件的测试目录进行，需要先在同一终端确认 node --version 可以运行。它演示 Bash 工具的匹配；如果会话实际调用的是 PowerShell 工具，应按 /permissions 显示的工具名与对应语法设置，Bash 规则不会自动覆盖另一个工具。
用三个无害命令理解规则
先以 Manual 模式进行这次练习：终端启动命令为 claude --permission-mode default。将下列内容合并进该测试目录的本地设置：
{
"permissions": {
"allow": ["Bash(node --version)"],
"ask": ["Bash(node -v)"],
"deny": ["Bash(node --help)"]
}
}
在对话中分别要求通过 Bash 执行这三条命令，每次只执行一条：
| 请求 | 没有其他冲突规则时的预期 | 应保留的证据 |
|---|---|---|
node --version |
无需手工批准后运行 | 实际工具名、命令、版本输出 |
node -v |
先显示询问 | 询问界面及规则来源 |
node --help |
被拒绝执行 | 拒绝记录，不能只有模型说不执行 |
这些是预期行为，本文没有运行 Claude 客户端验证。不要用真实删除、推送或发布命令测试拒绝是否生效。练习完成后移除本例三条测试规则，保留原文件中的其他规则。
当同一调用匹配多个类别时，评估顺序为 deny → ask → allow；更具体的 allow 不能覆盖匹配的 deny。可以临时把同一条 Bash(node --version) 加入 deny，检查其变成拒绝，再还原。若结果不符，查看是否换了工具、命令形式、工作目录或权限模式。规则与匹配文档
再为真实项目设置必要命令
假设你已读过 package.json，确认 test 和 build 只做预期的本地工作，才可考虑：
{
"permissions": {
"allow": ["Bash(npm test)", "Bash(npm run build)"],
"ask": ["Bash(git commit *)"],
"deny": ["Bash(git push *)"]
}
}
这里的 allow 不是对所有 npm 操作开放；加参数的命令也可能不匹配。构建脚本本身可以被修改，所以命令名不构成永久安全保证。项目更新脚本或加入生命周期钩子后，应重看执行内容。
Bash(git push *) 拒绝的是匹配的命令文本，并非对 Git 程序的一切调用方式都封锁。真正需要隔离生产网络或文件写入时，应结合运行环境、凭证和沙箱能力，而非堆几条字符串规则后声称“绝不会发布”。
权限模式决定默认处理方式
| 当前模式 | 本教程中的用法 |
|---|---|
default，界面标为Manual |
新手验证明确允许、询问、拒绝的行为 |
plan |
先探索和制定改动方案，不直接编辑源文件 |
acceptEdits |
适合已准备好接受本地文件编辑的阶段；并不等于仅只读 |
其他模式是否可用取决于当前环境和组织设置；不要为了消除一个正常权限提示就切换到绕过权限的模式。遇到组织策略限制时，应先识别来源，个人设置不能被当作已覆盖组织限制的证据。
当前版本支持多数 settings 变更热重载；修改权限后再用 /permissions 核对，必要时运行 claude doctor 看配置错误。/status 的 Setting sources 能说明加载了哪些设置来源，但不是每一个配置键最终值的追踪表。只有具体工具调用结果，才能证明本次规则与预期一致。
资料来源
- Claude Code权限规则
规则优先级、模式、命令匹配与权限界限。
- Claude Code设置文件
配置作用域、加载来源和热重载。
下一步
继续阅读与你当前问题相关的教程：
