AI CODING TOOLS

Claude Code Hooks Pack

10 ready-to-install Claude Code hooks that block secrets and destructive commands, auto-format, run the right tests, gate on typecheck, and log every tool call. Bash + jq, shellcheck-clean, with the real hook contract documented from captured payloads.

  • Instant download Secure link seconds after payment
  • Commercial license Unlimited paid client projects
  • 14-day refund If it doesn't work as described

What's inside

  • 10 hook scripts (bash + jq): 5 guardrails, 3 automation, 2 observability
  • 11 copy-paste settings.json snippets — one per hook, plus all-hooks.json wiring all ten together
  • The verified hook contract in the README: event payloads, exit-code semantics, and settings.json structure captured from a live Claude Code 2.1.232 session
  • Warn mode on every blocking hook, so you can introduce them gradually
4 more included — see the full list →

About this product

A prompt is a request. A hook is an enforcement point. You can tell Claude "never commit secrets" and "don't force-push to main" in your CLAUDE.md, and most of the time it will listen. Hooks are the part of Claude Code that runs your code at fixed points in the agent loop — a PreToolUse hook sees a tool call before it executes and can refuse it outright. That difference matters the one time in fifty it would have mattered a lot.

The Claude Code Hooks Pack is 10 hooks that are worth keeping installed: five guardrails that refuse bad tool calls, three that do a chore for you, and two that tell you what happened.

The guardrails (5)

  • block-secrets — refuses a write or edit that would put an AWS key, PEM private key, Anthropic/OpenAI/GitHub/Slack/Stripe/Google/Twilio/SendGrid token, or a hardcoded password on disk. Skips obvious placeholders so your .env.example still works, and reports only an 8-character fingerprint — it never echoes the credential it caught.
  • block-dangerous-shell — refuses rm -rf /, mkfs, dd of=/dev/…, fork bombs, chmod -R 777, curl … | sh, force-push to a protected branch, git reset --hard, DROP TABLE, and DELETE/UPDATE with no WHERE. --force-with-lease is deliberately allowed.
  • protect-paths — a configurable deny-list applied to edits and shell commands, so production config and state files are off-limits.
  • enforce-conventional-commits — rejects a git commit -m message that isn't type(scope): description.
  • guard-write-scope — catches the write that lands outside your project root, and the 400 KB file that's really an inlined dataset.

The automation (3)

  • format-on-write — formats the file just written, matched by extension: biome/prettier, ruff/black, gofmt, rustfmt, shfmt, rubocop, google-java-format, terraform fmt.
  • run-related-tests — finds the test file for the file just edited by convention, runs just that file, and feeds a failure straight back so Claude fixes it in the same turn instead of moving on.
  • typecheck-gate — won't let the turn end on code that doesn't compile. Auto-detects tsc, go build, cargo check, or mypy.

The observability (2)

  • session-log — one JSON line per tool call to a local dated audit file.
  • notify-on-finish — pings you when a turn ends, showing the first line of what Claude actually said.

The contract is documented, and it's verified

Most hook examples on the internet are wrong in the same way: they read environment variables like $CLAUDE_FILE_PATHS that do not exist. Hooks receive JSON on stdin. A hook built on that mistake fails silently and protects nothing.

So the README documents the real contract — event names, the exact stdin payload per event, what each exit code does, and the settings.json structure — captured by running Claude Code 2.1.232 with instrumented hooks and recording the actual payloads. Including the trap where tool_input uses file_path but the tool_response you get back uses filePath. You're buying working hooks and a correct mental model for writing your own.

Built to stay out of your way

  • Fails open. No jq, no formatter, no test runner? The hook exits 0 and gets out of the way. A guardrail that crashes your session is worse than no guardrail.
  • Every blocking hook has a warn mode, so you can introduce it to an existing codebase without it refusing anything on day one.
  • Configured by environment variable — loosen, retarget, or disable any hook without editing it.
  • shellcheck-clean at default severity, all 10 scripts, no findings.

Who it's for

Developers running Claude Code on real repositories — where a committed key means a rotation, and a bad migration means a restore. Also for anyone who wants to write their own hooks and would rather start from a correct, working reference than from a blog post that invented its variable names.

