目录
您已在 Claude Code 中设置了 --dangerously-skip-permissions 标志，但 Claude 仍在聊天中发送“可以执行此操作吗？”的消息。是否感到似曾相识？
您可能会以为“bypass 没有生效”，但实际情况并非如此。Claude Code 的权限系统包含两个独立层，而 bypass 模式只控制其中一个。
本文将全面介绍“bypass 究竟是什么”、两层权限系统的区别、Claude 会主动请求确认的操作类型，以及在自动化场景中减少确认提示的实用方法。
1. “Bypass” 到底是什么？
在软件领域，“bypass”（绕过）意味着跳过常规的确认或审批流程，直接执行操作。就像购物网站的“立即购买”按钮跳过了审核页面一样——这就是对确认流程的绕过。
在 Claude Code 的 Manual 模式（配置值为 default）下，执行任何文件编辑或 shell 命令之前都会弹出确认对话框。不过从 Claude Code v2.1.283 起，终端和 VS Code 会话在所有套餐和服务商下都默认以 Auto 模式启动，由分类器代替您审查大多数操作（更早的版本只有 Pro、Max 和 Team 套餐如此；如果管理员关闭了 auto 模式，或所用模型不支持，则以 Manual 模式启动）。
# Manual 模式：每次操作前需要确认
$ claude --permission-mode default
> Please fix index.js
[Claude Code] May I edit index.js? → Yes / No权限 bypass 模式的作用是跳过（绕过）这一确认流程。
# Bypass 模式：几乎不弹出确认对话框
$ claude --dangerously-skip-permissions
# 或
$ claude --permission-mode bypassPermissions请注意，该标志包含 dangerously（危险）一词。Anthropic 明确指出此模式仅适用于容器或隔离环境，不建议在日常本地开发中使用。有关 bypass 模式风险的详细说明，请参阅 Claude Code Bypass 权限模式：风险与安全使用指南。
如果确认对话框仍然频繁出现，请先确认自己是否真的在 bypass 模式下运行。bypass 生效时，终端的状态栏会显示 ⏵⏵ bypass permissions on。如果没有显示，常见原因有两个。
- 写在了项目设置里：在
.claude/settings.json或.claude/settings.local.json中把defaultMode设为bypassPermissions不会生效，会话会以 Manual 模式启动（v2.1.257 及以后）。请写在用户设置（~/.claude/settings.json）或托管设置中，或在启动时通过标志指定 - 想在会话中途切换：只有启动时已启用 bypass 的会话才能选择它。在未启用的情况下启动的会话里，按 Shift+Tab 也切换不到 bypass
此外，第一次以 bypass 启动交互式会话时，Claude Code 会显示一次警告，要求您对未经权限检查而执行的操作承担责任（您的确认会保存在用户设置中）。
2. 真正的原因：两层权限系统
“为什么启用 bypass 后仍会出现确认提示”的答案在于：Claude Code 的权限系统建立在两个独立层之上。
Claude Code 权限系统：两层结构
Bypass 模式能够禁用的只有第一层（而且第一层中也有少数确认会保留）
--dangerously-skip-permissions 禁用的是第一层的几乎全部确认（ask 规则、关键路径的删除等少数几项会保留），第二层无法绕过。
混淆这两层正是“bypass 没有生效”这一误解的根本原因。下面我们逐层详细说明。
3. 第一层：工具权限 UI（可通过 Bypass 控制）
第一层是工具执行前显示的确认对话框——当 Claude Code 即将编辑文件或运行 shell 命令时出现的交互式界面。
| 工具 | 确认对话框示例 |
|---|---|
| 文件编辑 | “是否允许修改 index.js？” |
| Bash 执行 | “是否允许运行 npm install？” |
| 网络访问 | “是否允许访问 https://...？” |
这正是 bypass 模式所禁用的那一层。使用 --dangerously-skip-permissions 后，这类对话框几乎不再出现，Claude 可以自由执行工具。在 bypass 模式下，就连写入 .git、.claude 等受保护路径也不会询问。从这个意义上说，bypass 模式运行正常。
bypass 模式下仍会出现的确认（第一层的例外）
关键在于“几乎”。官方文档明确写道，以下内容在包括 bypass 在内的任何模式下都不会被自动批准（来源：Claude Code 官方页面“Choose a permission mode”，截至 2026 年 9 月 22 日）。
- 匹配 ask 规则的操作：您在设置的
permissions.ask中写入的操作（例如Bash(git push *)），即使在 bypass 模式下也每次都会询问 - 需要您参与的工具：Claude 以选项形式向您提问的
AskUserQuestion、被标记为需要用户交互的 MCP 工具，以及您的组织设为 ask 的连接器工具 - 针对关键路径的
rm和rmdir：以文件系统根目录及其一级目录（如/usr）、主目录、工作目录及其上级目录等为目标的删除。官方文档称之为防范模型出错的“断路器”（circuit breaker），任何 allow 规则或钩子都无法批准它。不过，在 Desktop 应用和 VS Code 中，从 v2.1.309 起会直接拒绝、不再弹出确认，并返回改写命令的提示，以免无人值守的会话被卡住（官方更新日志）。 - 其他：跨会话消息传递的安全机制，以及启用
permissions.blockReadsOutsideWorkingDirectories时读取工作目录以外内容的 Bash 命令
规则方面也要注意。deny 规则在 bypass 模式下照样生效，会拦截匹配的操作；而 allow 规则在 bypass 模式下没有意义（本来就全部放行）。在使用 -p 的非交互式运行中，这几类确认不会等待输入，而是直接被拒绝。
注意：共有 6 种权限模式
Claude Code 共有六种权限模式：Manual（default）、Accept edits（acceptEdits）、Plan（plan）、Auto（auto）和 Bypass permissions（bypassPermissions），再加上从不出现在 Shift+Tab 循环中、会自动拒绝一切需要确认的操作的 dontAsk（面向 CI）。Bypass（bypassPermissions）是限制最少的模式。各模式的详细说明请参阅权限模式详解。
4. 第二层：AI 安全判断（不可通过 Bypass 控制）
第二层是Claude 自主的安全判断，与工具确认 UI 完全独立。
当 Claude 判断某个操作可能产生重大影响时，它会以普通文本的形式在聊天中发送确认消息。这不是工具执行机制——而是 Claude 作为 AI 的对话行为。
--dangerously-skip-permissions 跳过的是第一层的 UI 对话框，对第二层的 AI 判断没有任何影响——因为第二层是内置于 Claude 模型本身的行为原则。
常见误解
“我设置了 bypass 模式但 Claude 还是停下来问了→ bypass 没有生效”
→ 更准确地说，要看 Claude 是怎么停下来的。如果 Claude 是用聊天文本询问，那就是“第一层 UI 已被禁用，但第二层 AI 判断正在请求确认”。如果终端里弹出了请求许可的对话框，那就是 bypass 仍会保留的第一层确认之一，例如 ask 规则或关键路径的删除。无论哪种情况，bypass 都运行正常（如果两者都不是，确认却一直出现，可能根本就没有以 bypass 启动）。
不过，第二层并不是安全保证。Claude 是否询问取决于当时的判断，并不一定会在危险操作前停下来。官方文档也警告说，bypass 模式对提示词注入和意外操作没有任何防护作用。绝对不能执行的操作，请用 deny 规则拦截。
5. Claude 会主动确认的操作类型
按操作类型：哪一层负责确认？
第一层（工具权限 UI）与第二层（AI 安全判断）的对比
Claude 内部判断“需要确认”的标准主要分为三类。
① 不可逆性
无法撤销的操作会让 Claude 更加谨慎。永久删除文件、git push --force 和 DROP TABLE 是典型例子。由于错误难以恢复，Claude 会暂停并询问。
② 影响范围
影响生产环境、大量文件或其他用户的操作会触发更频繁的确认。修改单个本地文件几乎不会触发提问；修改生产数据库结构则几乎每次都会。
③ 安全风险
将 .env 文件、身份验证令牌或 API 密钥发送到外部的操作会被 Claude 标记为高安全风险，执行前会主动询问。
不过，有些删除完全不交给 Claude 判断：针对关键路径的 rm 和 rmdir（根目录、主目录或工作目录本身等），即使在 bypass 模式下，也会由 Claude Code 自身（第一层）拦截（CLI 会弹出确认，Desktop 应用和 VS Code 则从 v2.1.309 起直接拒绝）。这是 bypass 无法去掉的少数确认之一。
这些判断内置于 Claude 的 AI 模型中，无法通过配置完全关闭。有关 AI 智能体安全设计的更多内容，请参阅 什么是 AI 智能体？。
6. 为什么要分两层？设计理念解析
为什么要分两层？——设计理念
用建筑承包商的类比来理解
下面用一个类比来直观理解两层设计的逻辑。
假设您雇了一位承包商装修房间，并给了他一把备用钥匙，告诉他“你可以做任何需要做的事”。这相当于授予了工具权限。
但当承包商即将拆除一面墙时，他会问：“这是承重墙吗？您确定要拆吗？”——他问这个问题是基于自己的专业判断，而不是因为找不到钥匙。
给他钥匙并不能阻止承包商思考。他的专业判断和安全意识独立于钥匙运作。
Claude 的工作方式完全相同。Bypass 模式给了 Claude“使用工具的钥匙”，但不会停止 Claude 的 AI 判断。事实上，Claude 在高风险操作前暂停是一种有意为之的安全特性，而非故障。
7. 减少确认提示的实用方法
在 CI/CD 流水线和其他自动化场景中，您可能需要 Claude 在不中断的情况下完成任务。以下是最有效的几种方法。
方法一：使用 CLAUDE.md 提供上下文
在项目根目录创建 CLAUDE.md 文件，说明运行环境和约束条件。当 Claude 理解“这是一个安全的隔离环境”时，确认频率会显著降低。
# About This Environment
This repository runs inside a CI/CD pipeline test environment.
- Runtime: fully isolated Docker container
- Production impact: none
- All changes are rollback-safe
Please proceed without asking for extra confirmation.方法二：给出明确具体的指令
模糊的指令会增加 Claude 的不确定性，从而触发更多确认。
| 指令类型 | 示例 | 确认频率 |
|---|---|---|
| 模糊 | “整理一下这个项目” | 高 |
| 明确 | “删除 src/ 中未使用的 import” | 低 |
| 模糊 | “部署一下” | 高 |
| 明确 | “在 staging 环境中运行 npm run deploy:staging” | 低 |
方法三：优先尝试 Auto 模式
在使用完整 bypass 模式之前，先试试 auto 模式。它会在后台运行安全分类器，同时自动批准大多数操作，还会促使 Claude 继续工作，而不是停下来提出澄清性问题（当您的提示词或技能依赖提问时，Claude 仍会询问）。如果您使用 bypass 的唯一原因是“厌倦了确认提示”，那么 auto 模式可能就已经足够了。匹配 ask 规则的操作在 auto 模式下仍会询问。
重要说明
任何配置都无法将 Claude 的安全判断降低至绝对零。这是有意为之的设计——而非 bug 或限制。对于高风险操作，Claude 请求确认是正确行为，请将其视为设计的一部分加以接受。第一层中也保留着 bypass 去不掉的确认，例如 ask 规则和关键路径的删除。
8. 总结
| 条目 | 说明 |
|---|---|
| Bypass 是什么 | 跳过工具执行前几乎所有的确认对话框（第一层） |
| Bypass 禁用的内容 | 工具权限 UI（“是否允许运行此命令？”），包括写入 .git、.claude 等受保护路径时的确认 |
| Bypass 不禁用的内容 | Claude 的 AI 安全判断（以聊天文本形式发送的确认），以及第一层的例外（ask 规则、针对关键路径的 rm/rmdir、AskUserQuestion） |
| Bypass 下的规则 | deny 照样拦截；allow 没有作用 |
| Claude 确认的标准 | 不可逆性、影响范围、安全风险 |
| 减少确认的方法 | CLAUDE.md 上下文 / 明确具体的指令 / Auto 模式 |
| 两层设计的原因 | 工具权限与 AI 判断是本质上独立的概念 |
当 Claude 在 bypass 模式下仍然请求确认时，并不意味着 bypass 失效了——只是两个独立系统各司其职。理解这一区别有助于准确预测 Claude Code 的行为，并更高效地使用它。
要了解各 Claude 产品之间的差异，请参阅 Claude.ai 与 Claude Code 有何不同？。
常见问题
使用 bypass 模式可以做到零确认提示吗？
您可以禁用几乎所有工具执行 UI 对话框（第一层），但匹配 ask 规则的操作、针对关键路径的 rm 或 rmdir，以及通过 AskUserQuestion 提出的问题，仍会弹出确认。第二层的 AI 安全判断确认也无法完全消除。这是有意为之的安全特性。不过，在 CLAUDE.md 中详细描述您的运行环境并给出具体指令，可以显著减少 Claude 询问的频率。
Claude 请求确认是 bug 吗？
不是。Bypass 模式跳过的是工具权限 UI，而非 Claude 的 AI 判断。Claude 在执行不可逆操作、访问生产环境或处理敏感数据前暂停，是有意为之的安全行为——而非故障。这不是“bypass 没有生效”，而是“两个系统独立运行”。如果出现的不是聊天文本，而是请求许可的对话框，那就是 bypass 仍会保留的第一层确认之一，例如 ask 规则或关键路径的删除。
如何防止 Claude 在 CI/CD 流水线中暂停？
以下三种方法效果较好：① 在 CLAUDE.md 或系统提示中明确说明“这是一个完全隔离的 CI/CD 环境，所有操作均安全运行”；② 给出小而具体的任务指令（模糊指令会触发更多确认）；③ 将 bypass 模式与 Docker 容器隔离结合使用。对于③，请以非 root 用户运行 Claude Code：在 Linux 和 macOS 上，以 root 或 sudo 运行时 bypass 模式会拒绝启动。使用 -p 时，bypass 仍保留的少数确认不会等待输入，而是直接被拒绝。如果只想运行事先批准的操作，官方文档还为 CI 列出了 --permission-mode dontAsk 配合 --allowedTools 的用法。请注意，即使采用上述所有方法，某些暂停仍可能发生。
能从视觉上区分工具对话框和 Claude 的确认消息吗？
可以。第一层工具权限对话框会在 Claude Code 终端中以交互式 UI 的形式出现，显示要执行的命令或编辑内容，并附带 Yes、No 等选项。第二层 AI 判断确认则以 Claude 的普通对话文本形式出现（例如“这将修改生产数据库——确定吗？”）。容易混淆的是 Claude 以选项形式提问的 AskUserQuestion：问题来自 Claude，但它以对话框形式出现，而且因为第一层从不自动批准它，即使在 bypass 模式下也会等待您回答。两者的显示格式不同，熟悉后很容易区分。
