Claude Code 提供了六种权限模式，控制你对 AI 操作的审批粒度。选错模式要么被弹窗烦死，要么不小心执行了不该执行的命令。本文逐一拆解每种模式能做什么、怎么工作、以及各自的坑。

模式速览

1. default —— 最安全，最啰嗦

表现

每次工具调用都弹窗让你审批：[Allow] [Deny] [Always allow]。你对 AI 的每一步有完全的掌控权。

适用场景

• 初次使用 Claude Code，想看看它到底会做什么

• 在生产环境操作，不敢有丝毫闪失

• 对 AI 还不信任的阶段

优点

• 零意外：任何操作都要你点头

• 建立肌肉记忆后，你能逐渐了解"哪些操作可以信任"

• 没有分类器开销，没有额外 API 费用

缺点

• 极度打断心流：写 10 行代码可能弹 15 次窗

• 长时间工作后会「审批疲劳」→ 开始机械点 Allow → 安全意识麻痹

• 不适合长时间无人值守的任务

2. acceptEdits —— 日常开发甜点区

表现

文件读取、写入、编辑自动放行。Shell 命令和网络请求依然弹窗。

内部机制

它维护了一个「安全 Shell 命令白名单」——纯读操作（ls、cat、git status、git log、grep、find等）自动放行；有副作用的命令仍然弹窗。changelog 显示这个白名单在持续扩充，比如lsof、pgrep、tput、ss等都陆续被加入。

适用场景

• 日常写代码的主力模式

• 本地开发，项目跑在你自己机器上

• 需要 AI 频繁读写文件但不想它随意执行命令

优点

• 文件操作零摩擦——写代码不再被打断

• Shell 层面仍有安全护栏

• 没有额外 API 调用的延迟和费用

• 可以通过permissions.allow按需放行特定命令（如Bash(npm test)）

缺点

• 频繁跑测试、装依赖、启动服务 → 还是会被弹窗轰炸

• 只信任「当前工作目录」内的文件操作——出了这个范围照弹不误

• 白名单之外的安全命令（如某些自定义工具）每次都要批

3. auto —— AI 当保安

表现

文件操作自动放行。Shell 命令和网络请求交给一个AI 分类器判断：安全就放行，危险就拦截。

内部机制

这是六种模式里最复杂的，值得展开讲：

决策管道（四层）：

操作请求 ├─ ① 内置白名单 + 用户 allow 规则 → 直接放行 ├─ ② 项目内文件 Write/Edit → 直接放行（不经过分类器，省延迟） └─ ③ Transcript Classifier（AI 分类器）→ 判断放行还是拦截

分类器的两阶段评估：

分类器的四级拦截体系：

关键安全设计：

• 分类器是独立模型（Claude Sonnet 4.6），跟你的主会话模型无关

• 分类器看不到工具执行结果——只看到用户消息 + 工具名/参数。恶意文件内容无法操控它

• 还有一个输入层 probe在工具输出进入上下文之前扫描 prompt injection

降级保护：

• 连续 3 次拦截 → 暂停 auto mode，回退到手动审批

• 累计 20 次拦截 → 同上

• 非交互模式（claude -p）→ 直接中止会话

适用场景

• 长时间无人值守的编码任务（比如「把这个 PR review 完并修好所有问题」）

• 信任 AI 的判断，但不想完全裸奔

• 有autoMode.environment配置了信任边界的团队项目

优点

• Shell/网络操作也能自动处理，真正解放双手

• 有安全护栏，不是无脑放行

• 自定义规则灵活（可以写autoMode.allow/soft_deny/hard_deny）

• 拦截后有审计记录，可在/permissions查看

缺点

• 每次 Shell/网络操作增加 API 调用的延迟（分类器要跑一次推理）

• 额外 token 费用（分类器调用也算钱，虽然 Stage 2 基本命中缓存）

• 分类器不是 100% 准确——实测有 0.4% 误杀 + 17% 漏过

• 项目内文件写入绕过分类器（Tier 2 盲区）——恶意文件内容不会被拦截

• 需要 Anthropic API 的 Sonnet 4.6——第三方端点（Bedrock/Vertex/DeepSeek 等）可能不可用

• 比 bypassPermissions 慢，比 acceptEdits 贵

