Claude Code 中的权限规则由代理运行时强制执行，而不是由模型本身强制执行。这种区别听起来比实际意义更重大。你的提示或 CLAUDE.md 中的指令塑造了 Claude 尝试做什么，但它们不改变 Claude Code 实际允许什么，如官方权限文档所明确的那样。要授予或撤销访问权限，你使用 /permissions、下面描述的设置文件、权限模式或 PreToolUse 钩子。这篇文章逐层讲解：选择模式、理解优先级、编写有效的策略文件、测试它，以及了解整个系统无法帮助你的地方。
选择权限模式
你选择的模式为其他一切设置基线。有五种。
Manual 在大多数文件编辑、shell 命令和网络调用前停止 Claude Code。你确认每一个。速度慢，但不会有意外。
Auto 将批准权交给一个分类器模型代表你审查操作。在 Pro、Max 和 Team 计划上，这是内置的起始模式，根据权限模式文档。分类器有自己的规则说明哪些操作它审查、哪些跳过，所以 auto 不等同于"批准一切"。
Accept Edits 自动批准文件操作但仍然提示 shell 命令。对于你拥有和理解的代码库的单人工作来说是合理的折衷。
Plan 完全阻止文件编辑和 shell 写入。Claude 可以读取、推理和输出计划，但不能行动。适合早期审查，当你想在任何变化前看到方法时。
dontAsk 自动拒绝任何不在你明确允许列表上的工具。没有提示，只是无声的拒绝。这是正确的模式用于 CI/CD 管道，没有人监看。
bypassPermissions 跳过所有检查。Claude 执行它想要的任何东西。在沙盒一次性环境中有用；不是针对生产版本库运行的东西。
要在 VS Code 中固定起始模式，在你的用户设置中将 claudeCode.initialPermissionMode 设置为 default、manual、acceptEdits、plan 或 bypassPermissions。注意：该设置不接受 auto。要以 Auto 开始，将其留空并从模式指示器中选择一次；扩展程序记住该选择用于后续对话。
对于终端会话，在 ~/.claude/settings.json 或托管设置中设置 permissions.defaultMode。当功能标志获取可用时，该值在 Pro、Max 和 Team 计划上应用。
一个值得知道的边界情况：如果你的组织将 claude.ai 连接器工具设置为 ask，该工具的允许规则即使在 auto 或 bypassPermissions 模式下也不生效。Claude Code 在每次调用时提示。在 dontAsk 模式下，它拒绝调用而不是提示。
规则和设置优先级如何工作
五个层级，从上到下评估。更高层级获胜。
- 托管设置 (
managed-settings.json)：IT 部署，不可覆盖。如果你的组织在此阻止 SSH，那是最终的。 - 本地设置 (
.claude/settings.local.json)：每台机器，默认 gitignored。个人或安全敏感的覆盖在这里。 - 项目设置 (
.claude/settings.json)：提交到仓库中。在该项目中跨整个团队共享。 - 用户设置 (
~/.claude/settings.json)：全局默认值，应用于每个项目，除非更高层级覆盖。 - 会话标志：
--dangerously-skip-permissions和类似的运行时参数。
管理员设置文档添加了两个值得了解的锁定控制：allowManagedPermissionRulesOnly（使托管设置成为权限规则的唯一来源，忽略用户和项目文件）和 permissions.disableBypassPermissionsMode（完全移除绕过选项）。如果你运行一个有承包商接触客户端仓库的代理机构，这两个设置结合在一起会给你一个硬上限，没有开发者能悄悄撤销。
每一层都接受三种规则类型：allow、deny 和 ask。在同一层内，deny 优先于 allow。支持 Shell 模式匹配（例如 Bash(git *)），但要精确：在测试中看起来严密的模式在实际命令字符串与你预期的不同时往往有漏洞。
文档明确标记的一点：拒绝 WebFetch 会阻止 Claude 的 fetch 工具，但如果允许 Bash，curl 和 wget 仍然可以访问任何 URL。沙箱（通过 /sandbox）在操作系统级别实施域名白名单，缩小这个漏洞。权限和沙箱覆盖不同的层，对于任何重要的情况你通常需要两者。
客户端仓库策略示例
这是一个说明性的客户端项目 .claude/settings.json，团队可以运行构建和读取数据库，但不应该接触部署脚本或密钥。这是一个代表性结构，不是复制粘贴的生产策略。
{
"permissions": {
"defaultMode": "auto",
"allow": [
"Bash(npm run build)",
"Bash(npm run test*)",
"Bash(git log*)",
"Bash(git diff*)",
"Bash(git status)",
"Read(**)"
],
"deny": [
"Bash(rm -rf*)",
"Bash(git push*)",
"Bash(kubectl*)",
"Edit(.env*)",
"Edit(deploy/**)"
]
}
}
配合这一点，每个开发者机器上的 ~/.claude/settings.json 处理个人全局信任，比如允许 curl 进行常规使用。敏感凭证或特定于机器的路径放在 .claude/settings.local.json 中，git 不会提交它。
对于 CLAUDE.md 这一方，你在其中设置约定和项目上下文而不是执行规则，代理机构 CLAUDE.md 指南详细涵盖了创作工作流。
用现实命令测试策略
将策略放在一个临时仓库中（在临时目录中执行 bare git init 可以）。然后运行一些命令来练习所有三种规则类别。目标是看哪些会提示，哪些静默执行，哪些被拒绝而不提示。
一个代表性的测试序列：
npm run build（应该自动批准，它在允许列表中）git diff HEAD~1（应该自动批准）git push origin main（应该被拒绝）rm -rf node_modules（应该被拒绝）- 编辑
deploy/内的文件（应该被拒绝） - 编辑
src/index.js（没有拒绝规则，没有显式允许：行为取决于模式） - 对外部 URL 的
curl调用（测试Bash允许规则和沙箱如何相互作用）
特别留意第 6 个案例。在 auto 模式下分类器审查它。在 dontAsk 模式下它被静默拒绝，因为它不在允许列表中。这种差异会让在一个模式下测试在另一个模式下部署的开发者感到惊讶。
如果你在此基础上添加事件级自动化（在文件保存时运行 linter，在特定工具调用时触发通知），这是钩子的问题而不是权限问题。钩子指南完整涵盖 PreToolUse 和 PostToolUse。
对于需要无人值守运行或CI集成的团队，考虑使用Claude Code代理设置从一开始就获得正确的配置基线。
托管设置和无人值守作业
当没有人在场点击"批准"时，权限模型必须完全预先声明。这指向带有托管设置中显式允许列表的dontAsk模式。
管理员设置文档将permissions.defaultMode作为此托管密钥提供。将其设置为dontAsk，然后在permissions.allow中明确列举作业需要的内容。任何未列出的内容都会被静默拒绝。这是你在管道中想要的。
官方文档为代理团队场景（其中主导会话生成队友）记录的几点：
- 队友从主导的权限设置开始。如果主导使用
--dangerously-skip-permissions运行，所有队友也是如此。 - 你可以在生成后更改单个队友模式，但不能在生成时更改。
- 队友权限提示显示在主导会话中。计划批准是设计的例外：主导授予这些而无需单独提示。
托管代理（平台级编排服务）目前处于测试阶段，根据托管代理概述。不要在没有后备方案的情况下围绕测试版功能架构生产管道。
对于permissions.disableAutoMode标志：设置它会将自动模式作为该组织中开发人员的一个选项移除。当你希望所有会话都保持在一个模式中时很有用，其中人或显式允许列表在做每个调用，而不是分类器。
权限无法保证什么
诚实的回答：相当多。
Shell模式拒绝规则不是安全边界。它们根据Claude Code构建的命令字符串进行匹配，但足够创意的提示注入或shell命令的巧妙重新表述可以产生你的模式无法捕获的字符串。权限文档是明确的：拒绝规则和沙箱覆盖不同的层。你需要两者，即使这样你也在降低风险，而不是消除风险。
bypassPermissions模式不会使允许的代码无害。如果Claude执行包含错误或执行意外操作的代码，跳过权限检查意味着"Claude决定执行"和"它发生了"之间没有门。
权限也不会审查Claude编写或执行的代码内部的内容。它安装的依赖项、它运行的脚本、它创建的文件内容：这些都不会被权限系统检查。这是一个单独的问题，更接近供应链卫生而不是运行时策略。
模型本身不是执行层。你可以编写CLAUDE.md指令说"永远不要接触生产秘密"。这些指令塑造Claude的意图。它们不会阻止配置不当的允许规则让它发生。运行时是执行层。设置文件是你配置运行时的方式。相应地对待它们。
FAQ
权限设置会自动跨机器同步吗？
不会。用户设置（~/.claude/settings.json）是本地的，每台机器各不相同。项目设置（.claude/settings.json）通过git同步。托管设置由你的IT基础设施分发。用户级文件没有内置同步；每个开发人员需要配置自己的。
开发人员可以覆盖托管设置吗？
仅在托管设置允许的范围内。如果设置了allowManagedPermissionRulesOnly，用户和项目权限规则被完全忽略。没有该标志，用户和项目设置可以添加允许规则，但它们无法覆盖托管拒绝。
权限提示在无头或CI环境中会发生什么？
在dontAsk模式中，任何不在允许列表上的内容都会被静默拒绝。不会出现提示，因为没有终端来显示一个。这是设计的。在无头环境中的auto模式中，分类器仍然运行，但如果无法解析提示（无TTY），行为取决于运行器配置。对于无人值守作业，使用带有显式允许列表的dontAsk。
权限模式对 MCP 工具的适用方式与对内置工具是否相同？
大体上是的，但有所不同。Claude Code 直接获取的 MCP 工具显示为 mcp__claude_ai_<server>__<tool>。允许和拒绝规则可以按该名称针对它们。来自你的组织设置为"始终询问"的连接器的工具会始终提示，权限模式例外，在"不询问"模式下，它们会被拒绝。
将 `.claude/settings.json` 提交到公共存储库是否安全？
该文件本身只是包含工具名称和模式的 JSON，没有机密信息。但公开的允许列表会告诉任何阅读你的仓库的人 Claude Code 将运行哪些操作而无需提示。对于开源项目，这可能没问题。对于任何专有项目，请检查你正在提交的内容。机密和 API 密钥绝不应出现在任何设置文件中；它们应该位于 Claude Code 配置外的环境变量中。
最重要的一点是：拒绝规则和沙箱解决的是不同的问题，它们互不替代。如果你在任何一个出错代价很大的环境中运行 Claude Code，请同时设置这两种方案。