bug(hooks): permission.request 词表与远端会话身份不一致导致处理器漏执行

[heibaitouxinshu-cmyk]

功能影响

显式启用权限 Hook 的会话可能完全不执行插件处理器：main 的前端词表缺少 permission.request；PR #34 补齐词表后，ACP 远端会话 ID 与本地 ID 不同时仍查找失败。可能漏掉插件预期的 deny/modify 决策。此报告不声称已证明真实工具越权或所有配置下的最终授权结果。

固定基线：main 3127ee4336b30c3f349fd7fe6cb2b69923c4ef3e；PR #34 39cad2925c59129d82aa217b6039a0b48d26a12d。2026-09-10重跑结果一致。

执行证据

直接执行真实 TypeScript 生产模块，只模拟 Tauri IPC、身份存储与 HookRuntime 边界。会话：id local-session、source profile:local-session、periId remote-acp-session，hooks显式含测试插件。

源码	Hook	请求ID类型	handler调用次数
main	message.user.beforeSend	本地	1
main	permission.request	本地	0
main	permission.request	ACP远端	0
PR #34	message.user.beforeSend	本地	1
PR #34	permission.request	本地	1
PR #34	permission.request	ACP远端	0

main警告：Pylon hook bridge received unknown anchor: permission.request。PR远端ID用例无警告，返回 action: continue, executed: 0, skipped: 0。

完整结果；可运行脚本。准备包含上述两个提交的仓库（可 fetch pull/34/head），在仓库根目录用 Node22 的类型擦除支持运行该脚本；可用第一个参数指定仓库目录。脚本固定提交，并断言对照与失败行为。这是模块级复现，不是原生 ACP 端到端权限证明。

源码链条

• 前端 resolveSession仅匹配本地 id/source。
• 词表在main缺少 permission.request。
• ACP权限解析读取 Agent 提供的 sessionId；#34 hook_bridge使用该 ID派发。

修复与验收

补齐跨语言词表契约；在 owner/runtime 和连接代次明确的入口规范化为本地会话身份。不要做无 owner 的全局 periId 回退。覆盖两运行时重复远端 ID、重连旧请求、未 opt-in、deny/modify/continue、超时取消、原生 ACP 往返，并让无法映射的请求有可诊断状态。

#34的文本冲突可以整合，但本功能问题不随文本合并自动解决，建议作为其验收阻塞项。

[AlchemistCxC]

维护方核验：属实（两处），且在 Ru5t/Reflector@73a5d7d0（2026-09-13）仍未修复

感谢报告。您的脚本 docs/tactical-blue/evidence/reproduce-hooks.mjs 已在主线仓库里，我们把它原样跑了一遍，并把同一 harness 指向 HEAD 追加了一组用例。结论：您表格里的六行逐格复现，且您对"词表补齐后仍有第二处身份缺陷"的判断成立。

一、独立复跑（原样）

运行方式（在临时 clone 内运行，避免脚本输出写进工作树；脚本只 git show <ref>:<path>，不联网、不 checkout）：

TMP=$(mktemp -d); git clone -q --shared --no-checkout . "$TMP/pv"
node docs/tactical-blue/evidence/reproduce-hooks.mjs "$TMP/pv"

ref	Hook	请求 ID	handler 调用	我方复跑
main 3127ee43	message.user.beforeSend	本地	1（对照）	✅ 一致
main 3127ee43	permission.request	本地	0	✅ 一致
main 3127ee43	permission.request	ACP 远端	0	✅ 一致
PR #34 39cad292	message.user.beforeSend	本地	1	✅ 一致
PR #34 39cad292	permission.request	本地	1	✅ 一致
PR #34 39cad292	permission.request	ACP 远端	0	✅ 一致

追加：把两个 ref 都换成 HEAD 73a5d7d0 再跑同一 harness → 在"词表补齐后本地 ID 应执行"那条断言上失败（AssertionError: 0 !== 1）⇒ 您报告的"main 缺词表"在 HEAD 依然成立，未随后续改动修复。PR #34（Chica/p55）目前仍是 OPEN 未合并。

二、逐条判定

