[FEATURE] Hook runtime execution telemetry — expose which hook fired, exit code, duration, and captured stderr/stdout

Summary

Claude Code hooks currently fail silently in many ways: PATH issues, wrong exit codes, hanging processes, project-subdirectory load failures, and false-positive hook-error labels. There is no runtime telemetry surface: a user cannot see which hook actually fired for the last tool call, what its exit code was, how long it took, or what it wrote to stderr.

Request: add a runtime diagnostics surface exposing, for each hook execution: name/source, matcher that matched, exit code, duration ms, captured stdout/stderr (bounded), and whether the result was treated as blocking.

Why existing issues do not cover this

Each of these is a symptom of runtime opacity — none ask for the general telemetry primitive:

• #6305 — Post/PreToolUse hooks silently not executing (14 👍)
• #38651 — Stop hook empty result in -p mode (11 👍)
• #22172 — 100% CPU hang w/ hooks + parallel instances (10 👍)
• #36793 — Project hooks not loaded in subdirectory (6 👍)
• #34713 — False "Hook Error" labels cause premature turn end (5 👍)
• #44707 — exit(1) silently non-blocking docs gap
• #46954 — Homebrew PATH silent fail (mine)
• #32376 — hook self-rewrite security (4 👍)

Each would be diagnosable in minutes with a telemetry view. Today they require guesswork.

Distinct from:

• #49778 (static hook visibility / supply-chain confirmation) — that covers at-rest visibility + install-time confirmation. This request covers runtime per-execution telemetry. The two are complementary.
• #35078 (closed) — addressed parallel dispatch + priority ordering, not observability.

Proposal (two minimal surfaces)

1. /hooks slash command listing each registered hook with its last run: exit code, duration, timestamp, captured stderr tail. Mirrors how /mcp lists server status.

1. New hook-result transcript event (machine-readable) with the same fields, tapped by the existing transcript_path plumbing so external tools can aggregate. No new tool surface required.

Request

1. Confirm whether a runtime diagnostics surface is on the roadmap.
2. If not, would a first minimal step be to capture hook exit code + stderr into the transcript JSONL so external tools can build the view?

---
Suggested labels: enhancement, area:hooks