In Claude Code, hooks are actions you set up once that then run automatically at specific moments in a session. A hook can be a shell command, an HTTP call to a web address, or a short prompt sent to the model, and it fires at a set point in the work: before a tool runs, after a file is edited, when Claude finishes responding, and more. The key thing to know about Claude Code hooks is that the software runs them for you, on schedule, every time, so you don't have to remember to ask.

What Claude Code hooks actually are

Think of a hook as an "if this moment happens, then do that" rule. You pick the moment -- the technical term is an event -- and you pick the action. From then on, whenever that moment arrives, the action runs on its own. You never type anything to trigger it.

That "moment" can be a lot of things. A few of the common ones:

  • PreToolUse -- right before Claude uses a tool (like running a command or editing a file).
  • PostToolUse -- right after a tool finishes successfully.
  • UserPromptSubmit -- the instant you send a message, before Claude starts working on it.
  • SessionStart -- when a session begins or resumes.
  • Stop -- when Claude finishes responding.
  • Notification -- when Claude Code sends you a notification.

You view the hooks you've set up with the /hooks command, which opens a read-only list of every configured hook and where it came from.

/hooks

Open the read-only browser of your configured hooks. Click to copy.

Why hooks are reliable, not just helpful

Here's the part that matters most for anyone who cares about guardrails. Hooks are run by the Claude Code software itself, not decided by the AI in the moment. That means a hook fires every single time its event happens, regardless of what the model was planning to do. When you need something to be guaranteed rather than likely -- a check that always runs, a dangerous action that's always blocked -- a hook is the tool for it.

A hook is a rule the software enforces for you. It doesn't depend on the AI remembering, or deciding, to follow it.

The four things a hook does at that moment

When a hook fires, it can do one of a few useful jobs. These are the patterns you'll reach for most.

common hook jobs
!Block a risky actionA PreToolUse hook can deny a tool call before it runs -- for example, stopping a destructive command.Enforce
✓Clean up after a changeA PostToolUse hook can auto-format or lint code right after a file is edited.Automate
☉Send a heads-upA hook can ping you -- a desktop or Slack notice -- when Claude finishes or needs input.Notify
☰Keep a recordA hook can log what tools were used, giving you an audit trail of the work.Log

The everyday uses: enforce, automate, notify, log.

How to set one up (in plain terms)

You don't set up hooks by chatting. They live in a settings file called settings.json. You can put them at three levels, and the level decides who the hook applies to.

Level 1Just youYour user settings apply the hook across every project on your machine.
Level 2The whole teamProject settings live with the project, so a hook you commit is shared with everyone who works on it.
Level 3Local onlyLocal settings stay on your machine and aren't shared, good for personal tweaks.

Inside the file you name the event (say, PostToolUse), optionally narrow it down (say, only when a file is edited), and point it at the action to run. If you're not comfortable editing that file yourself, this is exactly the kind of setup the free Masterclass walks you through.

A real example

Say your team has one hard rule: no one -- human or AI -- should ever run a command that force-deletes files. You don't want to trust that everyone remembers. You want it blocked, always.

You add a PreToolUse hook that runs before any command executes. It reads the command about to run, and if it spots a destructive delete, it denies it and hands back a reason.

claude
› run: cleanup the temp folder # PreToolUse hook inspects the command... command detected: rm -rf /project/temp # hook returns a decision decision: deny — "Destructive command blocked by hook" ✓ command never ran; Claude gets the reason and adjusts

A PreToolUse hook stops a risky command before it can run.

The result Claude gets from a hook can be fed back to it as context, so instead of silently failing, Claude sees why the action was stopped and can choose a safer path. That feedback loop is what makes hooks feel like a smart guardrail rather than a blunt wall.

Good to know: the /hooks command only shows you what's configured -- it's a viewer. To add, change, or remove a hook, you edit the settings.json file directly.

When to use a hook (and when not to)

Reach for a hook when something needs to happen reliably and automatically at a known moment: a check that must always run, a rule that must always be enforced, a notification you never want to miss, a log you need for every session. Because the software runs it, you get consistency.

You don't need a hook for a one-time task, or for judgment calls that change case by case. For those, just ask Claude directly. Hooks earn their keep when the same thing should happen the same way, over and over.