Permission & Security 模块对比分析

1. 模块边界

这里讨论的是工具调用前的权限裁决模型、规则表达、用户确认链路与安全边界，不展开讲 UI 交互细节。

2. Claude Code：多来源裁决的权限系统

2.1 关键源码路径

• claude-code-rev/src/utils/permissions/permissions.ts：权限规则聚合、匹配、提示文案、更新持久化等核心逻辑。
• claude-code-rev/src/utils/permissions/permissionsLoader.ts：从不同设置源装载规则。
• claude-code-rev/src/utils/permissions/permissionRuleParser.ts：把字符串规则解析成可匹配的权限值。
• claude-code-rev/src/utils/permissions/PermissionMode.ts：权限模式定义。
• claude-code-rev/src/utils/permissions/bashClassifier.ts、yoloClassifier.ts、classifierDecision.ts：自动分类路径。
• claude-code-rev/src/services/tools/toolExecution.ts、src/services/tools/toolHooks.ts：工具执行前后接入权限和 hook。

2.2 权限模型

Claude Code 的权限系统是“模式 + 规则 + 自动裁决 + hook”的组合：

• 模式层决定默认姿态，例如 default、plan、bypass、acceptEdits 等。
• 规则层把 allow / deny / ask 规则按来源聚合，来源包括 settings、CLI、session、command 等。
• 自动裁决层在特定场景会调用 classifier，为 shell 命令等高风险操作做额外判断。
• hook 层允许外部逻辑在工具执行前后插入拦截。

2.3 运行特点

• 并不是简单命中一条规则就结束。实际结果会综合模式、显式规则、hook、classifier、工作目录限制等因素。
• permissions.ts 负责生成“为什么要求批准”的可解释消息，来源包括 rule、hook、classifier、sandbox override、working dir 等。
• 权限更新支持会话级和持久化级写回，这也是它需要 loader/parser/update 多模块配合的原因。

2.4 安全边界

• 对 shell 和路径的防护是重点，相关逻辑分散在 pathValidation.ts、dangerousPatterns.ts、shellRuleMatching.ts 等模块。
• 因为 Claude Code 同时支持 MCP、plugin、agent、worktree 等能力，所以权限系统必须覆盖跨模块调用，而不是只看本地文件工具。

3. Opencode：规则优先的轻量权限系统

3.1 关键源码路径

• opencode/packages/opencode/src/permission/index.ts：权限服务、待审批请求、事件总线、规则持久化。
• opencode/packages/opencode/src/permission/evaluate.ts：规则匹配函数，按最后命中的 wildcard 规则返回 allow / deny / ask。
• opencode/packages/opencode/src/permission/schema.ts：权限请求 ID 类型。
• opencode/packages/opencode/src/permission/arity.ts：参数维度校验。
• 调用侧示例：tool/skill.ts 会在加载技能前调用 ctx.ask()；session/processor.ts 在 doom loop 检测时通过 Permission.ask() 请求确认。

3.2 权限模型

Opencode 的权限模型明显更直接：

• 规则就是三元组：permission、pattern、action。
• evaluate() 把多个 ruleset 展平后做 wildcard 匹配，并以最后命中的规则为准。
• 没命中就默认 ask。

3.3 运行特点

• Permission.ask() 先用项目规则集和已批准规则集做评估。
• 只要任一 pattern 命中 deny，立即拒绝并抛出 DeniedError。
• 只有存在 ask 才会发出权限请求事件，等待用户回复 once / always / reject。
• 用户选择 always 后，会把当前 permission + always patterns 写入已批准规则集，并尝试自动释放同 session 下其他已满足条件的 pending 请求。

3.4 安全边界

• Opencode 没有看到 Claude Code 那种多路 classifier 裁决，也没有复杂的 hook 优先级系统。
• 它更依赖显式规则和显式 ask。
• 但它补了一个很实用的边界条件：SessionProcessor 会检测连续三次相同工具、相同输入的调用，触发 doom_loop 权限确认，避免模型在坏状态下无限重复。

4. 核心差异

维度	Claude Code	Opencode
规则来源	多来源合并：settings、CLI、session、command 等	项目规则集 + 已批准规则集
决策结构	模式、规则、hook、classifier、目录限制共同参与	wildcard 规则命中后直接给出 allow/deny/ask
自动裁决	有 classifier 与更复杂的自动判断链	没有同等级的自动分类层
待审批管理	和工具执行、hook、模式深度联动	Permission.ask/reply 独立维护 pending 队列
特殊保护	shell、路径、sandbox、MCP 等全局覆盖	doom loop 防护更明确、实现更直接

5. 设计取舍

5.1 Claude Code 的取舍

• 目标是复杂运行环境下的统一安全治理。
• 因此权限系统需要理解工具类型、来源、hook、工作目录、classifier 结果和可持久化规则。
• 成本是系统复杂，理解与调试门槛高。

5.2 Opencode 的取舍

• 目标是把权限系统做成可预测、容易解释的规则引擎。
• 因此它把 ask/allow/deny 做成清晰的显式状态，配套一个简单但可落盘的审批流。
• 成本是自动化程度和细粒度保护不如 Claude Code 丰富。

6. 结论

Claude Code 的权限系统偏“企业级安全治理引擎”，重点是多来源裁决和高风险场景防护；Opencode 的权限系统偏“轻量审批与规则匹配器”，重点是规则清晰和调用链简单。两者不是能力有无的问题，而是复杂治理与可预测性的不同取舍。