No PostToolUse hook has completed on this machine since 2026-08-12 (formatters silently not running)

[kyle-sexton]

Symptom

No PostToolUse hook on this machine has produced a completion or an observable effect since 2026-08-12T09:07:17Z. Nine distinct hooks across six plugins stopped within a roughly ten-hour window that day and have produced nothing in the nineteen days since:

skill-usage-audit, markdown-format, typos-format, eol-normalizer, biome-format, bash-format, cli-flag-verify, stale-path-verify, skill-reference-verify, actionlint-check.

Adjacent events are healthy over the same period. PreToolUse logged 2,404 telemetry records today; PostToolUseFailure logged 7. Every PostToolUse dispatch today ends in a hook_cancelled transcript attachment, with zero hook_success records for any PostToolUse:* hook.

The practical consequence is not limited to telemetry: the format-on-write hooks are silently not running, so files land unformatted with no user-visible error.

Reproduction

Minimal and self-contained. No plugins needed, roughly two minutes. Add to .claude/settings.json, restart, then Write any file:

{"hooks":{
  "PreToolUse":[{"matcher":"Write","hooks":[{"type":"command","command":"date -u +pre-%FT%TZ >> /tmp/hookprobe.log"}]}],
  "PostToolUse":[{"matcher":"Write","hooks":[{"type":"command","command":"date -u +post-%FT%TZ >> /tmp/hookprobe.log"}]}]}}

