Claude Code跳过权限确认的风险边界

claude --dangerously-skip-permissions 能让 Claude Code 少打断你，也会让一次判断失误直接变成文件修改或命令执行。作者的核心主张是：先限制 Agent 能碰到什么，再讨论要不要取消确认。

这篇最有用的地方，是把「允许 AI 帮忙写代码」拆成了读文件、跑测试、联网、提交、部署等不同权限。对前端和全栈开发者来说，它提供了一套可以落到项目配置里的取舍方法，也解释了为什么 worktree 和命令黑名单都不能单独承担安全隔离。

跳过确认，到底跳过了哪些保护

按作者截至 2026 年 10 月 22 日核对的文档，claude --dangerously-skip-permissions 等同于 claude --permission-mode bypassPermissions。它关闭权限提示和安全检查，但存在例外：deny 仍然生效，显式 ask 规则、AskUserQuestion、需要用户交互的 MCP 工具，以及被识别出的关键路径 rm、rmdir 删除操作，仍可能要求确认。

allow 此时没有作用，因为操作已经默认获准。.git、.claude、.bashrc、.mcp.json 等受保护路径也可以直接写入。在可用 bypass 的交互终端里，Plan mode 虽然仍要求模型只规划，但模型若尝试编辑或执行命令，权限系统不会再弹窗拦住。

要求模型不要执行，不等于系统禁止它执行。

首次交互启动会显示责任确认；接受后，~/.claude/settings.json 写入 skipDangerousModePermissionPrompt: true。Linux、macOS 通常拒绝以 root 或 sudo 启动该模式，识别到特定沙箱时例外。这些限制也不能替代隔离，原文明确说 bypass 不提供额外的提示注入保护。

如果只是嫌确认太频繁，作者建议先考虑 auto。它保留后台安全检查，必要时才询问。Claude Code 有六种权限模式，可用 claude --permission-mode <mode> 或 permissions.defaultMode 设置；终端的 Shift+Tab 可以切换其中部分模式，auto 是否出现取决于账号可用性。

worktree 能分开代码，分不开你的身份

Agent 的实际权限，是文件、Shell、凭据和网络叠加后的结果。一个看似普通的修复任务，只要同时拿到仓库读取、终端、登录态和网络，就可能读取并发送当前用户能访问的数据。

作者建议把无人值守执行放进容器或可丢弃 VM。容器只挂载项目，不挂主目录、SSH 密钥和云凭据，最好限制网络；文档示例是在容器内运行 claude -p "<prompt>" --dangerously-skip-permissions。干净的 CI runner 也可以承担类似角色，但凭据仍要限定用途。

worktree 解决的是另一个问题。claude --worktree feature-auth 会在 .claude/worktrees/ 下创建工作区，方便并行修改代码，但进程仍使用你的身份、环境变量、SSH agent 和网络。cp、Shell 重定向也不会因为处于 worktree 就自动受到文件编辑规则的同等约束。

内置沙箱比单纯分目录更进一步。通过 /sandbox 或 sandbox.enabled 开启后，它可以在 macOS、Linux、WSL2 上限制 Shell 命令访问的文件和网络域名。不过，Claude 文件工具、MCP servers 和 hooks 在其覆盖范围之外，不能把它当成整个进程都进了容器。

隔离环境里同样不能随便放生产凭据。容器可以删除，凭据能调用的远端服务却不会因此免受影响。

把权限分成七层，配置才有讨论空间

作者提出七级权限阶梯：读取工作区、编辑工作区、执行受限本地命令、访问本地浏览器和 localhost、有限联网、使用 Git 写操作及第三方工具，最后才是生产部署与客户数据。

它的价值是让授权对应具体任务。排查构建失败可以先只读；修改组件可以增加编辑和本地检查；安装依赖、调用外部 API、提交代码，则各自说明原因。生产权限还应拆成部署、读日志、读指标、读写数据、轮换凭据和修改基础设施，不能用一个管理员 token 全包。

其中容易误判的是「测试命令」。bun run build、bun test 看起来常规，但实际行为由项目脚本决定，可能迁移数据库、请求远端服务或改写快照。允许命令之前，需要先知道它执行什么。

下面这份配置用于放行常规检查、询问安装与提交，并阻止部分敏感操作，是作者给出的起点：

{
  "permissions": {
    "allow": [
      "Bash(bun run test *)",
      "Bash(bun run typecheck)",
      "Bash(bun run lint *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "ask": [
      "Bash(bun add *)",
      "Bash(bun install *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

重点看 Bash(git log *)：通配符放在子命令后；改成 Bash(git *)，授权范围就扩展到了所有 Git 命令。配置可放在项目 .claude/settings.json 或个人 ~/.claude/settings.json，包管理器和脚本名要按 package.json 调整。

规则按 deny、ask、allow 顺序匹配，首次命中决定结果，不能靠更窄的 allow 绕过 deny。跨配置作用域也是 deny 优先，managed settings 位于更高层。

但这仍是规则匹配，不是完整隔离。禁止 curl 不代表能拦住 /usr/bin/curl 或 sh -c 'curl ...'；Read deny 能覆盖文件工具及被识别的 cat、head，却挡不住脚本自己打开文件。.claudeignore 则没有效果。真正需要保密的 .env，应当不出现在 Agent 可访问的环境里。

我的判断

我赞同作者把授权交给规则和执行环境。依赖 README、Issue、网页里的一段误导文字，就可能影响模型后续动作；只靠提示词要求「谨慎」，很难形成可验证的边界。

但七级阶梯是经验模型，不是严格的安全等级。第二级的文件编辑已经能修改 CI、安装脚本和启动逻辑，把执行后果延迟到下一次运行。授权还要看文件内容，不能只看工具名称。

原文没有给出作者团队的对照实验，也没有比较各模式的误拦率、提示次数或效率收益；提到的权限研究也未展开实验条件。因此，不能据此断言某种配置最优。相较频繁逐条确认，auto 值得作为减轻打断的选项；相较命令黑名单，容器和网络限制提供了更明确的约束，但也需要额外维护。

减少弹窗可以是体验优化，扩大权限必须有任务理由。

能拿来做什么

• 给前端项目整理一份可审查的检查命令列表，先读清 package.json 脚本，再放行类型检查、lint 和测试；视觉验收使用 localhost 与独立浏览器环境。
• 将依赖安装与 Git 写操作单独处理。安装前确认包和固定版本，提交前审查 diff，同时检查工作流、依赖清单等可能影响后续执行的文件。
• 无人值守任务优先使用只挂载项目的容器或干净 CI，注入短期、限定用途的凭据，任务结束后撤销网络例外、临时 token 和客户数据副本。
• 已开启 bypass 时，退出后用 claude --permission-mode default 重启，并移除默认配置中的 "defaultMode": "bypassPermissions"。管理员可配置 "permissions": { "disableBypassPermissionsMode": "disable" }；原文称 claude --restricted 在 v2.1.248 及以后也会拒绝该模式。