# Claude Code --dangerously-skip-permissions：跳过确认、设置与安全替代

> --dangerously-skip-permissions 和 --permission-mode bypassPermissions 启用同一种模式：跳过多数工具确认，仍保留部分强制询问与阻断。只想减少日常编辑打断，可先选 acceptEdits；长期自动化还需要真实的文件和网络隔离。

- URL: https://blog.laozhang.ai/zh/posts/claude-code-dangerously-skip-permissions
- Published: 2026-05-07
- Updated: 2026-10-08
- Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about)
- Topic: Claude Code
- Tags: Claude Code, 权限模式, AI 编程, 开发者工具, 安全

---
Claude Code 的 <code>--dangerously-skip-permissions</code> 会启用 <code>bypassPermissions</code>，通常直接批准工具调用，包括文件修改和命令执行。界面显示的 **Bypass permissions on** 就是这一模式已开启，中文教程也常叫它“危险模式”或“跳过确认”。它不会替你登录、提升系统权限，也不会绕过组织政策、套餐限制或模型额度。[官方权限模式说明](https://code.claude.com/docs/en/permission-modes)

如果只是嫌日常改文件太多确认，先用 <code>acceptEdits</code>；如果希望命令也能经过自动判断，再看 Auto。完整 bypass 更适合已经限制文件、凭据和网络范围的一次性环境。这里的关键区别是：**少问你几次，由权限模式决定；出错后能碰到什么，由运行环境决定。**

以下按 2026 年 10 月 7 日的官方文档说明。命令和配置是文档用法及离线示例，本文没有运行真实 bypass 会话、容器或外传测试；版本条件紧贴相应操作。

## 怎么启动：两种写法相同，allow 参数只负责开放选项

在已经准备好的隔离环境中，以下两条命令任选一条，都会选择 bypass 模式：

~~~bash
claude --dangerously-skip-permissions
~~~

~~~bash
claude --permission-mode bypassPermissions
~~~

<code>--allow-dangerously-skip-permissions</code> 则不同：它让 bypass 出现在 CLI 的模式切换中，**不会自行切到 bypass**。例如，下面启动时选的是 Manual，而后允许你切换到 bypass：

~~~bash
claude --permission-mode default --allow-dangerously-skip-permissions
~~~

配置值 <code>default</code> 对应界面里的 Manual；从 v2.1.200 起也支持 <code>manual</code> 别名。会话中用模式切换控件确认当前状态，用 <code>/permissions</code> 查看权限规则，不能只凭启动命令的记忆判断。[CLI 参数参考](https://code.claude.com/docs/en/cli-reference)、[权限模式说明](https://code.claude.com/docs/en/permission-modes)

**别把“先 Plan，再开放 bypass”当成强制只读方案。** 在交互式终端里，只要 bypass 已可用，Plan 原本强制禁止编辑和命令的检查就不再生效；模型仍收到先做计划的指令，但那只是行为指令。<code>-p</code>、SDK 和 VS Code 聊天中的 Plan 仍保留这些强制检查。因此，准备只读分析时不要给交互式终端同时开放 bypass。[Plan 的运行界面例外](https://code.claude.com/docs/en/permission-modes)

启动还有三个容易混淆的条件：

- Linux 和 macOS 通常拒绝用 root 或 <code>sudo</code> 启动 bypass；识别到特定沙箱的例外，不等于推荐提权。容器应使用非 root 用户。
- 从 v2.1.248 起，<code>--restricted</code> 不允许 bypass，不能把两者组合成“更安全的危险模式”。
- 首次交互启动的责任确认，与选择权限模式是两件事。<code>-p</code> 不显示这项对话框；<code>--bg</code> 需要此前已经接受该确认。缺少弹窗不代表环境已经隔离。

这些条件见[官方启动限制](https://code.claude.com/docs/en/permission-modes)。遇到阻断时先调整环境或模式，不要通过关闭保护检查来让启动成功。

## bypassPermissions 怎么设置默认：先分清用户配置和项目配置

**项目配置里的 <code>defaultMode: "bypassPermissions"</code> 不会让新会话自动进入 bypass，而会从 Manual 开始。** 项目配置里的 <code>auto</code> 默认值同样不生效。当前 CLI 按显式启动参数、适用设置、内置默认值的顺序选择起始模式；用户设置、<code>--settings</code> 和托管设置，与仓库项目设置不能混为一谈。[起始模式与设置作用域](https://code.claude.com/docs/en/permission-modes)

日常项目更实用的选择，是在项目的 <code>.claude/settings.local.json</code> 中设置自动批准编辑：

~~~json
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}
~~~

这是一个完整 JSON 示例；若文件已有其他设置，只合并这一字段，不要覆盖原文件。它影响从该项目启动的 CLI，会受显式参数和组织策略等条件约束。也可以只对一次启动使用：

~~~bash
claude --permission-mode acceptEdits
~~~

技术上，在用户级 <code>~/.claude/settings.json</code> 或显式 <code>--settings</code> 中把同一字段改成 <code>bypassPermissions</code>，属于可生效的起始模式来源；但放进用户级文件会影响其他项目。需要 bypass 的隔离任务，逐次使用启动参数更容易看清本次选择，避免普通项目继承它。

设置路径写对，也不证明当前会话就是预期模式：VS Code 的起始模式不读取项目配置，Desktop 还可能记住文件夹的模式，恢复会话也有另外的规则。后两种情况在下文分别说明。配置示例仅做 JSON 语法检查，不代表已在某个安装版本上导入成功。

## 只想少点确认，acceptEdits、Auto 和 dontAsk 怎么选？

根据你愿意自动批准什么来选，而不是把所有模式排成一条固定升级路线：

| 实际需要 | 可以先选 | 会发生什么 |
| --- | --- | --- |
| 关键动作仍要自己看一眼 | Manual，配置值为 <code>default</code> | 按权限规则询问；已获准的操作仍可直接执行 |
| 反复修改同一工作区的文件 | <code>acceptEdits</code> | 自动批准编辑，也批准范围内部分常见文件系统 shell 命令；并非所有 Bash 都继续问 |
| 先分析方案，不急于执行 | <code>plan</code> | 通常强制限制编辑和命令；交互式终端开放 bypass 后有上节所述例外 |
| 希望工具动作经过自动审查 | <code>auto</code> | 分类器评估操作，仍可能阻断或转为人工确认；不提供文件或网络隔离 |
| 无人应答时宁可拒绝动作 | <code>dontAsk</code> | 原本需要提示的调用会被拒绝，读取、预批准工具及允许的钩子决定仍可执行 |
| 直接批准多数工具调用 | <code>bypassPermissions</code> | 保留特定询问与阻断；可达资源仍取决于宿主和其他控制 |

以上比较按[当前权限模式文档](https://code.claude.com/docs/en/permission-modes)。例如，要处理工作区内常见的目录创建、文件移动等操作，<code>acceptEdits</code> 也可能自动批准相应命令；不能拿旧教程“只自动批准 Edit/Write”的说法预测当前行为。

Auto 的起始默认值也已经变化：从 v2.1.283 起，交互式终端和 VS Code 的内置默认模式可在各套餐、各 provider 中使用 Auto，但仍取决于模型、provider 的最低版本、组织策略和服务端可用性。<code>-p</code> 与 SDK 获取功能标志的会话通常从 Manual 开始；从 v2.1.285 起，不获取功能标志的会话内置默认值改为 Auto，仍受可用性限制，符合 HIPAA 条件的组织另有 Manual 默认值。别再按“仅某个套餐能用”的旧表选择，也别假定所有机器刚启动都是同一模式。[Auto 可用性和默认值](https://code.claude.com/docs/en/permission-modes)

<code>dontAsk</code> 尤其值得区分：它的“不要问”是遇到需要确认的操作就拒绝，并非悄悄批准。对无人应答的批处理，这比用 bypass 强行完成所有步骤更符合“未批准就不执行”的需求。Auto 连续三次或累计二十次被分类器阻断时会走回退逻辑；<code>-p</code> 没有权限提示工具时，可以拒绝调用并继续后续工作，不能只看进程还在运行就认定任务已经全部完成。

## 明明开了危险模式，为什么还会停？

先看停下来的到底是什么。工具调用前的权限对话框，与 Claude 在回答里询问需求或缺少信息，并不是同一种停顿。切换 bypass 不会自动补齐业务决定，也不会替用户扩大任务授权。

当前 bypass 仍有以下例外：[官方 bypass 规则](https://code.claude.com/docs/en/permission-modes)

| 看到的情况 | 原因与下一步 |
| --- | --- |
| 配置明确要求某类调用询问 | 显式 <code>ask</code> 规则仍然适用；检查规则作用域，按该操作的实际需要批准或拒绝 |
| 工具需要人参与，或连接器要求确认 | 必需交互工具、组织连接器的询问策略仍可暂停；不能用模式名称保证每个工具无提示 |
| 跨会话发送消息需要确认 | 跨会话消息有独立保护；重新核对接收对象和发送授权 |
| 删除关键目录时提示 | 关键 <code>rm</code>/<code>rmdir</code> 有额外检查，不能视为所有删除操作都会获救 |
| 读取工作目录之外的数据仍被问 | <code>blockReadsOutsideWorkingDirectories</code> 对识别到的读取有特定检查；它不等于禁止所有进程读取所有外部文件 |
| 返回拒绝而不是弹窗 | 普通 deny 规则、组织策略、操作系统权限或沙箱也可能阻断；按照拒绝来源排查 |

从 v2.1.281 起，终端中 Auto/bypass 对关键删除的确认有两分钟时限，反复不回应会变成拒绝；非终端 Auto 会拒绝这些调用。PowerShell 的系统路径和通配符删除还存在所有模式都适用的拒绝规则，不能用 Bash 的行为概括 Windows。与此同时，当前 bypass 通常允许受保护路径的**写入**，写入和关键目录**删除**的保护不同。不要拿一个被拦住的删除案例证明其他写入也被禁止。

排查顺序可以很短：先确认当前模式，再看实际阻断工具、命令和规则来源；如果需要人工交互，改为可应答的运行方式；如果是环境或组织政策阻断，缩小任务范围或由管理员评估。不要为了让长任务不停顿而删掉每一条保护规则。

## allowedTools 和 deny 能限制什么？别把规则当沙箱

<code>--allowedTools</code> 是预先批准操作的清单，**不是只允许这些工具存在的总开关**。例如，把某个测试命令列入 allowedTools，只说明这个匹配操作可以不用再问，不说明其他工具或间接脚本失去了能力。<code>--tools</code> 才用于选择内置工具集合，但它不影响 MCP；MCP 需要独立控制。[CLI 工具参数](https://code.claude.com/docs/en/cli-reference)

普通权限规则按 deny、ask、allow 的顺序判断，跨设置作用域的 deny 不能被另一条 allow 抹掉。不过它们依赖工具和命令匹配：Bash 规则可以识别部分运算符与 shell 包装，不能遍历任意 Python、脚本或命令运行器的内部行为；文件规则也无法替代操作系统对所有子进程的访问限制。[权限规则与 shell 匹配边界](https://code.claude.com/docs/en/permissions)

路径写法也有差别：文件规则中的 <code>//</code> 表示绝对路径，<code>/</code> 相对设置文件位置，<code>~/</code> 相对家目录，<code>./</code> 相对当前目录。把其中一种当成另一种，即使 JSON 合法，覆盖范围仍可能完全不同。

PreToolUse 钩子可以在 bypass 中阻止调用，但一个正则表达式钩子不是完整 shell 解析器。还要留意装在进程内的 mod：它的 <code>tool.check</code> 能覆盖 ask、钩子或分类器的决定，在部分策略环境中也能覆盖 deny；托管钩子及 Team/Enterprise、托管 deny 有特定保护和策略例外。因此，“deny 永远优先”必须限定为普通权限规则的判断，不能推广成任何扩展代码都无法改变结果。[扩展与权限规则例外](https://code.claude.com/docs/en/permissions)

## 沙箱到底隔离了什么？空域名列表不等于禁止外连

![命令沙箱覆盖子进程与沙箱外工具、挂载、凭据和网络须分别检查的示意](https://blog.laozhang.ai/posts/zh/claude-code-dangerously-skip-permissions/img/explainer-2.webp)

内置命令沙箱包住 Bash、PowerShell、Monitor 及其子进程，**不包住**文件工具、网页工具、MCP、钩子、LSP、状态栏辅助程序、mod 或屏幕控制。它默认关闭；在不支持或缺少依赖时，若没有设置 <code>failIfUnavailable</code>，启动可以回退到无沙箱执行。原生 Windows 没有这套内置沙箱，WSL2 支持。[沙箱范围与默认行为](https://code.claude.com/docs/en/sandboxing)

沙箱的“auto-allow”表示自动批准部分沙箱内命令，和权限模式 Auto 的分类器审查是两件事。即使某条命令获准运行，也要看它有没有落在沙箱之内。

下面是一个只展示命令沙箱控制的设置片段：要求沙箱可用、禁止请求无沙箱重试，并给沙箱内命令设置严格的空网络许可列表。

~~~json
{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": [],
      "strictAllowlist": true
    }
  }
}
~~~

这个示例适合解释“沙箱内命令不需要联网”的目标，**不是完整隔离配置**，也没有配置文件读取范围。需要联网的依赖安装或 API 调用会需要相应目标；使用其他 provider 时，连接要求也要分别考虑。它不封锁 Claude Code 主进程访问模型，也不限制沙箱外的 MCP 或钩子。

这里 <code>strictAllowlist</code> 不能省略：在 bypass 中，未列出的主机通常会自动获准，单独写 <code>allowedDomains: []</code> 不能证明命令无法外连，托管域名锁是另一种约束来源。<code>allowUnsandboxedCommands: false</code> 关闭重试逃生口，但仍要查看排除命令及其他沙箱外工具。从 v2.1.285 起，用户级 false 不会被项目级 true 放宽；托管或 CLI 的严格设置可以要求必须使用沙箱，却不会自动帮你开启沙箱。[网络严格列表与重试行为](https://code.claude.com/docs/en/sandboxing)

凭据也不是自动消失的。默认读取范围和继承的环境变量可能包含 SSH、云服务等凭据；限制文件工具，并不保证命令子进程也被同样限制。检查时应确认“有什么资源可达”，避免把真实密钥打印进终端、文章或日志。运行成功只说明某条路径可用，不能代替对拒绝路径的验证。

## 放进 Docker 就安全了吗？还需要看宿主挂载和模型网络

**worktree 只隔离 Git 工作副本；容器或 VM 才能提供另一层进程运行边界，但具体边界仍要配置。** 容器中的绑定挂载仍会写到宿主目录；挂载的密钥、Docker socket 和允许访问的内部服务，都可能把真实权限带进去。[完整进程隔离说明](https://code.claude.com/docs/en/sandbox-environments)

准备无人值守任务时，先逐项决定：

| 要决定的资源 | 可操作的准备方向 | 不能当作完成证据的情况 |
| --- | --- | --- |
| 可读和可写文件 | 只暴露任务所需副本，保留明确输出目录 | 仅创建新分支、worktree，或挂载整个家目录 |
| 凭据与状态 | 使用任务专用凭据和状态目录，限制有效范围 | 把宿主 SSH、云配置或长期 Claude 配置目录直接挂进去 |
| 网络 | 允许所选模型、认证及任务必要目标，其余按策略限制 | 一个空列表、容器名字，或只限制其中一种工具 |
| 宿主控制 | 限制套接字、挂载和容器额外能力 | 非 root 运行就认定无法影响宿主 |
| 输出与恢复 | 保存代码基线、核对 diff 和任务结果 | 测试通过就认定没有读取或发送敏感内容 |

官方 Dev Container Feature 可以安装 Claude Code，**不会自动带来默认拒绝外连的防火墙**。它的 <code>:1.0</code> 固定的是 Feature 安装脚本，不是 Claude Code 版本；CLI 版本固定和更新策略需要另行决定。官方的 <code>devcontainer.json</code>、Dockerfile、<code>init-firewall.sh</code> 是参考配置，不能当作持续维护的基础镜像。应使用非 root <code>remoteUser</code>，逐项检查挂载、状态保存和网络要求。[Dev Container 官方说明](https://code.claude.com/docs/en/devcontainer)

容器重建可能丢弃家目录中的状态；持久化配置卷则可能保留认证信息、设置和历史。不要在解决“重建后需要重新登录”的同时，把整个真实家目录带入一次性环境。参考防火墙的额外容器能力也不是 Claude Code 必需权限，不应不加判断地照抄。

官方另有完整进程 sandbox runtime，当前属于 beta 研究预览，需要明确配置文件读写和推理、认证网络。某次启动成功，尤其是配置缺失时，不能证明想要的策略已经加载。文件隔离还存在 macOS、Linux 及新建嵌套仓库等覆盖差别，应按实际平台核对。[Sandbox runtime 与平台边界](https://code.claude.com/docs/en/sandbox-environments)

最后，隔离并不使模型变成本地离线运行。提示和读取到的文件仍可能发送给你配置的模型 provider。需要限制的是不必要的可读内容和目的地，不能承诺“断网后靠缓存继续使用 Claude”。

## CLI、VS Code、Desktop 和远程会话为什么显示不同？

![Claude Code 的本地、IDE、网页与远程控制入口需分别确认实际权限模式的示意](https://blog.laozhang.ai/posts/zh/claude-code-dangerously-skip-permissions/img/explainer-3.webp)

先确定执行发生在哪里，再排查选项为何缺失。下表按[官方各界面权限说明](https://code.claude.com/docs/en/permission-modes)：

| 运行入口 | 当前要核对的地方 |
| --- | --- |
| 本地交互 CLI | 显式启动参数、适用设置和当前模式；开放 bypass 与选中 bypass 分开判断 |
| VS Code 扩展 | 有独立的 <code>initialPermissionMode</code>、记忆模式和用户/托管默认顺序；起始模式不读项目设置，bypass 还需扩展对应开关，组织策略可限制 |
| Desktop 的 Code | 使用模式选择器；Pro/Max 有相应 toggle，Team/Enterprise 由组织策略决定，文件夹记忆模式可能影响起始选择；Cowork 是另一个界面 |
| Web 云会话 | 支持 Accept edits、Plan 和符合条件的 Auto；不能选择 Bypass，仓库里的 bypass/dontAsk 默认值会被忽略 |
| Remote Control 应用 | 不能从应用选择 Auto/Bypass；但执行端终端的实际模式与应用显示可能不同，不能断言一切远程执行都在 Manual |
| JetBrains 终端 | 按 CLI 控制方式判断，不直接套 VS Code 扩展设置 |

因此，在 Web 里看不到 bypass 是产品界面边界；在 VS Code 里项目配置不生效，要查扩展的起始设置；使用 Remote Control 时，要同时辨认显示端和本地执行端。重复给仓库添加同一字段，解决不了这三类问题。

## 继续上次任务，会一直保留 bypass 吗？

**不一定，恢复正在运行的会话，与从记录新建会话不同。** 恢复一个仍在运行的后台会话会保留其模式；交互终端按准确 ID、名称或 <code>--continue</code> 恢复记录时，通常恢复原模式，但原来的 Bypass 和 Plan 会重置成新会话的起始模式，bypass 要明确重新启用。[恢复时的权限模式](https://code.claude.com/docs/en/sessions#permission-mode-on-resume)

启动时从会话选择器进入，会用新会话模式；在现有会话内执行 <code>/resume</code>，保留当前模式。<code>-p</code> 恢复采用新的 <code>-p</code> 默认值，Plan 是否恢复还有版本、权限提示工具和其他参数条件。所以，“昨天已经开过危险模式”不能作为今天会话状态的判断依据，也不应把 <code>--continue</code> 包成永久 bypass 的别名。

## 哪些任务应该保留人工批准？

当会话能修改生产系统、数据库、云权限、账单或真实凭据时，优先保留关键步骤的人为决定。对部署、迁移、资源删除、发布和共享基础设施操作，应把任务拆成范围明确的检查与执行步骤，而不是让一个全局 bypass 设置顺带批准所有动作。

代码修改需要减少打断时，用 <code>acceptEdits</code>；工具动作需要自动判断时，核对 Auto 的当前条件；无人应答时宁可拒绝，用 <code>dontAsk</code> 配合必要预批准；确实需要直接执行多数动作时，先建立能限制整个进程及其资源的环境。模式选择解决审批流程，环境设计决定失误的影响范围，二者要分别完成。

## 常见问题

### “Bypass permissions on” 是什么意思？

表示当前会话已经选择 <code>bypassPermissions</code>，多数工具调用可直接执行。仍可能有显式 ask、必要人机交互和关键删除等例外；它不表示获得了系统管理员权限或绕过登录。[权限模式说明](https://code.claude.com/docs/en/permission-modes)

### --dangerously-skip-permissions 可以写成 --skip 吗？

不要按缩写猜参数。官方写法是 <code>--dangerously-skip-permissions</code>，或者等效的 <code>--permission-mode bypassPermissions</code>；<code>--allow-dangerously-skip-permissions</code> 只开放切换选项。[CLI 参数参考](https://code.claude.com/docs/en/cli-reference)

### dontAsk 和 bypass 都不问我，为什么结果不同？

<code>dontAsk</code> 遇到需要确认的调用会拒绝，bypass 通常直接批准。dontAsk 仍允许读取、已预批准工具和允许的钩子决定；两者都有各自交互例外，不能把“不弹窗”当成“操作已执行”。[模式行为比较](https://code.claude.com/docs/en/permission-modes)

### 开了沙箱，再开 bypass，是否就不会泄露文件？

不能这样保证。内置命令沙箱不覆盖文件工具、MCP、钩子等全部进程行为；默认读取和环境继承可能带来凭据，允许的网络目标也可能接收可读数据。还要检查完整进程边界和实际资源范围。[沙箱限制](https://code.claude.com/docs/en/sandboxing)、[完整进程隔离](https://code.claude.com/docs/en/sandbox-environments)

### 怎么关闭危险模式？

在交互会话的模式控件切回 Manual 或适合任务的其他模式。若要重新启动并明确使用 Manual，可用 <code>claude --permission-mode default</code>；同时移除自己设置过的用户级默认值、启动包装或编辑器记忆模式，避免下一次又自动进入 bypass。修改设置不能撤销已经执行的操作，已有改动仍要单独核对。[模式和起始设置](https://code.claude.com/docs/en/permission-modes)

## 参考来源

本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-10-08。

- [官方权限模式说明](https://code.claude.com/docs/en/permission-modes) (code.claude.com)
- [CLI 参数参考](https://code.claude.com/docs/en/cli-reference) (code.claude.com)
- [权限规则与 shell 匹配边界](https://code.claude.com/docs/en/permissions) (code.claude.com)
- [沙箱范围与默认行为](https://code.claude.com/docs/en/sandboxing) (code.claude.com)
- [完整进程隔离说明](https://code.claude.com/docs/en/sandbox-environments) (code.claude.com)
- [Dev Container 官方说明](https://code.claude.com/docs/en/devcontainer) (code.claude.com)
- [恢复时的权限模式](https://code.claude.com/docs/en/sessions) (code.claude.com)