Claude Code 的权限模式选错会怎样：六档各自放开了什么

先把最容易记错的一件事摆正：Claude Code 的权限模式不是四档。官方文档 code.claude.com/docs/en/permission-modes 的 Available modes 表里一共列了六个配置值，code.claude.com/docs/en/permissions 的 Permission modes 表也是同样这六个。凭印象说「就那四种」，排查时往往一开始方向就偏了。

配置值	文档写明「不问就能跑」的范围
default	只有读
acceptEdits	读、文件编辑、常见文件系统命令（mkdir、touch、mv、cp 等）
plan	读，加上 auto mode 可用时由分类器批准的命令
auto	全部，带后台安全检查
dontAsk	只有预先批准的工具
bypassPermissions	全部

default 这一档在 CLI、claude --help、VS Code 与 JetBrains 扩展、桌面端里显示的名字是 Manual，但配置值仍是 default——hooks 和 SDK 集成用的是配置值。文档写明 CLI 接受 manual 作为别名（例如 claude --permission-mode manual），但这个标签与别名需要 Claude Code v2.1.200 或更高版本。这就是第一类踩坑的来源：你在文档里搜 manual，在旧版本的配置里写 manual，两边对不上。

下面按四类现象走。

现象一：设了 defaultMode，会话却不在那个模式

怎么确认。 文档写明状态栏会显示当前模式的字样：default 显示 ⏸ manual mode on，其余分别是 ⏵⏵ accept edits on、⏸ plan mode on、⏵⏵ auto mode on、⏵⏵ don't ask on、⏵⏵ bypass permissions on。先看会话实际停在哪一档，再用一次显式指定的启动做对照：

claude --permission-mode plan

如果加了 flag 就对、不加就不对，问题在起始模式的取值链路，而不在模式本身。

文档给的处置。 终端会话的起始模式按这个顺序取第一个命中的：--permission-mode flag 或 --dangerously-skip-permissions；设置文件里的 permissions.defaultMode；内置默认值。这里有一条很容易踩的例外：文档写明 .claude/settings.json 或 .claude/settings.local.json 里的 "auto" 值不生效（Claude Code v2.1.142 及以后），并且此时 Claude Code 会改用内置默认值而不是 ~/.claude/settings.json 里的 defaultMode——要让 auto 生效得把它挪到 ~/.claude/settings.json。其它取值则任何设置文件都适用。另外，VS Code 扩展启动的会话有它自己的一套顺序，文档明确写它从不读项目的 .claude/settings.json 或 .claude/settings.local.json 来决定起始模式。

内置默认值本身也不是一个固定值。文档给了一张按「你怎么跑 Claude Code」逐行匹配的表，claude -p 与 Agent SDK 落在 default，任何设置文件把 disableAutoMode 设为 "disable" 也落在 default。内置的 auto 默认在 macOS、Linux、WSL 上需要 v2.1.228 或更高，原生 Windows 需要 v2.1.233 或更高，更早版本的内置默认是 Manual。Windows 这边默认没进 auto、同事那边进了，先核这一条。

处置后怎么验证。 起一个新会话看状态栏字样。要写成机器上所有终端会话的默认，文档给的示例是保存到 ~/.claude/settings.json：

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

什么情况说明不是这个原因。 如果模式字样已经对了、动作还是被拦，那就跟起始模式无关了。文档写明有三类控制在每一个模式里都生效，包括 bypassPermissions：deny 规则与显式 ask 规则、组织对 connector 工具设的 ask、以及标记了 requiresUserInteraction 的 MCP 工具。

现象二：切到 acceptEdits 还是不停被问

放开的到底是哪一块。 文档写明 acceptEdits 自动批准工作目录内的文件创建与编辑，外加一组文件系统 Bash 命令：mkdir、touch、rm、rmdir、mv、cp、sed（七个）。这些命令前面带安全环境变量前缀（如 LANG=C、NO_COLOR=1）或进程包装器（timeout、nice、nohup）时同样自动批准。关键限定是：只对工作目录或 additionalDirectories 之内的路径生效。

怎么确认。 拿被问的那个动作对着三件事逐条比：一是路径在不在作用域内；二是路径命不命中 protected paths；三是这条命令属不属于「除内置只读集之外的其它 Bash 命令」——文档写明后者在 acceptEdits 下仍然会问。

