Use /hooks to Inspect and Debug Your Hook Configuration
When hooks aren't firing the way you expect, it's hard to tell whether the problem is the matcher regex, the wrong settings file, or a syntax error. The /hooks command gives you a read-only browser of every configured hook in your current session.
Type /hooks in Claude Code to open the hooks viewer. It shows:
- Every hook event with how many hooks are registered
- Matcher patterns for each event
- Full hook configuration (command, type, timeout, etc.)
- Source labels:
[User],[Project],[Local],[Plugin],[Session],[Built-in]
This makes it easy to see at a glance whether your hook is being picked up from the right settings file and whether the matcher is correct.
Common hook debugging steps:
- Run
/hooksto confirm the hook is registered — if it's not listed, Claude can't see it - Check the matcher against the actual tool name (case-sensitive, regex)
- Verify you're not hitting
disableAllHooks: truesomewhere in your settings - Check that your shell profile doesn't print text on startup (hook stdout must be valid JSON or empty)
If you need to temporarily disable all hooks for debugging, add this to your local settings:
{
"disableAllHooks": true
}
MCP tool matchers follow the pattern mcp__<server>__<toolname> — use a regex like mcp__memory__.* to match all tools from a server.
Before debugging a hook script, check /hooks first — the problem is usually a missing registration or wrong matcher.
Log in to leave a comment.
When a page takes five seconds to load or an API endpoint times out under load, tell Claude which route is slow and it traces the entire code path — controller, services, queries, loops — identifying N+1 queries, redundant computations, missing indexes, and cacheable operations, then fixes each bottleneck.
Flaky tests are maddening — they pass locally, fail in CI, pass again when you retry. Tell Claude to read the test, identify the source of non-determinism — timing issues, shared state, date dependencies, or order-dependent setup — and fix the root cause so the test is reliably green or reliably red.
When your app throws an error, don't just Google the message — paste the full stack trace into Claude Code. It reads the trace, opens the referenced files in your codebase, follows the call chain, and pinpoints the actual root cause instead of just explaining the symptom.