Claude Code 权限管理与沙箱安全机制深度解析

理解 Claude Code 的两层安全防线——应用层权限管理 + OS 层沙箱隔离。

安全架构概览

Claude Code 采用纵深防御（Defense in Depth）策略，有两层独立但互相协作的安全机制：

┌─────────────────────────────────────────────┐
│            Claude Code 安全架构              │
│                                             │
│  ┌───────────────────────────────────────┐  │
│  │     第一层：应用级权限管理              │  │
│  │     (Node.js / 工具调用前拦截)         │  │
│  │                                       │  │
│  │  • allow/deny/ask 规则引擎            │  │
│  │  • auto 模式 AI 分类器                │  │
│  │  • 路径安全检查                        │  │
│  │  • 敏感目录保护                        │  │
│  └───────────────────────────────────────┘  │
│                                             │
│  ┌───────────────────────────────────────┐  │
│  │     第二层：OS 级沙箱隔离              │  │
│  │     (macOS sandbox-exec / Linux bwrap) │  │
│  │                                       │  │
│  │  • 文件系统读写限制                    │  │
│  │  • 网络访问控制                        │  │
│  │  • 进程隔离                            │  │
│  └───────────────────────────────────────┘  │
│                                             │
└─────────────────────────────────────────────┘

第一层：权限管理系统

权限检查完整流程

当 Claude 要调用一个工具时，权限系统按以下顺序检查：

1a. deny 规则检查 → 命中则直接拒绝 ❌
    ↓
1b. ask 规则检查 → 命中？
    ├─ 沙箱开启 + 命令会在沙箱内 → 跳过询问 ✅
    └─ 否则 → 弹窗询问用户
    ↓
1c. 工具自身权限检查（如 Bash 子命令规则）
    ↓
1d. 工具实现拒绝 → 拒绝 ❌
    ↓
1e. 工具需要用户交互 → 询问 ❓
    ↓
1f. 内容特定 ask 规则 → 即使 bypass 模式也生效
    ↓
1g. 安全检查（.git/, .claude/, .vscode/） → 始终询问 ❓
    ↓
2a. 权限模式检查
    ├─ bypassPermissions → 直接允许 ✅
    └─ normal → 继续
    ↓
2b. always-allow 规则 → 命中则允许 ✅
    ↓
3. 最终结果 → ask（询问用户）

权限模式

Auto 模式详解

Auto 模式使用 AI 分类器自动判断操作的安全性：

用户操作
  ↓
AI 分类器 (Classifier)
  ├─ 安全 → 自动允许 ✅
  ├─ 危险 → 自动拒绝 ❌（附带原因）
  └─ 不可用 → 根据 iron_gate 策略
       ├─ fail closed → 拒绝 ❌
       └─ fail open → 降级到正常模式

分类器还有拒绝限制（Denial Limits），连续被拒太多次会降级到手动审批。

不可绕过的安全检查

即使开启 bypassPermissions，以下操作仍需确认：

第二层：沙箱隔离

平台支持

沙箱做了什么？

沙箱在 OS 内核层面限制 Claude 执行的 Bash 命令：

permissions 如何同步到沙箱？

settings.json 中的 permissions
  │
  ├─ Edit(src/**) allow  →  sandbox filesystem.allowWrite += "src/**"
  ├─ Edit(/etc/**) deny  →  sandbox filesystem.denyWrite += "/etc/**"
  ├─ Read(~/.ssh/**) deny →  sandbox filesystem.denyRead += "~/.ssh/**"
  └─ WebFetch(domain:github.com) allow → sandbox network.allowedDomains += "github.com"

关键洞察：同一份 permissions 配置同时驱动两层安全机制。

两层联动：autoAllowBashIfSandboxed

这是最重要的联动逻辑：

Claude 要执行 Bash 命令
  ↓
沙箱开启？ → 否 → 正常权限检查（可能弹窗询问）
  ↓ 是
命令会在沙箱内运行？
  ├─ 排除命令 (docker等) → 否 → 正常权限检查
  ├─ dangerouslyDisableSandbox → 否 → 正常权限检查
  └─ 是 → 自动允许 ✅（不弹窗）

原理：OS 级沙箱已经限制了命令能做的事，再让用户逐条审批就是多余的。

企业级安全管理

Policy Settings（管理员配置）

通过 MDM 或 /etc/claude-code/managed-settings.json 部署：

{
  "permissions": {
    "deny": ["Bash(curl *)", "WebFetch(*)"],
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["internal.company.com"]
    }
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true
}

管理员锁定能力

安全最佳实践

个人用户

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true
  },
  "permissions": {
    "deny": [
      "Bash(rm -rf /)",
      "Edit(//.ssh/**)"
    ],
    "allow": [
      "Read(*)",
      "Bash(npm test)",
      "Bash(git *)"
    ]
  }
}

团队项目

{
  "permissions": {
    "deny": [
      "Bash(npm publish*)",
      "Bash(docker push*)",
      "Edit(//.env*)"
    ],
    "ask": [
      "Bash(git push*)",
      "Edit(.github/**)"
    ],
    "allow": [
      "Read(*)",
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff*)"
    ]
  }
}

高安全环境

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": []
    },
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws", "~/.gnupg"]
    }
  },
  "permissions": {
    "defaultMode": "normal",
    "disableBypassPermissionsMode": "disable"
  }
}