claude code的auto权限机制的原理是什么

比如你让 Claude Code“修复测试”，它准备跑测试，通常可以继续；但如果它突然要强制推送分支，或者把敏感数据传到外部服务，auto 就可能拦下来。你说“修测试”，不等于授权它做所有相关操作。 它的核心是：主模型负责提出操作，独立的分类器模型负责审核权限，Claude Code 的执行层负责真正放行或阻断。不是简单地“自动点击允许”，也不只是让主模型自己判断自己安不安全。 按当前官方文档，可以拆成三层理解。 第一层：先过确定性的权限规则 工具调用先经过权限系统。显式 deny 规则直接阻止；显式 ask 规则仍然要求你确认，auto 不能替你批准。 已有的窄范围 allow 规则也可能直接放行，所以并不是所有工具调用都必然再跑一遍分类器。auto 会暂停部分过宽的授权，比如允许任意 Bash 命令的规则，避免整套审核被架空。 第二层：分类器结合上下文做语义审核 需要审核的操作会交给另一个模型。它结合用户请求、待执行操作、相关对话、项目指令和可信环境配置，判断： 这个动作是不是超出了你的授权？ 有没有破坏性或数据外泄风险？ 目标是不是可信仓库、域名或基础设施？ 是不是被读到的恶意内容诱导了？ 所以它不是只检查命令里有没有 rm、curl 这样的关键词。同一个操作，授权和目标不同，结果可以不同。 官方给的例子是：“清理仓库”不代表允许 force push；明确要求“强制推送这个分支”，才可能解除对应的软拦截。 第三层：放行，或把拒绝反馈给主模型 审核通过才执行；被拒绝后，主模型会收到反馈，尝试其他做法。持续被拦截时，可能再转成人工确认，而不是偷偷执行。 这里还有个容易混淆的点：分类器内部也有 hard_deny、soft_deny、allow 等自然语言策略。所谓 hard_deny，是要求分类器无条件阻止，不代表它变成了不会出错的程序规则。需要确定性禁止的操作，应放在前面的 permissions.deny 里。 因此，auto 和另外两种机制的区别是： bypassPermissions：主要是跳过权限审批。 auto：把很多人工审批交给模型审核。 sandbox：限制执行后实际能访问哪些文件和网络资源。 auto 管“该不该执行”，sandbox 管“执行后能碰到什么”，两者可以叠加。分类器仍可能误放或误拦，所以 auto 是降低风险，不是安全保证，也会增加一些推理开销和延迟。 官方文档： https://code.claude.com/docs/en/auto-mode-config https://code.claude.com/docs/en/permission-modes