随笔
Claude Code 源码解读 08：安全边界为什么不能只靠弹窗
从工具可见性、deny 优先、path validation、sandbox、MCP、bridge、workspace trust 和多 agent 风险面看 Claude Code 的安全治理。
安全不能写成“有权限弹窗所以安全”。Claude Code 的安全治理分布在工具可见性、配置源、path validation、sandbox、MCP、bridge 和 workspace trust 里。
快速了解
- 安全不是一个弹窗，而是一组贯穿工具可见性、权限、Hook、路径、sandbox、MCP 和 bridge 的边界。
- deny 优先很关键，auto / bypass 不等于无限通行。
- project settings 不能自我开启高风险能力，因为项目文件本身未必可信。
- MCP、remote、bridge 都是外部信任边界，需要单独治理。
如果只想快速理解，可以先读这一节；如果要看源码机制，再往下看“主线与场景插入分类”和机制图。
设问与回应
| 设问 | 回应 |
|---|---|
| 模型看到工具前，工具面是否已经被 deny rule 收缩？ | 模型看到工具前，工具面就应该被 deny rule 和场景条件收缩。安全边界如果等到工具执行时才出现，模型已经在不可用能力上规划了行动。 |
auto / bypassPermissions 是否等于无条件通行？ | auto / bypassPermissions 不等于无条件通行。它们改变的是部分确认路径，不是取消工具语义、路径校验、高风险 opt-in 和外部连接治理。 |
| 为什么 project settings 不能自我开启高风险 opt-in？ | project settings 不能自我开启高风险 opt-in，因为项目文件本身就是不完全可信输入。如果仓库能自行放开高风险能力，权限模型会被分析对象反向控制。 |
| MCP、bridge、remote control 为什么要作为外部信任边界处理？ | MCP、bridge、remote control 都连接外部系统或远端执行面，风险不止是本地工具调用。它们需要单独的配置、审批、OAuth、组织策略和审计边界。 |
主线与场景插入分类
| 机制/模块 | 分类 | 我保留的判断 |
|---|---|---|
assembleToolPool() / filterToolsByDenyRules() | 安全/治理横切 | 在模型看到工具前收缩工具面 |
runPreToolUseHooks() | 安全/治理横切 | 工具执行前的外部策略插入点 |
hasPermissionsToUseTool() | 安全/治理横切 | 合并规则、工具专属权限、mode、auto/headless 行为 |
pathValidation | 安全/治理横切 | 把字符串路径转成 workspace 和规则下的判断对象 |
| MCP / bridge / remote control | 外部信任边界 | 需要配置、审批、OAuth、组织策略和审计共同治理 |
安全不是单点，而是顺序
deny 优先是核心。auto mode 和 bypassPermissions 不能被写成“放开所有限制”。它们仍处在权限语义、工具专属检查和高风险 opt-in 约束里。
从 Codex 差异拆解安全边界
Codex 的差异价值，也不是简单问“集中式安全好，还是分布式安全好”。更合理的拆法是先把安全问题还原成几层边界：模型能不能看到这个工具，工具输入是否合法，外部 Hook 能不能改写或阻断，权限规则如何合并，路径是否落在可信 workspace，外部 MCP / bridge / remote control 是否越过了本地信任边界。
把这些层拆开之后，Claude Code 的设计才更容易看清：deny rule 先收缩工具面，输入校验把自然语言参数变成可判断对象，PreToolUse Hook 提供外部策略插入点，permission/mode 处理用户授权语义，path validation 处理文件系统边界，MCP/bridge/remote control 单独进入外部信任治理。Codex 对比可以继续追问的是：策略是否集中到生命周期节点，执行点是否还保留贴近副作用的细粒度检查，两者之间有没有可审计的一致性。这个对比带来的设计理解是：优秀 agent harness 的安全不是一个弹窗，而是把“可见、可用、可执行、可越界”的每一步都变成可解释的控制点。