[bug] defaultTimeoutMs: 0 使全部 hook fail-open，误配置应在加载时失败 — 附可 cherry-pick 修复

[ericcaiwx-star]

摘要 / Summary

defaultTimeoutMs: 0（或负数 / 小数）能通过插件 Config，但 bash 执行器拒绝 timeoutMs <= 0。runHook 把执行器拒绝收成「基础设施故障」并 fail-open：hook 被跳过，工具照跑。仓库约定是「Misconfiguration fails loud」，stderrSummaryMaxChars 已经在 load 时校验，timeout 没有。

A zero hook timeout is a silent security bypass, not a disabled hook.

复现 / Repro

hooks-claude-code:
  configPath: ./hooks.json
  defaultTimeoutMs: 0

或 hooks.json 里 "timeout": 0 再叠加默认 0。每个 hook 调用变成 exitCode: undefined 的非阻塞错误，PreToolUse deny 永远不会发生。

根因 / Root cause

hooks-claude-code / hooks-codex 的 apply() 对 stderrSummaryMaxChars 调用 assertPositiveInteger，对 defaultTimeoutMs 只做 ?? DEFAULT。0 原样传给 runHook → bash.resolve() 抛错 → catch 成 fail-open。

修复 / Fix (cherry-pick ready)

• 分支：https://github.com/ericcaiwx-star/deepseek-harness/tree/fix/hook-timeout-misconfig-fails-loud
• commit：4f4597a64c — fix(hooks): reject non-positive defaultTimeoutMs at load
• 对比：master...ericcaiwx-star:deepseek-harness:fix/hook-timeout-misconfig-fails-loud

两个桥在读 hooks.json 之前 拒绝非正整数 defaultTimeoutMs，与 stderrSummaryMaxChars 对称。

验收 / Acceptance

pnpm exec vitest run packages/hooks/hooks-claude-code/tests/config.spec.ts packages/hooks/hooks-codex/tests/config.spec.ts 通过。defaultTimeoutMs 为 0 / -5 / 1.5 / NaN 时插件加载抛错。

[zhou256bug]

我是外面看这条的开发者，看了 fix/hook-timeout-misconfig-fails-loud。

defaultTimeoutMs: 0 能过插件 Config，bash executor 拒绝 timeoutMs <= 0，runHook 再把 executor reject 收成 exitCode: undefined 的非阻塞错误，合成结果是 hook 被跳过、工具照跑。旁边的 stderrSummaryMaxChars 已经在 load 时做正整数校验，timeout 没有，这个不对称成立。load 时 assertPositiveInteger 说得通。

想把严重度说准：默认值是 10 分钟，要显式写成 0 才会走进这条旁路，不是开箱即失效。hooks.json 里单条 timeout: 0，以及「凡 executor reject 都走 fail-open」要不要拆开，我觉得是后续问题，不必塞进这一条。

[ericcaiwx-star]

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

默认是 10 分钟，只有显式写成 0 才走进这条旁路，不是开箱即失效。hooks.json 单条 timeout: 0，以及「凡 executor reject 都 fail-open」，另开，不塞进这一条。

[zylos-luna]

Traced the full chain in master and it holds: apply() validates stderrSummaryMaxChars with assertPositiveInteger but only defaults defaultTimeoutMs; runHook forwards it as timeoutMs; bash-local's positive-finite assertion rejects it; and runHook's catch collapses that rejection into an exitCode: undefined non-blocking result — so a PreToolUse deny hook is skipped and the tool executes. Load-time rejection in both bridges, symmetric with the existing check, is the right shape and the coverage-cases tier tests it in the real harness path. One caveat: a per-hook "timeout": 0 in hooks.json takes the timeoutSec * 1000 branch and reaches the identical fail-open bypass, so this closes the config-level door but not the per-hook one — worth folding into the same validation rather than deferring, since it's the same security property.

[Xilink-Lin]

方向对，范围不够。

0 能过插件 Config，bash executor 拒 timeoutMs <= 0，runHook 收成 exitCode: undefined 非阻塞错误 → hook 被跳过、工具照跑。旁边的 stderrSummaryMaxChars 已经在 load 时 assertPositiveInteger，timeout 没有。load 时拒绝非正整数，形状对。默认 10 分钟，必须显式写成 0 才走进旁路，不是开箱即失效。

同一条安全性质还有一半没堵：hooks.json 里单条 "timeout": 0 走 timeoutSec * 1000，一样 fail-open。zylos-luna 说应该折进同一条校验，我同意——都是 load 时能看见的误配置，拆出去容易让人以为门已经关上。更底层的「凡 executor reject 都 fail-open」是设计问题，可以另开，但 per-hook timeout: 0 不该另开。

[ericcaiwx-star]

同意，per-hook timeout: 0 和 defaultTimeoutMs: 0 是同一条安全性质，不该另开。

已在两个 bridge 的成功 parse 之后校验每条 hook 的 timeout / timeoutSec：必须是正整数（秒），否则加载失败。放在 parse 的 try/catch 外面，避免被收成「读配置失败 → 一个 hook 都不注册」的 fail-open。runHook 对 executor reject 的 fail-open 仍是设计问题，另开。

commit：47a28a3043（同一分支 fix/hook-timeout-misconfig-fails-loud）。