随笔
Claude Code 源码解读 05：Hooks 怎样把外部规则插进关键节点
解释 UserPromptSubmit、PreToolUse、PermissionRequest、PostToolUse、Stop 等 Hooks 如何形成可编程纠偏层，以及它们自身的风险边界。
Hook 的价值不是多一个脚本入口，而是让外部规则能在关键事件上按语义介入。
快速了解
- Hooks 是可编程纠偏层，不是普通配置项。
- UserPromptSubmit 适合补边界，PreToolUse 适合卡副作用，Stop 适合完成前验收。
- Hook 自身也是高权限执行面，必须治理来源、匹配条件和输出。
- Claude Code 更像可编程扩展总线，Codex 更像生命周期策略引擎。
如果只想快速理解，可以先读这一节；如果要看源码机制，再往下看“主线与场景插入分类”和机制图。
设问与回应
| 设问 | 回应 |
|---|---|
| Hook 配置来源是单一 settings 字段吗？ | Hook 配置不是单一 settings 字段，而是来自用户配置、项目配置、插件、skill、session 等多种来源。源码里需要统一执行层，也需要配置快照来降低运行中被悄悄改写的风险。 |
PreToolUse 为什么比 PostToolUse 更适合作为副作用安全边界？ | PreToolUse 更适合作为副作用安全边界，因为它发生在工具真正执行前；PostToolUse 只能观察或补救结果，不能阻止已经发生的文件、网络或进程副作用。 |
PermissionRequest Hook 是不是可以替代人工审批？ | PermissionRequest Hook 不能替代人工审批。它可以参与审批流程、补充策略判断，但不能绕开 deny / ask，也不应该成为高风险操作的自动放行器。 |
| Claude Code Hooks 和 Codex Hooks 的架构差异在哪里？ | Claude Code Hooks 更像可编程扩展总线，覆盖输入前、工具前、权限请求、工具后、停止等多个事件；Codex Hooks 更像生命周期策略节点。前者灵活，但 Hook trust 和配置来源治理更重。 |
主线与场景插入分类
| 机制/模块 | 分类 | 我保留的判断 |
|---|---|---|
executeHooks() | 主线支撑 + 治理横切 | 所有用户配置、插件、skill、session Hook 的统一执行层 |
captureHooksConfigSnapshot() | 安全/治理横切 | 启动时捕获配置，减少隐藏修改风险 |
UserPromptSubmit | 主线前置纠偏 | 用户输入进入模型前的最后可编程检查点 |
PreToolUse | 主线工具治理 | 工具执行前的阻断、输入改写和上下文注入点 |
Stop / SubagentStop | 恢复支撑 + 治理横切 | 完成路径上的验收与补救 |
Claude Code 与 Codex 的 Hook 差异
我的对比判断是：Claude Code 更像“可编程扩展总线”，Codex 更像“生命周期策略引擎”。Claude Code Hooks 覆盖事件更广，配置来源也更复杂；代价是 Hook trust 必须被治理。
我对 Hook 的实操判断
Hook 最适合三件事：输入前补边界，工具前卡副作用，停止前做验收。它不适合承担所有错误恢复，也不能替代权限系统。