Repository navigation
hook-augment emits nothing on 0.9.1-rc.1, including payloads that work on 0.9.0 #1388
Description
Problem
hook-augment on v0.9.1-rc.1 (macOS arm64, release tarball, permanent daemon active) exits 0 with no stdout/stderr for every payload, including ones 0.9.0 answers.
Evidence
One-file Python repo, indexed by the rc.1 binary:
echo '{"session_id":"probe","hook_event_name":"PreToolUse","tool_name":"Grep","tool_input":{"pattern":"create_stripe_checkout","path":"<repo>"},"cwd":"<repo>"}' | codebase-memory-mcp hook-augment
| binary | project name | result |
|---|---|---|
| 0.9.0 | default path slug | emits additionalContext, 1 symbol |
| 0.9.1-rc.1 | default path slug | silent, exit 0 |
| 0.9.1-rc.1 | custom name | silent, exit 0 |
SessionStart and SubagentStart payloads are silent too, so the cbm-subagent-reminder hook the rc installer adds is a no-op. cli search_graph returns correct results for the same projects, so this is specific to the hook path. Custom-name resolution from #1069 worked when I ran main at d587dea; on rc.1 both custom and default-slug are silent.
Expected fix
hook-augment emits additionalContext again for indexed projects; a regression test on the release path would catch the next one.
Activity
DeusData commentedon Aug 3, 2026
Thank you for testing known-good 0.9.0 payloads against
0.9.1-rc.1. The hook path has a tight default deadline and silent skip behavior, so a zero-output result can hide whether startup, daemon dispatch, or augmentation consumed the budget. I have routed this as a high-priority0.9.1-rcstability regression; the red case should assert both bounded completion and visible diagnostics for each failure stage.Merge pull request #1441 from DeusData/fix/1388-hook-conflict-notice
fix(hook): surface daemon build conflicts to the hook caller (DeusDat…
diag(daemon): name the cohort path that admits a mismatched build
diag(daemon): name the cohort path that admits a mismatched build
dergachoff commentedon Aug 26, 2026
Retested on v0.10.8:
hook-augmentis still silent here (fresh one-file repo, default-slug and custom-named index, PreToolUse and SessionStart, warm daemon), andhook-augment-timeouts.loggetsdeadline_exceeded ms=2000each time. WithCBM_HOOK_DEADLINE_MS=20000it emits correctly in ~2.4 s, of which ~2.3 s is user CPU before any hook work — the startup fingerprint hash tracked in #1335. So I think this issue is the same mechanism as #1335 and #1767 should close both; happy for this to be deduped into that one.DeusData commentedon Oct 18, 2026
Thank you, @dergachoff, for retesting this on 0.9.1-rc.1 and again on 0.10.8, and for tracing it to the same startup cost as #1335. Your
CBM_HOOK_DEADLINE_MS=20000measurement (about 2.3 s of user CPU before any hook work) was the key data point.That cost was the SHA-256 that every hook process computes over its own executable as the daemon build identity. #2575 (e93e438, first released in v0.12.0) runs it on the CPU's SHA instructions.
On current main (354ccec), Apple arm64, a one-file Python repo, a warm daemon and the default deadline, SessionStart returns 782 bytes and PreToolUse Grep and Bash return 347 bytes each. Each run takes 0.12 s wall and 0.09 s user CPU, and the timeout log stays empty.
Could you rerun your one-file repro on v0.12.1, with both the default-slug and the custom-named index and both PreToolUse and SessionStart, without the override? If they emit, we'll close this. The remaining cost on CPUs without SHA instructions is tracked in #2683.
dergachoff commentedon Oct 19, 2026
Retested on v0.12.1 without the deadline override. All four cases work now: default and custom-named index, PreToolUse and SessionStart. Each hook takes about 0.2 s and the timeout log is empty. OK to close, thanks!