大多数开发者真正想要的不是“给 Claude Code 所有权限”，而是让它在可信范围内连续工作，又不被每个文件修改和命令打断。对普通本地仓库，较稳妥的起点是 Auto mode 加明确的 deny/ask 规则，再用沙箱限制文件和网络范围。bypassPermissions 不应成为解决弹窗疲劳的默认答案。
两种模式都会显著减少确认提示，但它们交出的权力并不相同：Auto mode 把逐次判断交给另一个分类器；bypassPermissions 则关闭普通权限提示和安全检查，让工具调用立即执行。后者只适合已经由容器或虚拟机把损害范围压缩到可接受程度的场景。
先看清两种模式实际改变了什么
| 判断维度 | Auto mode | bypassPermissions |
|---|---|---|
| 谁判断动作能否执行 | 独立分类器根据当前请求、环境和风险规则判断 | 普通权限层不再逐次判断 |
| 日常权限弹窗 | 通常没有；显式 ask 规则仍会要求确认 | 通常没有；仍存在少量产品级例外 |
| 危险动作 | 分类器会拦截超出请求、未知基础设施、破坏性操作或疑似恶意内容驱动的动作 | 不提供针对 prompt injection 或非预期动作的普通保护 |
| 确定性禁止 | permissions.deny 仍生效 | permissions.deny 仍生效 |
| 适合环境 | 方向可信、仍需要后台安全检查的日常或长任务 | 无互联网、非 root、可销毁的隔离容器或 VM |
| 是否等于系统隔离 | 否 | 否；必须由外部隔离补上 |
Anthropic 当前的权限模式说明明确指出，Auto mode 会在动作执行前调用独立分类器，并且不能保证安全。分类器默认关注的风险包括敏感数据外传、生产部署、破坏性 Git 操作、共享基础设施变更、从网络下载后直接执行代码等。它减少的是人工确认次数，不是把错误概率变成零。
bypassPermissions 与命令行参数 --dangerously-skip-permissions 等价。它会跳过普通权限提示和安全检查，包括对受保护路径写入的常规限制。不过“跳过所有权限”仍不是字面上的“产品里任何边界都消失”：显式 ask 规则、组织要求确认的 connector、必须与用户交互的工具、指向关键路径的 rm/rmdir，以及部分跨会话消息保护仍有特殊处理。这个区别很重要，因为准确的风险判断不能建立在一句过度简化的口号上。
用运行环境决定，而不是用任务时长决定
长任务并不会自动获得更大权限。真正影响选择的是：错误动作能触达什么、凭证能访问什么、环境能否恢复，以及有没有人在场处理阻塞。
普通本地开发仓库：选择 Auto mode。 适合你认可任务方向、会查看最终 diff 和测试结果，但不想逐次点确认的场景。它仍应配合最小权限凭证、受限网络和硬性 deny 规则。
陌生代码、生产基础设施或高敏感数据：使用 Manual 或 Plan。 先让 Claude 读取和提出方案，关键写入、部署或数据访问由人确认。分类器不是安全评审，也不能替代变更审批。
需要确定性白名单的 CI：考虑 dontAsk。 它只执行已经预批准的工具；未批准动作会被拒绝而不是临时放宽权限。对固定测试命令，这往往比让分类器自由判断更容易审计。
完全无人值守且确实需要绕过：只在隔离环境使用 bypassPermissions。 官方边界是容器、VM 或 dev container，并且没有互联网访问。环境应以非 root 用户运行，不挂载主机家目录，不注入生产凭证，工作目录和输出都可丢弃或回滚。若这些条件缺一项，就不是“方便与否”的问题，而是损害半径没有被约束。
如果你的核心问题其实是进程能否跨终端、睡眠或会话继续，以及中断后怎样恢复，请看 Claude Code 长任务的生命周期与恢复方法。权限模式只解决其中的监督问题，并不让本地进程自动变得持久。
一个更可靠的 Auto mode 起点
单次启动可以显式指定模式：
bashclaude --permission-mode auto
如果想把它设为个人终端会话的默认值，应放在用户配置 ~/.claude/settings.json，而不是仓库中的 .claude/settings.json。当前合同会忽略项目级文件里的 Auto 默认设置，避免检出的仓库偷偷为自己开启自动模式。
json{ "permissions": { "defaultMode": "auto", "deny": [ "Bash(git push --force *)", "Bash(terraform destroy *)" ], "ask": [ "Bash(git push *)", "Bash(terraform apply *)" ] }, "sandbox": { "enabled": true, "allowUnsandboxedCommands": false, "failIfUnavailable": true } }
这些规则只是示例，需要改成你的命令、分支和基础设施边界。权限规则文档说明了 allow、ask 和 deny 的匹配方式。尤其不要用模糊的 allow 规则放行整个 shell；一个看起来只允许测试的前缀，也可能接收你没有预料的危险参数。
Auto mode 的分类器还可以读取用户或组织级 autoMode 环境说明，用来识别可信仓库、域名、存储桶和内部服务。配置后运行下面的命令，查看真正生效的合并结果：
bashclaude auto-mode config
若团队需要不可被个人覆盖的边界，应把关键 permissions.deny 放在 managed settings。分类器内部的自然语言 hard_deny 很有用，但硬性的工具模式禁止更早执行，也更适合审计。Auto mode 配置说明还提供 claude auto-mode defaults 和 claude auto-mode critique，分别用于查看内置规则和检查自定义规则。
权限模式之下还要有真正的隔离层
模式回答“Claude Code 是否在动作前询问或调用分类器”；沙箱回答“命令一旦执行，操作系统允许它碰到什么”。这两层必须分开设计。
Claude Code 的 Bash sandbox 可以在 macOS、Linux 和 WSL2 上限制可写目录与网络域名。Native Windows 需要在 WSL2 中使用。建议至少做到：
- 只允许工作目录和会话临时目录写入；
- 网络按域名收窄，不为“省事”放开任意出口；
- 把云凭证、SSH 目录和高权限 token 拒绝或遮蔽；
- 将
allowUnsandboxedCommands设为false，避免沙箱失败后静默重试到主机； - 将
failIfUnavailable设为true，让缺依赖或不支持的平台直接失败关闭。
Bash sandbox 只约束 Bash 及其子进程，并不覆盖每一种 Claude Code 工具。若你真的需要 bypassPermissions，外部容器或 VM 才是最终损害边界；内置沙箱仍可作为额外一层，但不能用模式名称代替隔离证明。
启动后用四个证据核对现实
不要因为启动命令里出现 auto 就假设它已经生效。当前的可用性与起始默认值受 Claude Code 版本、计划、模型、provider、组织策略和 feature flag 影响。启动后检查：
- 状态栏显示的实际权限模式；CLI 中可用
Shift+Tab查看和切换可选模式。 /permissions中的 allow、ask、deny 以及最近被分类器拒绝的动作。claude auto-mode config输出的有效环境和分类器规则，而不是某一个配置文件的内容。/sandbox面板里的模式、文件系统、网络和 unsandboxed retry 设置。
Auto mode 连续多次拒绝动作后，交互式会话会回到人工提示；非交互 -p 运行若没有 permission prompt tool，则被拒绝的动作不会执行，但任务可能继续处理其他步骤。因此无人值守任务还需要明确的完成证据和失败状态，不能把“进程仍在运行”当作成功。
如果隔离环境还没准备好，选择 Auto mode 并收紧 deny、ask、sandbox 和凭证范围。只有当你能明确回答“主机不可达、互联网不可达、生产凭证不存在、环境可销毁”时，bypassPermissions 才从危险捷径变成一个可讨论的工程选择。
