claude-code-hooks ships 22 tested plugins that police what your agent is allowed to do
🪝 Claude Code hooks + an installable plugin marketplace: safety, cost, observability, productivity.
At a glance
- What is it?
- A Claude Code plugin marketplace of hooks for safety, observability and automation: block secret exfiltration and dangerous commands, log sessions, and audit instruction files. Hooks run outside the model, so prompts cannot argue with them.
- Who is it for?
- claude-code-hooks fits Claude Code users who want runtime guardrails their agent cannot prompt its way past: the safety set blocks secret reads and destructive commands, the audit hook catches poisoned instruction files, and the observability plugins turn sessions into usable records. Skip it if you run other agent platforms exclusively, since the event model is Claude Code specific, or if a sandbox is what you actually need.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Least privilege for an autonomous agent
Claude Code and its relatives run shell commands, edit files and install packages on their own initiative, and the permission prompt is the only gate most setups have. This repository's premise is that the gate should be enforced by code, not by the model's judgment: every tool call passes through a PreToolUse or PostToolUse hook that can allow it, deny it, or modify it, with the reason fed back to the agent as feedback it can act on.
The architectural point in the README is the one worth internalizing: hooks run outside the model as separate processes, so prompt injection cannot talk its way past them. The catalog began as a safety collection and grew into twenty-two plugins covering automation and notifications, each installable as a one-command Claude Code plugin and each mapped, per the README, against the OWASP LLM Top 10 2026.
The safety set: what gets blocked
The defensive plugins draw lines a team would otherwise negotiate by hope. block-dangerous-commands intercepts the classics before they run: rm -rf against the home directory, fork bombs, curl piped straight into sh, force pushes to main. The safety set also targets secret exfiltration, blocking reads of .env files and attempts to ship them out.
The most interesting entry is instructions-audit, which watches instruction files as they load and locks the session when it finds hidden directives: invisible Unicode smuggling including the zero-width and tag-character runs the README calls the TrapDoor supply-chain signature, bidirectional overrides, directives to read or exfiltrate secrets, curl-pipe-sh patterns, decode-and-execute chains, and tampering with hooks or settings. Detection names the rule and line so you can inspect the file; HOOK_AUDIT_LEVEL tunes criticality, and a warn-only mode exists for the cautious rollout every team will actually want.
Installing: marketplace or loose scripts
The plugin route is two commands inside Claude Code:
/plugin marketplace add karanb192/claude-code-hooks
/plugin install <name>@claude-code-hooksThat installs any of the twenty-two plugins with its script, tests and README. The second route is for people who do not want a marketplace: every plugin's script works standalone. You copy plugins/<name>/<name>.js and wire it into settings.json yourself, which makes the catalog double as a reference library of working hook implementations.
Either way the unit of adoption is small. One hook, one behavior, one line of configuration, and the README's structure, grouped by the lifecycle event that fires each hook, teaches the event model as a side effect of shopping.
Organized by lifecycle, not by feature
The grouping is the pedagogy. Session lifecycle hooks fire at boundaries: session-logger writes a durable markdown log of every session, with async PostToolUse registration so logging never blocks and best-effort secret redaction on bash commands. UserPromptSubmit hooks see your prompt before the model does: dead-end-registry remembers approaches you tried and reverted, with reason and token cost, and warns when you are about to retry one.
PreToolUse hooks decide before execution, which is where the blockers live. The InstructionsLoaded entry documents a real platform quirk with unusual candor: current Claude Code builds ignore even the universal continue false on that event, verified live by the author, so the plugin splits detection from enforcement, recording a per-session lock file and wiring UserPromptSubmit and PreToolUse arms that block everything until a human resolves the finding. That is unglamorous engineering around a platform limitation, documented where users will actually hit it.
Observability and cost: the flight recorder set
Beyond blocking, the marketplace instruments the agent's work. nerf-receipts is described as a personal flight recorder: it records your own failure rate, edit churn and tokens per task by model version, and flags real shifts when the model changes under you. standup-autopilot assembles the daily standup from what agents actually did across repositories, and re-injects yesterday's open blockers next session.
bounty-board gamifies maintenance debt: TODO, FIXME and HACK comments are priced as aging bounties, the top three surface as side quests, and cleared bounties are verified before payout. session-logger covers the durable record. None of these would justify the repository alone, but together they make the case that the hook event model is a small automation platform, and twenty-two tested examples are a better teacher than the reference docs.
Quality signals and the edges of the approach
The engineering claims are checkable: the README badge reports 1922 passing tests, CI runs on every push, and each plugin directory carries its own tests and documentation. The OWASP mapping document, the SECURITY.md and the instructions-audit design show threat modeling rather than checkbox security. MIT licensed, with the last push on 2026-09-15, the project is current.
The approach has structural limits worth naming. Hooks enforce on one machine's configuration, not a sandbox; a determined user can edit settings.json, and the audit plugin exists partly to catch tampering, but this is policy enforcement, not isolation. Coverage is matcher-based, so a command shape the patterns do not anticipate slips through. And the catalog is Claude Code shaped: the event names and plugin format belong to that platform, so the safety set does not automatically follow your agents elsewhere.
Against sandboxes, policies and hand-rolled hooks
The adjacent approaches each solve a different slice. Running the agent inside a container sandbox isolates blast radius but says nothing about which API calls should be allowed, and it slows the inner loop. Organization policy documents and system prompts ask the model to behave, which the prompt-injection threat model correctly assumes can fail. Hand-rolled hooks from the official docs work, but every team restarts from zero and rediscovers the same sharp edges this catalog already encodes and tests.
The reasonable posture is layering: sandbox for containment, hooks for policy, review for judgment. If you adopt one artifact from this repository, the safety set plus instructions-audit is the core; the observability plugins are the pleasant surprise; and the standalone scripts mean even marketplace-averse teams can lift the implementations they need into their own settings.json.
Editorial conclusion
claude-code-hooks fits Claude Code users who want runtime guardrails their agent cannot prompt its way past: the safety set blocks secret reads and destructive commands, the audit hook catches poisoned instruction files, and the observability plugins turn sessions into usable records. Skip it if you run other agent platforms exclusively, since the event model is Claude Code specific, or if a sandbox is what you actually need. Verify the core claim quickly: install the marketplace, add block-dangerous-commands, then ask the agent to run a command from the block list and watch the hook deny it with its reason attached.
Frequently asked questions
What are hooks used for in Claude Code?
In this catalog they enforce least privilege at runtime: every tool call passes through a PreToolUse or PostToolUse hook that allows, denies or modifies it. The plugins cover safety, automation and notifications, from blocking rm -rf to logging sessions.
What are hooks in the Claude Code lifecycle?
They are shell processes wired to named lifecycle events such as SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop and SessionEnd. Because they run outside the model, prompt injection cannot talk its way past them.
Do I have to use the plugin marketplace, or can I install hooks manually?
Both work. The marketplace is two commands: add karanb192/claude-code-hooks, then install a plugin by name. Alternatively copy any plugin's script from plugins/<name>/ and wire it into settings.json yourself.
Community notes