Claude Code 权限设置：允许、询问与拒绝规则

这篇适合谁，读完能做到什么

如果你在团队里用 Claude Code，想让它在哪些操作上自动放行、哪些操作必须先问你、哪些操作绝对不能做，这篇适合你。读完你能写出一份 permissions 配置，知道 allow、ask、deny 三类规则的先后顺序，并能判断某条规则到底能不能拦住它想拦的命令。^[1]

权限是怎么分层的

Claude Code 用分层的权限系统，在效率和安全之间取平衡。只读操作，比如读文件和 Grep，在工作目录和附加目录内不需要批准。Bash 命令、修改文件、WebFetch 和 WebSearch 则需要批准，只有一小部分内置的只读命令例外。^[1]

权限规则可以检入版本控制，让团队里的每位开发者共享同一套规则，同时每个人也能各自定制。^[1]

批准时选「不再询问」会发生什么

当你对某条 Bash 命令或某个 WebFetch 域名选择「Yes, and don't ask again」，Claude Code 会把这条规则永久保存到 git 仓库根目录下的 .claude/settings.local.json。以后在同一仓库的任何会话里，这条规则都会生效。^[1]

如果你批准的是一条复合命令，比如 git status && npm test，Claude Code 不会保存整条命令的规则，而是为每个需要批准的子命令分别保存一条。上面的例子会保存 npm test 的规则。^[1]

有些提示只提供一次性批准，没有「不再询问」选项。这是因为 Claude Code 只在提示能完整展示授权范围时才提供持久选项。遇到这种提示，只能一次一次地批准。^[1]

三种规则：allow、ask、deny

allow 让 Claude Code 无需手动批准就能使用某个工具；ask 每次使用时都会弹出确认；deny 则直接禁止使用。^[1]

判断顺序固定为：先 deny，再 ask，最后 allow，第一个匹配的规则决定结果。规则写得是否具体，不会改变这个顺序。^[1]

这意味着，宽泛的 deny 规则优先级高于更具体的 allow 规则。例如 Bash(aws *) 会拦住所有 aws 命令，包括同时匹配 Bash(aws s3 ls) 这条允许规则的调用。allow 规则无法从 deny 规则里挖出例外。ask 与 allow 之间也是同样的道理。^[1]

如果在 deny 里直接写工具名，比如 Bash，这个工具会从 Claude 的上下文中整个移除，Claude 根本看不到它。^[1]

还要记住一点：权限规则是由 Claude Code 执行的，而不是由模型执行的。你在提示词或 CLAUDE.md 里写的内容只影响 Claude 想做什么，并不改变 Claude Code 允许什么。要授予或撤销权限，应该用规则、权限模式或 PreToolUse hook。^[1]

规则怎么写

规则的格式是 Tool 或 Tool(specifier)。写 Bash 或 Bash(*) 会匹配所有 Bash 命令；加上括号里的 specifier 可以缩小范围，例如 Bash(npm run build) 只匹配这一条确切命令，Read(./.env) 只匹配当前目录下的 .env 文件。^[1]

Bash 规则里的 * 可以匹配任意文本，包括空格；没有 * 的规则只匹配一条确切的命令。^[1]

* 要放在子命令之后。规则里第一个 * 之前的词决定了规则的范围，所以 Bash(git log *) 只放行 git log 类的命令，而不是所有 git 子命令。^[1]

末尾是 *（前面有空格）的规则也会匹配不带参数的命令本身：Bash(ls *) 既匹配 ls，也匹配 ls -la，但不匹配 lsof。如果去掉空格写成 Bash(ls*)，lsof 也会被匹配。^[1]

复合命令和 Bash 规则的边界

复合命令只有在每一个子命令都被允许时才会免提示执行。Bash(safe-cmd *) 不会放行 safe-cmd && other-cmd。Claude Code 能识别的分隔符包括 &&、||、;、|、|&、& 和换行。^[1]

deny 和 ask 规则只要有任一子命令匹配就会生效，包括嵌套在子 shell 或命令替换里的命令。^[1]

还要注意，Bash 规则匹配的是 Claude 写出的命令文本，它不是安全边界。例如 Bash(curl *) 能拦住 curl https://example.com，却拦不住 /usr/bin/curl，也拦不住 sh -c 'curl ...'。想真正限制文件访问，应该用 Read 和 Edit 规则。^[1]

一份入门配置

下面这份配置允许 npm run 和 git commit 免提示执行，并直接拒绝 git push：

``json { "permissions": { "allow": [ "Bash(npm run *)", "Bash(git commit *)" ], "deny": [ "Bash(git push *)" ] } } ``^[1]

这份配置拒绝的是以 git push 开头的命令。换一种写法，比如 git -C . push，就不会被这条规则匹配到。所以它是一道常规防线，而不是强制边界。^[1]

文件路径怎么匹配

Read 和 Edit 规则使用 gitignore 风格的路径模式。//path 表示从文件系统根目录开始的绝对路径，~/path 表示从用户主目录开始，/path 相对于设置文件所在的来源，path 或 ./path 相对于当前目录。^[1]

要特别注意：/Users/alice/file 不是绝对路径，前面的单斜杠指向的是设置来源。写绝对路径要用双斜杠，即 //Users/alice/file。^[1]

Read(path) 形式的 deny 规则还会阻止 Edit 和 Write 工具改写同一路径，包括在该路径下新建文件。^[1]

工作目录、MCP 与子 agent

默认情况下，Claude 可以访问你启动它的目录里的文件。想扩大范围，可以在启动时加 --add-dir，在会话中用 /add-dir，或者在设置文件的 additionalDirectories 里长期配置。^[1]

MCP 工具的规则写作 mcp__<server>__*，表示某个服务器的全部工具；写 mcp__<server>__<tool> 则只匹配其中一个。子 agent 也能控制，Agent(Explore) 和 Agent(Plan) 分别匹配对应的子 agent。^[1]

项目规则与工作区信任

项目 .claude/settings.json 里的 permissions.allow 和 additionalDirectories 会授予实际能力，所以只有你在工作区信任对话框里接受了这个文件夹，它们才会生效。这一点对团队很重要：别人提交的仓库可能带着 allow 规则，你应该在信任之前先看清楚。^[1]

托管设置与优先级

组织的管理员可以部署托管设置，用户和项目设置无法覆盖它。托管设置的优先级最高，任何其他层级，包括命令行参数，都不能覆盖托管的权限规则。^[1]

只要某个工具在任一层级被拒绝，其他层级就无法再允许它。例如托管设置里的 deny 无法被 --allowedTools 覆盖。^[1]

如果希望托管设置成为唯一的权限规则来源，可以启用 allowManagedPermissionRulesOnly，这样其他设置来源的权限规则都会被忽略。^[1]

常见问题

**bypassPermissions 模式会怎样。** 这个模式会跳过权限提示，包括对 .git 和 .claude 这类受保护路径的写入。不要在不受隔离的环境里使用。想禁止它，可以在设置文件里把 permissions.disableBypassPermissionsMode 设为 "disable"；想禁止 auto 模式，则设置 permissions.disableAutoMode。这两项在托管设置里最有用。^[1]

**/permissions 能看到什么。** 这个对话框列出所有权限规则，以及每条规则来自哪个 settings.json 文件。你可以在 Claude 工作时打开它，增删规则会从 Claude 的下一次工具调用开始生效。^[1]