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

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

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

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

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

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

claude --dangerously-skip-permissions

claude --permission-mode bypassPermissions

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

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

配置值 default 对应界面里的 Manual；从 v2.1.200 起也支持 manual 别名。会话中用模式切换控件确认当前状态，用 /permissions 查看权限规则，不能只凭启动命令的记忆判断。CLI 参数参考、权限模式说明

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

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

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

这些条件见官方启动限制。遇到阻断时先调整环境或模式，不要通过关闭保护检查来让启动成功。

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

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

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

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

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

claude --permission-mode acceptEdits

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

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

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

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

以上比较按当前权限模式文档。例如，要处理工作区内常见的目录创建、文件移动等操作，acceptEdits 也可能自动批准相应命令；不能拿旧教程“只自动批准 Edit/Write”的说法预测当前行为。

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

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

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

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

当前 bypass 仍有以下例外：官方 bypass 规则

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

先确定执行发生在哪里，再排查选项为何缺失。下表按官方各界面权限说明：

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

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

不一定，恢复正在运行的会话，与从记录新建会话不同。 恢复一个仍在运行的后台会话会保留其模式；交互终端按准确 ID、名称或 --continue 恢复记录时，通常恢复原模式，但原来的 Bypass 和 Plan 会重置成新会话的起始模式，bypass 要明确重新启用。恢复时的权限模式

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

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

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

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

常见问题

“Bypass permissions on” 是什么意思？

表示当前会话已经选择 bypassPermissions，多数工具调用可直接执行。仍可能有显式 ask、必要人机交互和关键删除等例外；它不表示获得了系统管理员权限或绕过登录。权限模式说明

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

不要按缩写猜参数。官方写法是 --dangerously-skip-permissions，或者等效的 --permission-mode bypassPermissions；--allow-dangerously-skip-permissions 只开放切换选项。CLI 参数参考

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

dontAsk 遇到需要确认的调用会拒绝，bypass 通常直接批准。dontAsk 仍允许读取、已预批准工具和允许的钩子决定；两者都有各自交互例外，不能把“不弹窗”当成“操作已执行”。模式行为比较

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

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

怎么关闭危险模式？

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