- Published on
深入剖析 Claude Code 权限与安全系统
- Authors
- Name
- 大聪明
- @wooluoo
引言
Claude Code 作为 Anthropic 推出的 AI 编程助手,其安全设计值得深入研究。当 AI 拥有执行 Shell 命令、读写文件、发起网络请求的能力时,如何确保它不会越界?答案藏在其精心设计的多层安全架构中。
本文基于 Claude Code 源码,从七个维度拆解其权限与安全系统。
1. 权限模型:三级规则体系
Claude Code 的权限模型建立在 allow / deny / ask 三种行为之上,每种行为都可以通过 PermissionRule 精确配置:
// 权限规则的核心数据结构
type PermissionRule = {
source:
| 'localSettings'
| 'userSettings'
| 'projectSettings'
| 'policySettings'
| 'flagSettings'
| 'command'
| 'cliArg'
| 'session'
ruleBehavior: 'allow' | 'deny' | 'ask'
ruleValue: {
toolName: string // 如 "Bash", "Edit", "WebFetch"
ruleContent?: string // 如 "npm publish:*", "domain:github.com"
}
}
规则来源有明确的优先级层级:
- policySettings / flagSettings:企业级策略,管理员强制,用户不可修改
- projectSettings:项目级
.claude/settings.json - userSettings:用户级
~/.claude/settings.json - localSettings:本地覆盖
- session / cliArg:运行时临时规则
一条 Bash(npm publish:*) 的 deny 规则可以精确阻止 AI 执行 npm publish,同时允许其他 npm 命令。这种细粒度的内容匹配让权限控制既有力度又有弹性。
2. 工具权限审批流程
每次 AI 调用工具时,权限系统执行一个严格有序的决策管线:
1a. 整个工具被 deny 规则拦截 → 直接拒绝
1b. 整个工具有 ask 规则 → 弹出审批(沙箱内命令可豁免)
1c. 工具自身的 checkPermissions 检查(如 Bash 的子命令匹配)
1d. 工具实现返回 deny → 拒绝
1e. 工具标记 requiresUserInteraction → 强制交互审批
1f. 内容级 ask 规则(如 Bash(npm publish:*))→ 即使在 bypass 模式也必须审批
1g. 安全检查(.git/, .claude/ 等敏感路径)→ bypass 不可豁免
2a. bypassPermissions 模式 → 允许(但 1f/1g 除外)
2b. 工具在 always-allow 列表 → 允许
3. 以上均未匹配 → 转为 ask,弹出用户审批
关键设计亮点:
1f 和 1g 是不可绕过的安全底线。即使用户启用了
bypassPermissions模式,内容级 ask 规则和敏感路径检查仍然生效。这防止了攻击者通过配置文件植入宽松规则来绕过安全限制。dontAsk 模式将 ask 转为 deny,而非放行。这遵循了最小权限原则——不确定时宁可拒绝。
auto 模式使用 AI 分类器替代人工审批。当分类器不可用时,通过
tengu_iron_gate_closed特性标志控制 fail-closed 还是 fail-open,默认 30 分钟刷新一次。
3. 沙箱实现:操作系统级隔离
Claude Code 的沙箱基于 @anthropic-ai/sandbox-runtime,在 macOS 上使用 Apple 的 sandbox-exec,在 Linux 上使用 bubblewrap(bwrap)。这是一个 操作系统级沙箱,而非进程级限制。
文件系统沙箱
// sandbox-adapter.ts 中的路径配置逻辑
const allowWrite: string[] = ['.', getClaudeTempDir()] // 默认可写:当前目录 + 临时目录
const denyWrite: string[] = []
const denyRead: string[] = []
沙箱的文件系统限制包含多层防护:
- 默认隔离:只有当前工作目录和临时目录可写
- settings.json 保护:所有层级的设置文件被加入 denyWrite,防止 AI 修改自身配置来逃逸沙箱
- .claude/skills 保护:Skills 具有自动发现和完整 Claude 能力的特性,必须与 commands 和 agents 同等保护
- Git bare repo 防护:检测并阻止在 cwd 下植入
HEAD、objects/、refs/等 Git 仓库骨架文件,防止通过core.fsmonitor等配置逃逸沙箱 - Git worktree 感知:自动检测 worktree 并将主仓库路径加入 allowWrite,确保正常的 Git 操作
网络沙箱
network: {
allowedDomains: [], // 从 WebFetch(domain:*) 规则中提取
deniedDomains: [],
allowUnixSockets: boolean | undefined,
allowLocalBinding: boolean | undefined,
httpProxyPort: number | undefined,
socksProxyPort: number | undefined,
}
网络限制支持域名白名单/黑名单、Unix socket 控制、本地端口绑定限制,以及 HTTP/SOCKS 代理转发。当 allowManagedDomainsOnly 策略启用时,只有管理员配置的域名可以访问。
平台适配
沙箱有完善的平台检测:macOS、Linux、WSL2+ 支持,WSL1 不支持。还支持 enabledPlatforms 配置限制沙箱仅在指定平台运行——这解决了一些企业只信任 macOS 沙箱的场景。
4. BashTool 的安全检查
BashTool 是 Claude Code 中最强大的工具,也是安全风险最高的。它有多层安全检查:
Shell 解析与 AST 分析
// bashSecurity.ts 中的危险模式检测
const COMMAND_SUBSTITUTION_PATTERNS = [
{ pattern: /<\(/, message: 'process substitution <()' },
{ pattern: />\(/, message: 'process substitution >()' },
{ pattern: /=\(/, message: 'Zsh process substitution =()' },
{ pattern: /\$\(/, message: '$() command substitution' },
{ pattern: /\$\{/, message: '${} parameter substitution' },
// ... 更多模式
]
系统使用 Tree-sitter 进行 AST 分析来检测以下威胁:
- 命令替换注入:
$()、反引号、进程替换等 - Zsh 特有攻击面:
zmodload、zpty、ztcp等模块命令,=cmd等号展开 - IFS 注入:通过修改内部字段分隔符绕过参数解析
- Git commit 替换:在 git commit 消息中注入命令
- Shell 引号不同步:利用引号和注释的交互绕过解析
- Unicode 空白字符:使用非标准空白字符隐藏恶意内容
危险模式黑名单
dangerousPatterns.ts 维护了一份跨平台代码执行入口点列表:
const CROSS_PLATFORM_CODE_EXEC = [
'python', 'python3', 'node', 'deno', 'ruby', 'perl',
'npx', 'bunx', 'npm run', 'yarn run', 'pnpm run',
'bash', 'sh', 'ssh', 'eval', 'exec', 'sudo', ...
]
在 auto 模式下,类似 Bash(python:*) 的 allow 规则会被自动剥离,因为这些规则实际上允许 AI 通过解释器执行任意代码,完全绕过分类器。
5. 策略限制系统(policyLimits)
policyLimits 是企业级的安全管控层,专门为 Team 和 Enterprise 用户设计:
// 策略限制的核心检查逻辑
export function isPolicyAllowed(policy: string): boolean {
const restrictions = getRestrictionsFromCache()
if (!restrictions) {
// HIPAA 合规:essential-traffic-only 模式下特定策略 fail closed
if (isEssentialTrafficOnly() && ESSENTIAL_TRAFFIC_DENY_ON_MISS.has(policy)) {
return false
}
return true // 默认 fail open
}
return restrictions[policy]?.allowed ?? true
}
设计特点:
- Fail open 默认:API 不可用时不会阻塞用户工作,但 HIPAA 合规场景下特定策略(如
allow_product_feedback)会 fail closed - ETag 缓存:使用 SHA256 校验和实现 HTTP 304 缓存,减少不必要的网络请求
- 后台轮询:每 60 分钟自动检查策略更新,管理员可以实时收紧或放松限制
- OAuth + API Key 双认证:Console 用户(API Key)和 Claude.ai 用户(OAuth)都支持
6. 信任对话框(TrustDialog)
每次在新工作区启动 Claude Code 时,系统会展示一个安全检查对话框:
// TrustDialog 检测的风险维度
- hasMcpServers: 项目配置了 MCP 服务器(可能执行任意代码)
- hasHooks: 配置了 PreToolUse 等钩子
- hasBashExecution: 权限规则允许 Bash 执行
- hasApiKeyHelper: 配置了 API Key Helper(执行外部命令)
- hasAwsCommands: 配置了 AWS CLI 命令
- hasGcpCommands: 配置了 GCP CLI 命令
- hasOtelHeadersHelper: 配置了 OpenTelemetry(可能泄露数据)
- hasDangerousEnvVars: 配置了危险环境变量
对话框会明确告知用户:"Claude Code'll be able to read, edit, and execute files here."(Claude Code 将能在这里读取、编辑和执行文件。)
关键设计:
- 主目录特殊处理:在
$HOME下信任只存储在会话内存中,不持久化到磁盘。这防止了恶意项目通过写入配置文件来永久获得信任。 - 项目级持久化:非主目录的信任状态保存在项目配置中,下次进入不再重复询问。
- 遥测上报:信任对话框的展示和接受事件会上报,用于安全态势分析。
7. 工作区信任机制
信任机制是整个安全体系的入口门控:
用户进入工作区
↓
检查 hasTrustDialogAccepted
↓ 未信任
展示 TrustDialog(扫描所有风险源)
↓ 用户选择"Yes, I trust this folder"
↓
根据目录类型存储信任状态
├─ $HOME → 会话内存(setSessionTrustAccepted)
└─ 其他 → 项目配置文件(saveCurrentProjectConfig)
↓
允许 Claude Code 开始工作
这个机制确保了:在用户明确确认信任之前,Claude Code 不会读取、编辑或执行工作区中的任何内容。
架构总览
┌─────────────────────────────────────────────┐
│ 用户 / 管理员 │
│ (TrustDialog / policySettings / permissions) │
└──────────────┬──────────────────────────────┘
↓
┌──────────────────────────────────────────────┐
│ 权限决策管线 │
│ deny规则 → ask规则 → checkPermissions │
│ → requiresUserInteraction → 内容级ask规则 │
│ → safetyCheck → bypassPermissions → allow │
│ → ask (默认) │
└──────────────┬───────────────────────────────┘
↓
┌──────────────────────────────────────────────┐
│ Auto Mode 分类器 │
│ acceptEdits 快速路径 → allowlist 快速路径 │
│ → AI 分类器(两阶段)→ denial tracking │
└──────────────┬───────────────────────────────┘
↓
┌──────────────────────────────────────────────┐
│ BashTool 安全层 │
│ Tree-sitter AST → 危险模式检测 │
│ → Shell 引号验证 → Zsh 攻击面防护 │
└──────────────┬───────────────────────────────┘
↓
┌──────────────────────────────────────────────┐
│ OS 级沙箱 │
│ macOS: sandbox-exec │
│ Linux: bubblewrap (bwrap) │
│ 文件系统隔离 + 网络隔离 + 配置文件保护 │
└──────────────────────────────────────────────┘
设计哲学总结
Claude Code 的安全设计体现了几个核心原则:
纵深防御(Defense in Depth):没有任何单一检查是唯一的防线。Bash 命令要经过规则匹配、AST 分析、危险模式检测、沙箱隔离四层关卡。
不可绕过的安全底线:敏感路径检查(1g)和内容级 ask 规则(1f)即使在最高权限的 bypassPermissions 模式下仍然生效。
Fail open with exceptions:默认情况下系统倾向于允许操作(fail open),但在 HIPAA 合规等场景下可以 fail closed。
渐进式信任:从 TrustDialog 的显式确认,到 session 级别的主目录信任,再到 allow 规则的细粒度授权,信任是逐步建立的。
企业管控能力:policySettings 和 policyLimits 为组织管理员提供了集中管控能力,可以强制执行安全策略而不依赖终端用户的自觉。
这种多层、渐进、可控的安全架构,为 AI 编程助手在获得强大能力的同时提供了可靠的安全保障。