What's included

  • 10 hook scripts (bash + jq): 5 guardrails, 3 automation, 2 observability
  • 11 copy-paste settings.json snippets — one per hook, plus all-hooks.json wiring all ten together
  • The verified hook contract in the README: event payloads, exit-code semantics, and settings.json structure captured from a live Claude Code 2.1.232 session
  • Warn mode on every blocking hook, so you can introduce them gradually
  • Per-hook header comments: which event it binds to, what it needs, how to configure it
  • QUICKSTART with a one-hook install, a shell one-liner for testing any hook without burning a session, and a recommended rollout order
  • Commercial license — unlimited personal + client project use
  • Free updates as Claude Code's hook system evolves
FAQ

About Claude Code Hooks Pack

?

What exactly is a Claude Code hook?

A script Claude Code runs at a fixed point in its loop. A PreToolUse hook runs before a tool call and can refuse it. A PostToolUse hook runs after and can feed a problem back. A Stop hook runs when Claude thinks it's finished and can decide the turn isn't over. The hook receives a JSON payload on stdin describing what's about to happen, and its exit code decides what happens next. It's the difference between asking the model to follow a rule and enforcing it.

?

How is this different from putting rules in CLAUDE.md?

CLAUDE.md is instruction — it shapes what the model tends to do. A hook is enforcement — it runs regardless of what the model decided. If you tell Claude in CLAUDE.md not to commit secrets, it will usually comply. block-secrets.sh makes it structurally unable to. Use both: CLAUDE.md for conventions and taste, hooks for the handful of things that must never happen.

?

Which Claude Code version is this built against?

The contract was verified against Claude Code 2.1.232 by running live sessions with instrumented hooks and capturing the actual stdin payloads, exit-code behaviour, and matcher semantics — rather than transcribing documentation. The hooks use the long-stable core of the API (PreToolUse, PostToolUse, Stop; tool_name and tool_input; exit 0 and exit 2), so they are not tied to a narrow version window. If the contract changes, the pack is updated and you re-download.

?

Will these slow my sessions down?

The guardrails and observability hooks are pattern matches and a file append — the cost is not noticeable. Two hooks genuinely cost time because they run real commands: run-related-tests runs your test file after an edit, and typecheck-gate runs your typechecker before a turn can end. That's the point of them, but it is a real trade. Both have configurable timeouts, and the QUICKSTART recommends turning them on last, after the cheap hooks feel natural.

?

What happens if jq or a formatter isn't installed?

The hook exits 0 and does nothing. Every script in the pack degrades safely: a missing jq, formatter, test runner, typechecker, or notifier is treated as 'not my job today', never as a failure. A guardrail that breaks your session is worse than no guardrail. jq is the only thing you need for the guardrails to actually guard, so the QUICKSTART checks for it first.

?

Can I customise which paths and commands are blocked?

Yes, and you should. protect-paths reads a deny-list from .claude/protected-paths, one glob per line — point it at your production config. block-dangerous-shell takes your protected branch names. block-secrets takes an allowlist file of regexes for false positives. Every hook lists its environment variables in its own header comment, and every blocking hook has a warn mode that reports without refusing, so you can see what it would catch before you let it catch anything.

?

Do these work on macOS, Linux, and WSL?

Yes. Every hook is bash with jq and standard POSIX utilities. notify-on-finish detects its environment and uses notify-send on Linux, Notification Center on macOS, a toast on WSL, or the terminal bell as a fallback. format-on-write and run-related-tests use whichever tools you already have installed and skip the rest. Native Windows without WSL is not supported — the scripts assume a bash shell.

?

Are the guardrails a security boundary?

No, and the license says so plainly. They are a safety net that catches the common, expensive mistakes — a key pasted into a config file, a force-push to main, a DELETE with no WHERE. A determined bypass is always possible, and a pattern matcher will never catch every credential shape. Treat them as one control among several, not as your only defence around credentials or production systems.

?

Can I use these in client projects?

Yes. The commercial license covers unlimited use in your personal projects, internal company projects, and unlimited client work — and you can commit the hook scripts straight into the repos you build. The one thing you can't do is resell the pack itself or repackage it into a competing hooks pack, plugin, or course.

?

What if a hook misfires on my codebase?

Switch that hook to warn mode first so you're unblocked immediately, then narrow it — the header comment in each script explains its configuration. If it's a genuine pattern bug rather than a tuning issue, email hello@buycoded.com and we'll fix it and reissue. There's also a 14-day no-questions refund if the pack doesn't deliver.