您的主张	判定	HEAD 证据
main 前端词表缺 permission.request	属实（HEAD 仍缺）	src/plugin-runtime/hooks/hookTypes.ts:1-26 共 24 个锚点，无 permission.request
PR #34 补齐词表后本地 ID 可执行	属实	上表第 5 行；PR #34 未合并
补齐词表后 ACP 远端 ID 仍查找失败	属实（潜伏但成立）	上表第 6 行；结构证据见下
resolveSession 只匹配本地 id/source	属实	src/infrastructure/hooks/hookBridgeDispatcher.ts:39-41（session.id === sessionId || session.source === sessionId）
权限解析读 Agent 提供的 sessionId，并由该 ID 派发	属实	src-tauri/src/permission.rs:84-90（取 session/request_permission 的 params.sessionId，即 ACP 远端 id）；src-tauri/src/dispatcher/mod.rs:636-644（dispatch(Some(window), "permission.request", &permission.session_id, …)）

三、我们同意您的约束：前端不能做无 owner 的回退映射

Rust 派发的请求载荷只有 {provider, agentId, requestId, payload:{title,prompt,options}}（src-tauri/src/dispatcher/mod.rs:640-643）——不含本地会话 ID。前端手里只有远端 id 与 agentId，二者之间没有可用桥。所以身份规范化必须放在后端 owner/runtime 与连接代次明确的入口，这与您的结论一致。

四、我们补充的两点

1. 漂移在"派发面 vs 词表"，不是"文档滞后"：仓库内插件开发手册 §6.2 的锚点表（docs/说明书/Pylon-插件系统说明书-开发者版.md:383-391）与代码词表逐项一致（同为 24 个，都不含 permission.request）；而 Rust 侧自述的意图恰是二者一致——src-tauri/src/hook_bridge.rs:36 注释写着"发送链锚点名（[I01-A-DOC-01] 冻结 Release 单活与 AgentContext 边界 #1，与前端 HOOK_NAMES 词表一致）"。也就是说：派发面在发一个词表里没有的锚点。
2. dangerousHooks 复用同一份词表 ⇒ 双重不可达：src/plugin-runtime/packageManifest.ts:138-150 用 HOOK_NAMES 校验 manifest 的 dangerousHooks，未知锚点直接抛 '未知 hook 锚点'。因此插件既不能合法声明 permission.request，即使绕过声明，运行时锚点也会被词表拦成 0 调用。您"可能漏掉插件预期的 deny/modify 决策"的表述，实际面比它更宽：声明与执行两端都断。

五、与既有设计的关系（属实现缺口，非方案分歧）

维护方针对该锚点的设计（内部 P55 施工书）本就规定：permission.request 作为独立锚点、插在 dispatcher 的 bypass/auto 判定之前、payload 形状为 {provider, agentId, requestId, payload:{…}}、仅 allow/deny 短路。HEAD 的 Rust 实现与该规定一致（dispatcher/mod.rs:636-644）。缺的是把该锚点同步进词表/手册与身份规范化这两段契约——所以这是"契约未对齐"，不是设计分歧。

六、验收建议（供参考）

• 词表同步：HOOK_NAMES 补 permission.request，并同步仓库内手册 §6.2 的锚点表；建议加一道"锚点集一致性"门禁，避免跨语言再次漂移。
• 身份规范化：在后端 owner/runtime + 连接代次明确的入口把 ACP 远端 sessionId 映射为本地会话身份（或随请求携带本地 ID），不做前端全局回退。
• 覆盖：两 runtime 重复远端 ID、重连后的旧请求、未 opt-in、deny/modify/continue、超时取消，并让无法映射的请求落到可诊断状态（而非静默放行）。

七、影响边界（我们与您口径一致）

本核验不主张已发生真实工具越权，也未证明最终授权结果被改变；当前授权仍由既有 permission 流程闭环。成立的影响是：显式启用权限 Hook 的会话拿不到插件的 deny/modify/continue 决策，权限请求直接进入既有 bypass/auto/挂起流程。

---

核验方式：运行您附带的确定性脚本（原样 + HEAD 变体，如上）＋ 上述 file:line 静态核读。原始输出保留在维护方评审记录中。