Claude Code /permissions：谁能干什么，你说了算

什么是 /permissions

用 Claude Code 的时候，你一定遇到过这种情况：

Claude Code 想跑一条 npm install，弹窗问你”允许吗？”
你点了允许，过一会儿它又要跑 npm test，又弹窗问你
一个任务下来，你可能要点十几次”允许”

另一个极端是，你受不了频繁弹窗，直接开了 bypass permissions 模式——但又隐隐不安，万一它跑了什么危险命令呢？

/permissions 就是解决这个问题的。 它让你精细控制 Claude Code 每一个工具的权限：哪些操作可以自动放行，哪些操作必须拦下来问你，哪些操作直接禁止。

不多不少，刚刚好。

权限系统的基本概念

在深入 /permissions 之前，先理解 Claude Code 的权限模型。

三种行为

每一条权限规则对应三种行为之一：

行为	含义
allow	自动放行，不弹窗
deny	直接拒绝，Claude Code 不会执行
ask	强制弹窗，即使在宽松模式下也要问你

规则格式

权限规则的格式是 工具名 或 工具名(内容)：

Bash                    → 允许/拒绝/询问 所有 Bash 命令
Bash(npm install)       → 只针对 "npm install" 这条命令
Bash(npm:*)             → 所有以 "npm" 开头的命令（前缀匹配）
Bash(npm *)             → 同上，通配符写法
Edit                    → 所有文件编辑操作
mcp__server1            → 某个 MCP 服务器的所有工具
mcp__server1__tool1     → MCP 服务器的某个具体工具

规则来源

权限规则可以来自多个地方，后面的覆盖前面的：

来源	文件路径	说明
User	`~/.claude/settings.json`	全局规则，影响所有项目
Project	`<项目>/.claude/settings.json`	项目级，可提交 Git 共享
Local	`<项目>/.claude/settings.local.json`	项目级本地，已 gitignore
CLI	`--allowedTools` 等命令行参数	临时指定
Managed	企业托管设置	企业管理员下发，优先级最高
Session	当前会话中你的选择	只在本次会话有效

怎么用 /permissions

在 Claude Code 交互模式下输入：

/permissions

会弹出一个交互式面板，列出当前生效的所有权限规则。别名是 /allowed-tools。

在这个面板里你可以：

查看所有 allow、deny、ask 规则，以及它们来自哪个配置源
删除不再需要的规则
重试被拒绝的操作——如果之前某个操作被 deny 了，你可以在这里解除限制并重试

在 settings.json 中配置权限

/permissions 面板适合查看和删除规则。但如果要批量添加规则，直接编辑 settings.json 更高效。

基本结构

{
  "permissions": {
    "allow": ["Bash(npm:*)", "Bash(git:*)", "Edit", "Read", "Glob", "Grep"],
    "deny": ["Bash(rm -rf:*)", "Bash(sudo:*)"],
    "ask": ["Bash(git push:*)"]
  }
}

allow 规则示例

{
  "permissions": {
    "allow": [
      "Bash(npm:*)",
      "Bash(npx:*)",
      "Bash(node:*)",
      "Bash(git:*)",
      "Bash(ls:*)",
      "Bash(cat:*)",
      "Bash(echo:*)",
      "Bash(mkdir:*)",
      "Bash(cp:*)",
      "Bash(mv:*)",
      "Edit",
      "Write",
      "Read",
      "Glob",
      "Grep",
      "WebFetch",
      "WebSearch",
      "Agent",
      "TodoWrite",
      "mcp__github"
    ]
  }
}

这组规则的效果是：

常见的开发命令（npm、git、node、文件操作）自动放行
文件读写和搜索工具自动放行
GitHub MCP 服务器的所有工具自动放行
其他未列出的操作仍然会弹窗询问

deny 规则示例

{
  "permissions": {
    "deny": ["Bash(rm -rf:*)", "Bash(sudo:*)", "Bash(curl * | sh:*)", "Bash(wget * | sh:*)"]
  }
}

这组规则直接禁止了危险操作：递归删除、sudo 提权、从网上下载脚本并执行。

ask 规则示例

{
  "permissions": {
    "ask": ["Bash(git push:*)", "Bash(git checkout:*)", "Bash(docker:*)"]
  }
}

这些命令即使在宽松模式下也会弹窗确认——推代码、切分支、操作 Docker 这些你可能想自己过目。

通配符匹配详解

权限规则支持三种匹配方式：

精确匹配

Bash(npm install)

只匹配 npm install 这一条命令，npm install express 不匹配。

前缀匹配（:* 语法）

Bash(npm:*)

