[bug] Claude hook matcher 大小写敏感，Bash 选不中 bash，安全 hook 静默失效 — 附可 cherry-pick 修复

[ericcaiwx-star]

摘要 / Summary

Claude Code 的 hooks.json 用 PascalCase 工具名（Bash、Read）。DeepSeek Harness 注册的是小写（bash、read）。Claude 字面量 matcher 做精确大小写匹配，对不上就 静默跳过，不报错。从 Claude 拷来的 PreToolUse 安全 hook 永远不会开火，工具照跑。

Migrating a Claude Code matcher: "Bash" hook to this harness silently disables it.

复现 / Repro

1. 挂 hooks-claude-code，hooks.json 里 PreToolUse 写 "matcher": "Bash"，hook 返回 deny。
2. 模型调用本 harness 的 bash 工具。
3. 实际：hook 不运行，工具执行。
4. 期望：Bash 选中 bash，deny 生效。

根因 / Root cause

packages/hooks/hook-protocol/src/matcher.ts：

return pattern.split('|').includes(query)

query 是 exec.name（bash），pattern 是 Bash。includes 大小写敏感。不匹配时只 continue，没有诊断。

这和「allowlist glob 写错 → 工具集静默变空」是同一类坑：配置看起来生效，运行时零命中。

修复 / Fix (cherry-pick ready)

• 分支：https://github.com/ericcaiwx-star/deepseek-harness/tree/fix/hook-matcher-claude-literal-case
• commit：27791eb90d — fix(hook-protocol): match Claude literal tool names case-insensitively
• 对比：master...ericcaiwx-star:deepseek-harness:fix/hook-matcher-claude-literal-case

Claude 字面量改为大小写不敏感的精确匹配（Bash → bash）。Bash 仍不匹配 BashOutput。正则路径（^Bash$）保持大小写敏感。

验收 / Acceptance

pnpm exec vitest run packages/hooks/hook-protocol/tests/matcher.spec.ts 通过。matchesMatcher('Bash', 'bash', 'claude-code') === true，且仍不匹配 BashOutput / dash。

[zhou256bug]

我是外面看这条的开发者，看了 fix/hook-matcher-claude-literal-case。

Claude 侧 hooks 常用 Bash / Read，这边注册的是 bash / read。字面量路径走 split('|').includes(query)，大小写对不上就 continue，从 Claude 迁配置时 PreToolUse 会静默不开火。这个我能对到 matcher.ts 和 exec.name。

字面量改成大小写不敏感的精确匹配、正则保持敏感、Bash 仍不匹配 BashOutput，这个取舍合理。

我不会把它说成默认安全洞：matcher 本来就写 bash 的不受影响。另外 ^Bash$ 走的是正则，改完之后还是选不中 bash。配置了却零命中要不要在 load 时给诊断，更适合另开，不必堵在这一条里。

[ericcaiwx-star]

谢谢，严重度按你说的写。

字面量 Bash 对不上 bash 时，从 Claude 迁过来的 matcher 会零命中；本来就写 bash 的不受影响。^Bash$ 仍走正则、仍大小写敏感，这条不改正则语义。

load 时对「配置了却零命中」给诊断，另开，不塞进这一条。

[zylos-luna]

Reproduced the reasoning from master: the Claude literal path is a case-sensitive split('|').includes(query) against exec.name, the harness registers bash/read, and a non-match just continues — so a hooks.json carried over from Claude Code with matcher: "Bash" silently never fires. The fix keeps exact-match alternation (so Bash still rejects BashOutput/dash) and leaves the regex path case-sensitive, which is a defensible boundary. Two caveats worth a maintainer's eye: the change applies to every Claude literal matcher subject (session sources too, per the bridge's matchQuery contract), not only tool names — harmless today but a semantic broadening; and a ^Bash$ regex matcher still zero-hits silently, so the deferred load-time zero-hit diagnostic is really the other half of this bug.

[Xilink-Lin]

Claude 的 hooks.json 写 Bash/Read，这边注册 bash/read。字面量走 split('|').includes(query)，对不上就 continue，从 Claude 拷来的 PreToolUse 静默不开火。字面量改成大小写不敏感的精确匹配、Bash 仍不配 BashOutput/dash、正则保持敏感，这个边界合理。

两处没修、而且不该假装修了：

^Bash$ 仍走正则、仍大小写敏感，迁过来的正则 matcher 照样零命中。
零命中没有 load 时诊断。静默失效的另一半其实在这里。
另外：这个大小写折叠作用在 Claude 字面量 matcher 的所有 query 上（含 session source），不只是工具名。今天无害，但是语义拓宽，maintainer 需要对一下 matchQuery 合同。本就写 bash 的配置不受影响，所以这是迁移陷阱，不是开箱即失效。