为 Claude Code 选择合适的权限模式

使用 Claude Code 的时候，一个很常见的体验是：Claude 每做一个操作前都会弹出一个确认框，问"可以吗？"。这对敏感操作来说是好事，但如果只是想让 Claude 安安静静地重构一大段代码，这些反复弹出的确认框就会让人有点烦躁。

为了解决这个问题，Claude Code 提供了几种不同的权限模式。每种模式对应着不同的自主程度------从完全监督到完全放手，中间还有几个过渡选项。用户可以根据当前任务的性质，随时切换模式。

权限模式一览

模式	Claude 无需询问就能做的事	适合场景
default	读取文件	刚开始使用、敏感操作
acceptEdits	读取和编辑文件	边审阅边迭代代码
plan	读取文件（不能编辑）	探索代码库、规划重构方案
auto	所有操作，但带有后台安全检查	长时间运行的任务、减少重复确认
bypassPermissions	所有操作，没有任何检查	仅限隔离的容器或虚拟机
dontAsk	只有预先批准的工具	锁定的受限环境

切换权限模式的方法

在不同环境下切换模式的方式略有差异，但总的来说有三种途径：会话中切换、启动时指定、设为默认值。

在命令行界面（CLI）中，按 Shift+Tab 可以在 default → acceptEdits → plan → auto 之间循环切换。当前模式会显示在状态栏里。需要注意的是，auto 模式不会出现在这个循环中，除非启动时加了 --enable-auto-mode 参数。而且 auto 模式还需要 Team 套餐（或后续开放的 Enterprise/API 套餐）以及 Claude Sonnet 4.6 或 Opus 4.6 模型的支持，所以即使加了参数也可能不可用。

启动时可以通过命令行参数直接指定：

claude --permission-mode plan

如果想给某个会话设定一个默认模式，可以在设置文件中配置：

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

非交互式运行（比如脚本或 CI 环境）也可以用同样的参数：

claude -p "重构认证模块" --permission-mode acceptEdits

需要特别说明的是，dontAsk 模式永远不会出现在 Shift+Tab 的循环中。bypassPermissions 模式只有通过 --permission-mode bypassPermissions、--dangerously-skip-permissions 或 --allow-dangerously-skip-permissions 启动后，才会出现在循环里。

有一点很重要：在聊天框里直接对 Claude 说"别问了，直接做"并不会改变权限模式。必须通过上面这些明确的方式来切换。

default 模式：适合日常使用

default 模式是 Claude Code 的默认行为。在这个模式下，Claude 可以自由读取文件，但任何修改操作------编辑文件、运行 shell 命令、发起网络请求------都需要用户确认。这是一个比较平衡的起点，适合大多数日常开发场景，尤其是当用户还不完全确定 Claude 会做什么的时候。

acceptEdits 模式：信任编辑，谨慎执行命令

acceptEdits 模式把信任范围扩大到了文件编辑。Claude 可以直接修改代码文件，不再弹出确认框。但是运行 shell 命令、网络请求等操作仍然需要用户批准。

这个模式适合的场景是：用户正在审阅 Claude 的代码改动，觉得方向是对的，不太需要每个文件改动都点一次确认，但还想对命令执行保持控制。

plan 模式：先研究，再动手

plan 模式的设计思路是"先规划，后执行"。在这个模式下，Claude 会进行研究、探索代码库、提出澄清问题，并写出一份计划文件------但不会对实际源代码做任何修改。权限确认的机制和 default 模式一样，用户仍然需要批准那些需要确认的命令和操作。

什么时候用 plan 模式

plan 模式在以下几种情况下特别有用：

• 多步骤实现：一个功能需要修改多个文件，先看看整体方案
• 代码探索：只想先了解一下代码库，不做任何修改
• 交互式开发：和 Claude 反复讨论方向，直到方案成熟

如何使用 plan 模式

有两种方式进入 plan 模式。一是在提示词前加上 /plan 前缀，让 Claude 仅对这一次请求进入计划模式；二是通过 Shift+Tab 把整个会话切换成 plan 模式。也可以在启动时指定：

claude --permission-mode plan

一个典型的使用流程是：用户输入"我们需要把认证系统重构为 OAuth2，请制定一个详细的迁移计划"。Claude 会分析现有实现，生成一份计划。用户可以继续追问"向后兼容性怎么处理？""数据库迁移怎么做？"来细化方案。当计划准备好后，Claude 会展示计划并询问下一步。此时用户可以选择：