protected paths 是一份固定清单。文档列的受保护目录有十个：.git、.config/git、.vscode、.idea、.husky、.cargo、.devcontainer、.yarn、.mvn、.claude（.claude/worktrees 例外）。受保护文件里包含 .gitconfig、各类 shell 启动文件、.npmrc/.yarnrc 一类包管理配置、.mcp.json 与 .claude.json 等。文档写得很直接：permissions.allow 规则不会预批准 protected path 的写入，因为这项安全检查跑在 Claude Code 评估设置文件里的 allow 规则之前——所以在 ~/.claude/settings.json 里写 Edit(.claude/**) 改变不了结果。在会提示的模式下，.claude/ 写入的提示里带一个「Yes, and allow Claude to edit its own settings for this session」的选项，选它之后该会话内后续 .claude/ 写入不再提示。

Windows 侧。 启用 PowerShell 工具时，acceptEdits 也会对作用域内路径自动批准 Set-Content、Add-Content、Clear-Content、Remove-Item（四个）以及它们的常见别名，作用域与 protected path 规则不变。有一处专门写了出来：位置参数里含引号字符时仍会提示，文档举的例子是 Set-Content .\notes.txt "It's done" 里的撇号，理由是带引号与不带引号两种读法不同、无法静态校验；文档给的规避办法是改用 -Value 这类具名参数传内容。

什么情况说明不是这个原因。 如果被问的是一条命令而不是一次文件写入，先看它是不是被包装器罩住了。文档写明 watch、setsid、ionice、flock 这类 exec 包装器无法被 Bash(watch *) 这种前缀规则自动批准，find 带 -exec 或 -delete 同理；复合命令则要求每个子命令各自命中规则。这些是规则匹配层面的事，跟你切没切 acceptEdits 无关。

现象三：dontAsk 下 Claude 几乎什么都干不了

这一档的语义是：会提示你的工具调用一律自动拒绝。文档写明能跑的只有三类——命中 permissions.allow 规则的、内置只读 Bash 命令、以及被 PreToolUse hook 批准的调用。会话不会等待输入，文档给的定位是 CI 流水线与受限环境。

怎么确认。 这一档不在 Shift+Tab 的循环里，只能在启动时指定：

claude --permission-mode dontAsk

所以如果你以为自己在 dontAsk 却没这么启动，那多半不在。状态栏字样是 ⏵⏵ don't ask on。

处置。 把需要放行的动作写成 permissions.allow 规则。要注意几处文档明说的「拒到底」：命中你显式 ask 规则的调用被拒而不是提示；内置的 AskUserQuestion 工具被拒；组织设为 ask 的 connector 工具被拒；标记 _meta["anthropic/requiresUserInteraction"] 的 MCP 工具同样被拒（需要 v2.1.199 或更高），文档给的理由是它们的批准需要一个这个模式永远不会收集的回答。protected path 写入在这一档的结果是 Denied。

什么情况说明不是这个原因。 Claude Code on the web 的云端会话会忽略设置文件里的 defaultMode: "dontAsk"，文档写明是静默忽略、会话改用模式下拉里显示的那一档启动。所以云端跑出来跟本地不一样，别往 dontAsk 上找。

现象四：auto 模式下正常动作被挡

auto 的机制是另一个模型（分类器）代替你审动作。文档写明它信任你的工作目录，以及会话开始时就已经为该目录配置好的 remote；会话过程中用 git remote add 或 git remote set-url 加的或改指的 remote 不受信任（v2.1.200 之前是受信的），其余一律按外部处理，直到你配置可信基础设施。

怎么确认。 文档给了一条可执行的命令，直接把完整规则列表打成 JSON：

claude auto-mode defaults

被挡的动作会出现在 /permissions 的 Recently denied 标签下，文档写明在那里按 r 可以用手动批准重试一次。有一个例外要分清：当分类器对该动作没有产出裁决（安全检查拒了分类器自己的请求，或返回没解析成功）时，Claude Code 直接拒绝，既没有通知也不会进 Recently denied 列表。

还有一类常被误判成 bug 的。 文档写明你在对话里声明的边界会被分类器当作阻断信号：你说了「先别 push」，即使默认规则允许，匹配的动作也会被挡，而且这个边界会一直有效到你在后面的消息里解除，Claude 自己判断条件已满足并不能解除它。但边界不是规则，分类器每次检查都从对话记录里重读一遍，所以上下文压缩把那条消息挤掉之后边界就没了。要硬保证，文档指的是改用 deny 规则。

区分两种「auto 不可用」。 文档写得很明确：如果 Claude Code 报告 auto mode 不可用，说明账户没满足它列出的某项要求（计划、组织设置、模型、provider），这不是瞬时故障；而另一类消息——点名某个模型并说 auto mode「cannot determine the safety」——是分类器请求失败，通常是瞬时的。两者的处置完全不同。

什么情况说明不是这个原因。 显式 ask 规则在 auto 下仍然强制提示；组织设为 ask 的 connector 工具会跳过分类器直接提示你；标记 requiresUserInteraction 的 MCP 工具从 v2.1.199 起同样跳过分类器直接提示。这三类被问，跟分类器判断无关。另外文档写明进入 auto 时会丢弃一批过宽的 allow 规则（Bash(*)、PowerShell(*)、Bash(python*) 这类通配解释器、包管理器的 run 命令、Agent allow 规则），Bash(npm test) 这种窄规则保留，离开 auto 时被丢弃的规则会恢复——如果你发现「进了 auto 反而更爱问了」，先想到这一条。

需要说明的是，文档自己在 auto mode 一节加了警告：它减少权限提示但不保证安全，适用于你信任大方向的任务，不能替代对敏感操作的审查。

bypassPermissions 也不是全放开

这一档跳过权限提示与安全检查，包括对 protected paths 的写入。但文档列了仍然会提示的几项：显式 ask 规则、组织设为 ask 的 connector 工具、标记 requiresUserInteraction 的 MCP 工具（需要 v2.1.199 或更高）；针对文件系统根目录或家目录的删除（如 rm -rf /、rm -rf ~）作为熔断仍会提示，命令里含 $(...)、反引号或 <(...) 这类替换形式时同样触发；跨会话消息的两条保护也仍然生效。

文档写明你不能从一个启动时没启用它的会话进入这一档，只能在启动时用设置或 flag：

claude --permission-mode bypassPermissions

--dangerously-skip-permissions 与之等价。首次以这一档启动交互式会话时会有一次责任确认，接受后写入用户设置、之后不再出现；拒绝则退出。非交互模式没有这一步，用 --bg 启动的后台会话在你没有于交互式会话里接受过之前会被拒绝。

Linux 与 macOS 侧有一条 Windows 上没有对应说明的检查：以 root 或 sudo 运行时，Claude Code 拒绝以这一档启动，报错原文是

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

在被识别的 sandbox 内该检查会自动跳过。文档在这一节反复强调只在容器、VM、无外网的 dev container 这类隔离环境里用，并写明它对提示注入与意外动作不提供防护；管理员可以用 managed settings 里的 permissions.disableBypassPermissionsMode 设为 "disable" 来封掉它。

最后：什么情况说明根本不是模式的问题

翻完模式表还是对不上号时，按这几条排除，它们都在模式之外：

• 规则顺序。文档写明按 deny → ask → allow 求值，第一个命中的决定结果，规则的具体程度不改变顺序。所以 Bash(aws *) 的 deny 会盖掉 Bash(aws s3 ls) 的 allow。
• bare 工具名的 deny 会把工具从上下文里移除，Claude 根本看不见它（EndConversation 是例外）。这种情况下你看到的现象是「它压根不用这个工具」，而不是「被拒绝」。
• hook。退出码为 2 的 PreToolUse hook 在权限规则求值之前就终止调用，即使有 allow 规则也一样。
• 规则写在了不被消费的工具上。文档写明文件路径只按 Edit(path) 与 Read(path) 规则检查，写成 Write(...)、NotebookEdit(...)、Glob(...) 的路径规则会被接受但从不查阅，并在启动时告警（需要 v2.1.210 或更高）。
• 工具名对不上。规则与 hook matcher 只匹配规范名，文档举的例子是转录里显示为 Stop Task 的工具规范名其实是 TaskStop。

以上命令与配置片段均按官方文档中的写法与参数语义引用，未经实测，以官方文档与 --help 的实际输出为准。

---

本文依据 Claude Code 官方文档（code.claude.com/docs）于 2026-08-17 的公开内容整理。 该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。 该产品迭代频繁，文中涉及的命令、配置项与默认值随版本变动，请以官方文档最新内容为准。 本文不涉及价格、额度与限流的具体数值，相关信息请以官方定价与用量说明页为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。