Expected: one pre- line and one post- line. Observed here: pre- only. Corroborate in the transcript (~/.claude/projects/*/*.jsonl): the PostToolUse:Write record is {"type":"hook_cancelled",...} with no hook_success counterpart.

Two independent effect tests reached the same place:

• A live Skill tool call produced no store row, no telemetry envelope, and nine hook_cancelled / PostToolUse:Skill records.
• A .md file written with trailing whitespace and a misspelling was still unformatted two minutes later, with a hook_cancelled / PostToolUse:Write record for that exact toolUseID.

What is ruled out

• Kill switch. No skill_usage* key in any of the four settings scopes or ~/.claude.json; the manifest default is true.
• Registration drift. All four installed plugin-cache versions register PostToolUse matcher Skill.
• Hook correctness. Fed a synthetic payload directly, the hook writes correct rows in both a normal checkout and a linked git worktree.
• Timeout as the whole story. markdown-format measures 8.2s inside a 15s budget and is equally dead.

Boundary, stated conservatively

• Last known good: 2026-08-12T09:07:17Z. First confirmed bad: 2026-08-31. The window cannot be narrowed, because no telemetry exists inside it and that absence is the symptom.
• No version can be pinned. Transcript retention only reaches 2026-08-23. Versions observed since, all bad: 2.1.238, 2.1.241, 2.1.243, 2.1.245, 2.1.251, 2.1.252. This is "not reproducible against a known-good build on this machine", not "regressed in version X".
• One machine, unconfirmed elsewhere. No second host was tested. This is a report, not an established product defect.
• No exact upstream match. The nearest, Plugin hooks.json: command hooks silently dropped for PreToolUse/PostToolUse events anthropics/claude-code#34573, is closed and predates this; open candidates (#63047, #42336) are Desktop/Cowork-scoped rather than CLI.

Recorded dissent

A fresh-context verifier independently reproduced the fleet-wide finding and then disputed the disposition, arguing for a two-layer verdict: upstream dispatch failure plus a repo-owned fix, raising skill-usage-audit's declared 5s timeout in hooks.json, on the grounds that it measured 15.4 to 37.6s over 6 of 6 runs while its sibling tool-failure-audit at the same budget came in at 0.3 to 2.9s. Its argument: "If Claude Code's PostToolUse dispatch were fixed tomorrow, this hook would still fail on this machine."

That fix is not being made, for two reasons. It is unfalsifiable at any value while no PostToolUse hook completes at all, and the measurements are load-contaminated: they were taken while bash -c 'exit 0' itself cost 1.1s on this host, and the same hook's two recorded historical runs on the same machine and code were 1181ms and 2261ms, comfortably inside 5s. The durable part of that observation is filed separately as a spawn-count performance finding.

The verifier also corrected three claims in the original investigation, all accepted:

1. An argument that hook_cancelled records lacking timedOut proved abort rather than timeout was invalid. The binary's wrapper rebuilds the attachment unconditionally and discards that field, so it is absent for every cause. The conclusion survives on the telemetry cutoff; that particular reasoning does not.
2. "Cancels them before they run" overstates the evidence. tool-failure-audit wrote 7 rows today at timestamps with no corresponding cancellation, so a hook can execute despite a recorded cancellation. The defensible claim is "produces no completions".
3. A "worktree is clean" claim was false when stated (eight paths, from concurrent sibling agents rather than the hook work).

A ConfigChange lead was considered and dropped: five lifetime firings in a 21,609-line log, last at 2026-08-11T23:33:06Z, which is inside the same window rather than before it, and a hook that only fires on config change tells you nothing by going quiet.

[kyle-sexton]

Path forward

The cause is not identifiable from this machine's existing state, so the next steps are about producing evidence that does not exist yet rather than re-reading evidence that does. Recorded so this does not stall as an open question with no next action.

1. Establish whether it is this machine or the product. Highest value, cheapest, and it decides everything after it. Run the probe from the Reproduction section on a second machine with a different Claude Code install. Two outcomes, two different investigations:

• Also broken there: a product regression worth reporting upstream with a defensible boundary.
• Works there: local state, and the next step is a bisect of this install rather than a bug report.

2. If it is local, bisect the install rather than the version. The version boundary is unpinnable (transcript retention starts 2026-08-23, six versions observed, all bad), so bisecting versions cannot work. Bisect state instead, in this order, restoring after each:

• --settings with a minimal settings file containing only the two probe hooks, which isolates the whole configured hook surface.
• CLAUDE_CONFIG_DIR pointed at an empty directory, which isolates ~/.claude accumulated state, including the 2,404-record-per-day telemetry the working PreToolUse path writes.
• A single enabled plugin, then none, which isolates fleet size and any one plugin's registration.

3. Capture what the transcript does not. Every attempt so far reads hook_cancelled attachments after the fact, and the binary's wrapper discards command, durationMs, timedOut and timeoutMs before they reach the transcript, which is what made the original timing inference invalid. claude --debug writes the hook lifecycle before that wrapper runs, so a single debug-mode session with the probe hooks attached would show whether the dispatch is refused, started and killed, or never scheduled. That distinction is currently unknown and is the whole question.

4. Only then, upstream. With a second-machine result and a debug-log capture, this becomes reportable with a real boundary. Without them it is one host, no version, and a symptom, which is why nothing has been filed upstream yet.

What is deliberately not being done

No fix is being attempted here. Raising skill-usage-audit's declared timeout was proposed and rejected: it produces no rows at any value while zero PostToolUse hooks complete at all, markdown-format sits at 8.2s inside a 15s budget and is equally dead, and the measurements behind the proposal were taken while bash -c 'exit 0' itself cost 1.1s on this host. An unfalsifiable change shipped under a root cause of "not repo-owned" would be worse than leaving this open.

The durable part of that observation is filed separately as #3550.

[kyle-sexton]

This was generated by AI during triage.

Claiming for triage-only evaluation (no execution).

---

Generated by Claude Code

[kyle-sexton]

This was generated by AI during triage.

Triage: step 1 of the path forward executed — probe PASSES on a second machine

The path-forward comment names the second-machine probe as the highest-value next step and the one that decides everything after it. This triage lane runs on a different host with a different Claude Code install, so it ran that probe.

Result: PostToolUse dispatches normally here

Three independent tests, all on this host, Claude Code 2.1.258:

1. The exact probe from the Reproduction section, isolated config directory (CLAUDE_CONFIG_DIR pointed at an empty dir) and minimal --settings carrying only the two probe hooks:

pre-2026-09-06T21:10:50Z
post-2026-09-06T21:10:50Z

2. Same probe against this machine's real ~/.claude, full accumulated state and the whole installed plugin fleet:

pre-2026-09-06T21:11:25Z
post-2026-09-06T21:11:25Z

3. A real plugin PostToolUse hook, not a synthetic probe. Wrote a markdown file carrying a deliberate misspelling inside this repo. The typos-format hook fired and returned its finding as additional context on the Write:

typos-format is report-only — probe-fmt-check.md was NOT modified. Findings: "Teh" (line 4) should be "The".

Both pre- and post- lines appear in every run, and a plugin-registered PostToolUse hook produced an observable effect. There is no hook_cancelled-without-completion pattern on this machine. (The probe file was removed; the tree is clean.)

Corroborating detail from the same session: the guardrails PreToolUse bypass guard blocked a heredoc write of the probe settings file, so both hook phases are demonstrably live here.

What this settles, and what it does not

Settled: "no PostToolUse hook completes" is not a general property of Claude Code 2.1.x. The dispatch path works, including at a version newer than every one listed as bad (2.1.238 through 2.1.252), with a full plugin fleet and with accumulated user state.

Not settled, and the reason this is not yet a clean "local state" verdict. This host is Linux. The reporting host is evidently Windows: the same fleet carries a drive-root /tmp guard, an MSYS path-conversion guard, and the sibling worktree report describes D:\ strays. A Windows-specific dispatch regression would pass here and still be a real product defect. So this is a genuinely different machine, but it is not the same-OS second machine the path forward's decision tree assumes, and it narrows the space rather than closing it.

Two of the three branches from that decision tree survive:

• Windows-specific product behavior. Still open. Untested.
• This install's local state. Still open, and now the cheaper of the two to test.
• A general product regression across platforms. Ruled out by the runs above.

Note also that run 1 and run 2 together already cover bisect steps 2a and 2b from the path-forward comment, but only on this OS, so they do not transfer to the reporting host.

Why this stays with a human

Not a decision problem, a capability blocker. Every remaining step needs the affected Windows host, which no autonomous lane can reach:

1. Run the two-line probe on the reporting machine under claude --debug. The path-forward comment already identifies this as the one capture that distinguishes refused, started-and-killed, and never-scheduled, and that distinction is still unknown. Now higher value than before, because a passing Linux result means a Windows debug log is being compared against a known-good baseline rather than against nothing.
2. Run the same probe on any second Windows host. This splits the two surviving branches in one step. Broken there points upstream with a real boundary; clean there points at the install.
3. Only if both point at the install, bisect it in the order the path-forward comment gives.

If step 2 shows Windows-wide breakage, the upstream report can now assert that Linux 2.1.258 is unaffected, which is a materially stronger boundary than the one-host-no-version position that has kept this unfiled.

Labels: replacing the raw priority: needs-triage with priority: high (silent formatter and telemetry loss on the primary development machine, three weeks and running); adding needs-human, work-class: read-only (the remaining work is diagnosis producing no repository mutation).

Explicitly unchanged: no fix attempted, and the rejected skill-usage-audit timeout change stays rejected for the reasons already recorded. Nothing here disturbs #3550.

Triage claim released.

---

Generated by Claude Code

[kyle-sexton]

This comes from the 2026-09-29 audit of the Cursor run. Reopened: #4880 was a docs-only record, no follow-up exists (gh issue list --state open found none), and the diagnosis still needs the owner on the affected Windows host. No agent can do it. needs-human stays.

Exact steps (from the 2026-09-01 path-forward and 2026-09-06 triage comments)

1. On the reporting Windows host add the two-line probe from the issue's Reproduction section (a PreToolUse and a PostToolUse hook on Write, each appending a timestamp line). Run claude --debug, Write any file, keep the debug log. It decides whether PostToolUse dispatch is refused, started and killed, or never scheduled.
2. Run the same probe on any second Windows host.
3. Only if both point at the install, bisect in this order: a minimal --settings file with only the probe hooks, CLAUDE_CONFIG_DIR pointed at an empty directory, then a single enabled plugin and then none.
4. Record the Claude Code version, Windows build and outcome as a comment here. A passing Linux 2.1.258 result is already recorded.

Repo state

docs/formatter-path-probes.md carries the four-part record with this issue as the recheck carrier. No in-repo PostToolUse timeout change is planned while no hook completes on that host. Fix PR #5313 (draft) reduces the hook-observability README to a pointer.

Do not close until the debug capture is recorded.