PreToolUse:Bash hooks not invoked in v2.1.176 (registered hooks silently inert)

Confirmed in v2.1.191

This bug is still present in Claude Code v2.1.191 (released 2026-06-25).

Evidence with example hook that worked until recently

• Version: claude --version → 2.1.191 (Claude Code)
• Hooks configured: PreToolUse with matcher Bash(aws *)
• Expected behavior: Block AWS CLI commands without AWS_PROFILE
• Actual behavior: All AWS commands execute without hook invocation

Diagnostic findings

1. Hook registration verified: jq '.hooks' ~/.claude/settings.json shows null (no user-level hooks), plugin hooks configured in ~/.claude/plugins/cache/$PATH/hooks/hooks.json
2. Plugin enabled: jq '.enabledPlugins' ~/.claude/settings.json confirms plugin is active
3. Hook never invoked: grep -o '"hookResult"' ~/.claude/history.jsonl | wc -l → 0 (zero hook invocations across entire session)
4. Binary works when called directly: Running exact hook binary/script manually with test input returns proper deny decisions - so I know the hook logic is still successful

Impact

The implications are severe for any user relying on PreToolUse hooks for command validation, credential protection, or trust boundary enforcement.

Confirmation

This is the same bug as v2.1.176 - PreToolUse:Bash hooks are registered but never invoked. The hook execution system appears completely broken for the main conversation loop (unclear if subagents are affected).

Reconfirmed in v2.1.204 — same symptom, new forensic method + downstream impact

Hitting this same silent-inert PreToolUse/PostToolUse behavior on v2.1.204 (macOS, Darwin 25.5.0), continuing the pattern from v2.1.176 → v2.1.191 reported above. Adding a new corroborating diagnostic and a concrete downstream-impact case.

New diagnostic: ~/.claude.json lastSessionMetrics confirms it without needing a custom probe script

For any project, ~/.claude.json → projects["<path>"].lastSessionMetrics records hook_duration_ms_count and pre_tool_hook_duration_ms_count for the last completed session. On affected sessions, pre_tool_hook_duration_ms_count is absent entirely (not zero — the key doesn't exist), while hook_duration_ms_count is 1 or a small number (just a Session* hook, if any). On healthy sessions in other projects on the same machine, both keys are present with matching non-zero counts. This gives a quick way to confirm the regression retroactively without needing to have instrumented a probe hook in advance.

Both plugin-declared AND settings.json-declared PreToolUse hooks affected together

In my repro, a plugin's hooks/hooks.json-declared PreToolUse/PostToolUse hook (writing one log line per tool call) and a completely unrelated PreToolUse hook declared directly in ~/.claude/settings.json (a terminal-title notifier, unrelated to the plugin) both went silent in the same session — 30+ real tool calls produced zero log entries from either, while manually invoking the exact same hook scripts with the same stdin/env worked instantly. This suggests the regression is in the shared hook-dispatch layer rather than plugin-specific hook loading (which would point away from #73952's plugin-re-materialization theory as the sole cause, at least for this case).

Timing / version correlation

On this machine the CLI auto-updated 2.1.202 → 2.1.203 → 2.1.204 within about a 26-hour window. A hook-dependent background process (a PostToolUse-driven local observer) logged real activity continuously right up to that window, then nothing at all afterward across every project on the machine — consistent with the hook-dispatch break landing somewhere in that update range, matching the "still broken in 2.1.191" comment above.

Downstream impact example

A PreToolUse/PostToolUse-driven background learner (logs tool-call observations locally, periodically distills them via a headless session) silently stopped receiving any input once this hit — no crash, no error, just zero throughput, discovered only by diffing log timestamps against known CLI update dates. Same failure class as the "safety layer silently disabled" impact already noted above — anything hook-dependent (guardrails, telemetry, notifiers, background learners) fails open/silent with no user-visible signal.

Happy to provide the lastSessionMetrics JSON or hook scripts if useful for the bisect.

I'm on Claude Windows Desktop version 1.20186.1

I can't get Memtrace pre-tool-use hooks (a rail to force memtrace results to be appended when grepping etc.), either.
And mind you, I also have a hook for notifications when Claude is awaiting response, those fire just fine. But if I add the same exact notification hook for pre-tool-use (so the sounds should be going off all the time while searching) - nothing. Silence. Not working.

For context this is the memtrace hook that DOES NOT work whatsoever:

    "PreToolUse": [
      {
        "matcher": "Grep|Glob|Bash",
        "hooks": [
          {
            "type": "command",
            "command": "C:\\Users\\Admin\\AppData\\Roaming\\npm\\node_modules\\memtrace\\node_modules\\@memtrace\\win32-x64\\bin\\memtrace.exe route --hook"
          }
        ]
      }
    ]