Bypass Permissions：运行时的“超级用户”模式

在自动化场景或极高信任的环境中，频繁的权限询问（Ask）可能会阻碍流水线的顺畅执行。Bypass Permissions（绕过权限）模式是 Claude Code 权限矩阵中最极端的配置，它彻底拆除了运行时所有的安全询问闸门。

先搞清楚这是什么

Bypass Permissions 本质上是 完全信任模式（Implicit Trust Execution）。

它旨在彻底消除人机交互中的“摩擦力”：

• 它不是什么：它不是“无限制权限”。它受限于底层操作系统的物理限制和已装配的沙箱规则。
• 它的核心作用：当通过 --bypass-permissions 标志启动时，Claude Code 会假设用户已经赋予了模型绝对的执行权。所有的 canUseTool 检查逻辑都会被预先设置为 Approved，从而不再请求人类确认。

运行时的真相

Bypass 模式在代码层面实现了一种“拦截器短路”机制：

1. 全局标志位锁定

当用户在命令行中显式声明 --bypass-permissions 时，AppState 中的 permissionMode 会被全局设为 bypassPermissions。在 src/utils/permissions/PermissionMode.ts 中，该模式被特别标记为 error 颜色（红色），以示警其潜在风险。

2. 权限判定“一键放行”

在权限裁决的核心入口 claude-code-opensource/src/utils/permissions/permissions.ts 中，系统会执行以下逻辑：

• 前置检查：判断当前活跃的模式。如果命中 bypassPermissions 分支，所有的逻辑（包括复杂的 Bash 正则匹配、路径越界计算、复合命令拆解）都将不再进行细粒度的裁决。
• 直接返回批准：逻辑直接跳转到 return { result: 'Approve', ... }。这意味着无论模型想要执行 rm -rf / 还是 curl 某个可疑地址，系统都会默默允许其通过。

3. 应用层 vs 系统层的博弈

这里有一个关键的技术细节：Bypass 绕过的是“询问权”，而不是“执行权”。

• 沙箱仍然存续：即使开启了 Bypass，SandboxManager 依然会在后台根据初始配置运行。如果模型尝试执行的操作超出了 OS 层面分配给该进程的文件系统访问权限，操作系统依然会抛出 EACCES 或 Violation 错误。
• 物理沙箱是底线：换句话说，Bypass 让模型不再向用户“申请想试一下”，但它依然要接受操作系统的“能动哪些”的物理约束。

使用时的关键约束

• 极高安全风险：如果模型由于 Prompt Injection（提示词注入）被误导，它可能会在无任何预警的情况下执行破坏性操作。严禁在未隔离的生产物理机上开启此模式。
• 推荐场景：仅建议在严格隔离的 Docker 容器、临时性的自动化脚本测试、或高度受信任的离线环境中开启。
• 审计日志不可擦除：虽然系统不再实时询问，但所有的操作轨迹（Transcript）仍然会被记录并同步到后端或本地审计文件。Bypass 模式不是“秘密执行”，而是“自动执行”。
• 与 --bare 模式的区别：--bare 关注的是环境感知的极简化，而 --bypass-permissions 关注的是审批链的彻底断开。

推荐阅读路径

• 如果你想了解针对具体 Bash 命令的语义过滤规则，请看 Bash 权限规则：语义匹配与风险拦截。
• 如果你想了解物理层面的隔离是如何实现的，请看 权限与沙箱：双层防御体系。
• 如果你想通过智能方式减少审批而又不想完全关闭权限，请看 Auto Mode：基于分类器的自动化审批。

源码锚点

• claude-code-opensource/src/utils/permissions/PermissionMode.ts:66 — bypassPermissions 模式的配置定义与 UI 告警级别设置。

📄 src/utils/permissions/PermissionMode.ts — `bypassPermissions` 模式的配置定义与 UI 告警级别设置。L56-76 of 142

    color: 'planMode',
    external: 'plan',
  },
  acceptEdits: {
    title: 'Accept edits',
    shortTitle: 'Accept',
    symbol: '⏵⏵',
    color: 'autoAccept',
    external: 'acceptEdits',
  },
  bypassPermissions: {
    title: 'Bypass Permissions',
    shortTitle: 'Bypass',
    symbol: '⏵⏵',
    color: 'error',
    external: 'bypassPermissions',
  },
  dontAsk: {
    title: "Don't Ask",
    shortTitle: 'DontAsk',
    symbol: '⏵⏵',

• claude-code-opensource/src/utils/permissions/permissions.ts — 权限判断引擎中实现“短路放行”的关键代码点。

📄 src/utils/permissions/permissions.ts — 权限判断引擎中实现“短路放行”的关键代码点。L54-66 of 1487

  type PermissionRuleFromEditableSettings,
  shouldAllowManagedPermissionRulesOnly,
} from './permissionsLoader.js'

/* eslint-disable @typescript-eslint/no-require-imports */
const classifierDecisionModule = feature('TRANSCRIPT_CLASSIFIER')
  ? (require('./classifierDecision.js') as typeof import('./classifierDecision.js'))
  : null
const autoModeStateModule = feature('TRANSCRIPT_CLASSIFIER')
  ? (require('./autoModeState.js') as typeof import('./autoModeState.js'))
  : null

import {

• claude-code-opensource/src/utils/permissions/bypassPermissionsKillswitch.ts — 全局紧急开关：在特定托管环境下（如企业管控）强制禁用 Bypass 模式的逻辑。

📄 src/utils/permissions/bypassPermissionsKillswitch.ts — 全局紧急开关：在特定托管环境下（如企业管控）强制禁用 Bypass 模式的逻辑。L12-22 of 156

  createDisabledBypassPermissionsContext,
  shouldDisableBypassPermissions,
  verifyAutoModeGateAccess,
} from './permissionSetup.js'

let bypassPermissionsCheckRan = false

export async function checkAndDisableBypassPermissionsIfNeeded(
  toolPermissionContext: ToolPermissionContext,
  setAppState: (f: (prev: AppState) => AppState) => void,
): Promise<void> {