4. bypassPermissions —— 全自动，零护栏

表现

一切操作自动放行。不弹窗，不走分类器，什么都不问。

内部机制

权限检查在入口处直接短路返回 "允许"。相当于你永久按住了[Always allow]按钮。

适用场景

• 完全隔离的沙箱/容器环境，炸了也无所谓

• 你自己写的个人玩具项目

• 确定不会执行任何危险操作的场景

优点

• 零摩擦，AI 可以火力全开

• 无额外延迟，无额外费用

• 适合长任务全自动运行

缺点

• 没有任何安全网——AI 执行rm -rf /你连提示都看不到

• AI 可能被 prompt injection 操控执行恶意命令

• 代码 review 是你唯一的防线（事后检查 git diff）

• 误操作成本极高

5. dontAsk —— 静默拒绝

表现

allow 列表里的放行；不在列表里的直接拒绝，不弹窗问你。

内部机制

类似default但把「未匹配」的默认行为从"弹窗"改成了"拒绝"。

适用场景

• 只想让 AI 用一组预定义的安全工具（比如只读探索代码）

• 给 AI 的能力做极窄的约束

• CI/CD 场景，不能有交互弹窗

优点

• 行为完全可预测——AI 只能做你白名单里的事

• 零弹窗，适合非交互环境

• 安全性最高（仅次于 plan）

缺点

• 白名单之外的操作直接失败，AI 无法向你求助

• 容易出现「我想帮你做 X 但我没有权限」的死循环

• 白名单维护成本高——忘加一个常用命令就卡住

6. plan —— 只读，最严格

表现

只能读，不能写。允许 Read、Glob、Grep、WebSearch 等只读操作，禁止一切修改和命令执行。

内部机制

跟其他模式不同，plan 不是简单的权限过滤，它还会改变系统 prompt——告诉模型「你现在在 plan mode，不能执行修改操作」。

适用场景

• 设计方案阶段的探索

• 审查陌生代码库

• 让 AI 帮你分析问题但不能动手改

优点

• 完全不会改你的代码，零风险

• AI 知道自己被限制了，会调整回答策略

• 适合用来「先看看 AI 会怎么想」再做决定

缺点

• AI 无法执行任何验证操作（不能跑测试、不能试运行）

• 分析结论可能基于「猜测」而非「实测」

• 如果确实需要改代码，得退出 plan mode 重新来

决策指南：我该用哪个？

你在干什么？ │ ├─ 初次使用 / 在生产环境 / 对 AI 不信任 │ └─ default │ ├─ 日常写代码，需要 AI 改文件但要审批命令 │ └─ acceptEdits + permissions.allow 放行常用命令 │ ├─ 长时间无人值守任务，信任 AI 但想有安全网 │ └─ auto（前提：你的 API 端点支持 Sonnet 4.6） │ ├─ 隔离沙箱 / 个人玩具项目 / 确定安全 │ └─ bypassPermissions │ ├─ 只让 AI 做预定义操作，非交互环境 │ └─ dontAsk │ └─ 设计方案 / 审查代码 / 只看不改 └─ plan

进阶：组合使用

你不是只能选一种模式。Claude Code 支持多层配置叠加：

{ "permissions": { "defaultMode": "acceptEdits", "allow": [ "Bash(npm test)", "Bash(npm run build)", "Bash(git diff *)", "Bash(git log *)" ], "deny": [ "Bash(rm -rf *)", "Bash(git push --force *)" ] } }

这样你的实际体验是：

• 文件读写自动放行（acceptEdits）

• npm test、git log等自动放行（allow 规则）

• rm -rf、git push --force直接拒绝（deny 规则）

• 其他命令弹窗问你

常用 allow 规则建议（放到acceptEdits模式下）：

"allow": [ "Bash(npm *)", "Bash(npx *)", "Bash(python *)", "Bash(git status)", "Bash(git diff *)", "Bash(git log *)", "Bash(git branch *)", "Bash(grep *)", "Bash(find *)" ]

总结

没有「最好」的模式，只有适合你当前场景的组合。大多数日常开发用acceptEdits+ 精心维护的 allow 列表就足够了——既不会被打断到崩溃，也不会裸奔失控。