• 批准并切换到 auto 模式执行
• 批准并接受编辑（acceptEdits 模式）
• 批准但逐个手动审阅每个改动
• 继续完善计划（把反馈发回给 Claude 再改一轮）

每个"批准"选项都附带有"先清空计划上下文"的选项，方便开始新的任务。

auto 模式：后台分类器代替人工确认

auto 模式是目前最智能的权限模式。它让 Claude 可以执行操作而不显示权限确认框，但每个操作在真正执行前，都会由一个独立的分类器模型在后台进行安全评估。

可用性说明：auto 模式在 Team 套餐上可用，Enterprise 和 API 支持即将推出。在 Team 和 Enterprise 中，管理员需要在 Claude Code 的管理设置中先启用该功能，用户才能使用。它要求使用 Claude Sonnet 4.6 或 Claude Opus 4.6 模型，不适用于 Haiku、claude-3 系列或第三方提供商（如 Bedrock、Vertex、Foundry）。

分类器如何工作

每个操作都会经过一个固定的决策流程，命中第一个匹配项后即停止：

1. 匹配用户自定义的 allow 或 deny 规则的，直接按规则处理
2. 只读操作和当前工作目录内的文件编辑，自动批准
3. 其他所有操作，交给分类器判断
4. 如果分类器判定为阻止，Claude 会收到阻止原因，并尝试其他方案

分类器会读取用户消息和工具调用作为输入，但会剥离 Claude 自己的文本输出和工具结果。这意味着，即使某个文件或网页中包含了恶意内容，也无法直接操纵分类器。分类器还会收到项目中的 CLAUDE.md 内容，因此项目指令中描述的操作会被纳入"允许"或"阻止"的考量。

与基于规则匹配的权限系统不同，分类器读取的是用自然语言描述的"阻止什么、允许什么"------它在上下文中推理操作的安全性，而不是简单匹配语法。

进入 auto 模式时发生了什么

当用户切换到 auto 模式时，Claude Code 会临时丢弃那些已知可能授予任意代码执行的 allow 规则，例如：

• 无限制的 shell 访问：Bash(*)
• 通配符形式的脚本解释器：Bash(python*)、Bash(node*)
• 包管理器的运行命令
• 任何 Agent 层面的 allow 规则

这些规则如果保留，会在分类器看到操作之前就自动批准那些最可能造成破坏的命令和子代理调用。像 Bash(npm test) 这样精确限定的规则则会保留。当用户退出 auto 模式后，被丢弃的规则会恢复。

auto 模式如何处理子代理

当 Claude 生成一个子代理时，分类器会在子代理启动前评估委托的任务。如果一个任务描述本身就看起来很危险（例如"删除所有匹配此模式的远程分支"），会在生成时就被阻止。

在子代理内部，auto 模式以与父会话相同的阻止和允许规则运行。子代理自己在其 frontmatter 中定义的任何 permissionMode 都会被忽略。子代理自身的工具调用会独立地经过分类器检查。

当子代理结束时，分类器会审查其完整的操作历史。一个在生成时看起来无害的子代理，可能在中途因为读取了某些内容而被"劫持"。如果返回检查发现了问题，子代理的结果前会加上一条安全警告，主代理可以根据这个警告决定如何继续。

默认情况下分类器阻止什么

默认配置下，分类器信任当前工作目录，以及（如果项目在 git 仓库中）该仓库配置的远程地址。除此之外的一切都被视为"外部"：公司的源码控制组织、云存储桶、内部服务等，在用户告知分类器之前都是未知的。

默认阻止的操作：

• 下载并执行代码，例如 curl | bash 或从克隆的仓库中运行脚本
• 向外部端点发送敏感数据
• 生产环境部署和迁移
• 云存储上的批量删除
• 授予 IAM 或仓库权限
• 修改共享基础设施
• 不可逆地删除会话开始前就已存在的文件
• 破坏性的源码控制操作，如强制推送或直接推送到 main 分支

默认允许的操作：

• 当前工作目录内的本地文件操作
• 安装已在 lock 文件或清单中声明的依赖
• 读取 .env 文件并将凭据发送到与之匹配的 API
• 只读的 HTTP 请求
• 推送到会话开始时所在的分支，或 Claude 自己创建的分支