匹配所有以 npm 开头的命令：npm install、npm test、npm run build 都会匹配。

这是最常用的写法。冒号后面的 * 表示”后面的内容随便是什么”。

通配符匹配（* 语法）

Bash(git * --force)

* 可以放在任意位置，匹配任意内容。上面的规则会匹配 git push --force、git push origin main --force 等。

如果你的规则以 空格 + * 结尾（比如 git *），那么 git 本身也会匹配——这和前缀匹配的行为一致。

MCP 工具匹配

mcp__github              → GitHub MCP 服务器的所有工具
mcp__github__*           → 同上，通配符写法
mcp__github__create_pr   → 只匹配 create_pr 这一个工具

权限模式

除了规则之外，Claude Code 还有全局的”权限模式”，决定了没有规则匹配时的默认行为：

模式	行为
default	标准模式。读操作自动放行，写操作和命令执行弹窗询问
plan	规划模式。Claude Code 先制定计划再执行，执行前弹窗
acceptEdits	接受编辑模式。文件编辑自动放行，Bash 命令仍然询问
bypassPermissions	跳过权限。所有操作自动放行（危险，谨慎使用）

权限模式可以在 /config 里切换，也可以在 settings.json 里设置默认值：

{
  "permissions": {
    "defaultMode": "default"
  }
}

权限判断流程

当 Claude Code 要执行一个工具时，权限检查的完整流程是：

工具调用请求
    ↓
输入校验（validateInput）
    ↓
PreToolUse Hooks 检查
    ↓
权限规则匹配
  ├── 命中 deny 规则 → 拒绝
  ├── 命中 allow 规则 → 放行
  ├── 命中 ask 规则 → 弹窗
  └── 无规则匹配 → 看权限模式
    ↓
弹窗让你选择
  ├── Allow Once → 本次放行
  ├── Allow Always → 加入 allow 规则
  └── Deny → 拒绝
    ↓
工具级别检查（checkPermissions）
    ↓
执行

注意几个关键点：

deny 规则优先于 allow 规则——如果同一个操作同时命中了 allow 和 deny，deny 生效
Hooks 在规则之前检查——hooks 可以拦截甚至修改工具调用
弹窗选择 “Allow Always” 会自动写入规则——下次同样的操作就不会再问了

实用技巧

技巧一：先宽后严

刚开始用 Claude Code 时，不必急着配置权限。先用默认模式，观察 Claude Code 日常需要哪些操作。等你积累了经验，再根据自己的需求逐步添加 allow 和 deny 规则。

弹窗里选 “Allow Always” 就是最简单的添加方式——用着用着，你的权限规则就自然丰满了。

技巧二：分层管理

全局规则（~/.claude/settings.json）—— 放你在所有项目都需要的通用规则，比如 Edit、Read、Glob、Grep
项目共享规则（.claude/settings.json）—— 放团队统一的项目级规则，比如允许项目特定的构建命令
个人本地规则（.claude/settings.local.json）—— 放你个人的偏好，比如允许某些只有你在用的工具

技巧三：善用 deny 作为安全网

即使你的 allow 规则很宽松，也建议加几条 deny 规则作为兜底：

{
  "permissions": {
    "deny": ["Bash(rm -rf /)", "Bash(sudo:*)", "Bash(:(){ :|:& };:)"]
  }
}

deny 规则优先于一切，是你最后一道防线。

技巧四：用 /permissions 排查权限问题

如果 Claude Code 总是做不了某个操作，或者不该做的操作它做了，打开 /permissions 看看当前生效的规则列表。每条规则都标注了来源（user / project / local / session），方便你定位问题出在哪个配置文件。

安全建议

不要在共享的项目 settings.json 里放过于宽松的 allow 规则——团队成员的环境不同，你信任的命令在别人那里可能有风险
定期用 /permissions 检查规则列表——随着时间推移，你可能积累了一些不再需要的 allow 规则
企业环境用 managed settings——管理员可以通过托管设置强制 deny 某些操作，确保合规
bypassPermissions 模式只在你完全信任当前任务时使用——它会跳过所有弹窗，包括危险操作

写在最后

权限管理看起来是个”麻烦事”，但其实是你和 AI 合作的信任基础。

如果每次都弹窗，你会被打断，效率降低；如果完全不弹窗，你会担心，用得不安心。好的权限配置是让你既流畅又安心的关键——该自动的自动，该拦截的拦截。

花十分钟把常用操作加到 allow 列表，把危险操作加到 deny 列表，然后你就可以专注于真正重要的事情——让 Claude Code 帮你写代码，而不是一直在点”允许”。