如果想查看分类器接收到的完整默认规则列表，可以运行 claude auto-mode defaults 命令。

如果 auto 模式阻止了某个团队内部很常见的操作（比如推送到自己组织的仓库、写入公司存储桶），通常是因为分类器不知道那些目标是可信的。管理员可以通过 autoMode.environment 设置添加受信任的仓库、存储桶和内部服务。

当 auto 模式触发回退机制

为了防止误判阻断整个会话，auto 模式设计了回退机制：一次错误的阻止只会让 Claude 重试一次，而不是让用户卡住。如果分类器连续 3 次阻止同一个操作，或者在同一个会话中累计阻止了 20 次操作，auto 模式会暂停，Claude Code 恢复为每个操作都弹出确认框。这两个阈值不可配置。

在命令行界面中，用户会在状态栏区域看到通知。如果批准了被阻止后弹出的确认操作，拒绝计数器会重置，用户可以继续留在 auto 模式中。

在非交互式模式（-p 参数）下，由于没有用户可以被询问，会话会直接中止。

反复出现的阻止通常意味着两种情况：要么任务确实涉及分类器被设计来阻止的操作，要么分类器缺少关于可信基础设施的上下文，把安全操作误判为风险。如果看起来是误判，或者分类器漏掉了本应捕捉的操作，可以通过 /feedback 报告。

dontAsk 模式：只允许预先批准的工具

dontAsk 模式是最严格的模式------它会自动拒绝所有没有明确允许的工具。只有匹配 /permissions allow 规则或 permissions.allow 设置的操作才能执行。如果一个工具有明确的 ask 规则，也会被拒绝（而不是弹出提示框）。这使得该模式完全非交互，非常适合 CI 流水线或受限环境，用户可以预先定义好 Claude 被允许做的每一件事。

claude --permission-mode dontAsk

bypassPermissions 模式：跳过所有检查

bypassPermissions 模式会禁用所有权限提示和安全检查。每个工具调用都会立即执行，没有任何验证。

⚠️ 只在隔离环境中使用：这个模式应该仅在容器、虚拟机或没有互联网访问权限的开发容器中使用，确保 Claude Code 无法对宿主机系统造成损害。

claude --permission-mode bypassPermissions

--dangerously-skip-permissions 参数与 --permission-mode bypassPermissions 等价：

claude -p "重构认证模块" --dangerously-skip-permissions

bypassPermissions 模式对提示注入或意外操作没有任何保护。如果需要更安全的替代方案，同时保持后台安全检查，应该使用 auto 模式。管理员可以通过在托管设置中设置 permissions.disableBypassPermissionsMode 为 "disable" 来阻止用户使用这个模式。

各模式对比

下表总结了每种模式在审批方式上的主要差异（plan 模式因为限制的是 Claude 能做什么，而非审批方式如何工作，所以未列入）：

	default	acceptEdits	auto	dontAsk	bypassPermissions
权限提示	文件编辑和命令都需要	仅命令需要	无（除非触发回退）	无，不符合预允许则阻止	无
安全检查	用户逐项审查	用户审查命令	分类器审查命令	仅限预定义的允许规则	无
Token 用量	标准	标准	较高（分类器调用）	标准	标准

进一步自定义权限

权限模式设定了基准的审批行为。如果需要更精细地控制单个工具或命令，可以在当前模式之上叠加额外的配置。

权限规则是第一道可定制的防线。可以在设置文件中添加 allow、ask 或 deny 条目，用于预批准安全的命令、强制对危险操作弹出提示，或完全阻止某些工具。规则在除 bypassPermissions（它完全跳过权限层）之外的所有模式中都会生效，并且按工具名称和参数模式进行匹配。

**钩子（Hooks）**可以覆盖那些模式匹配规则无法表达的逻辑。PreToolUse 钩子在每个工具调用之前运行，可以根据命令内容、文件路径、时间段或外部策略服务的响应来决定 allow、deny 或升级。PermissionRequest 钩子会拦截权限对话框本身，并代为回答。

相关文档

• 权限管理：权限规则的语法、托管策略
• 钩子：自定义权限逻辑、生命周期脚本
• 安全机制：安全防护和最佳实践
• 沙箱：Bash 命令的文件系统和网络隔离
• 非交互模式 ：使用 -p 参数以编程方式运行 Claude Code