A hook is an action the tool runs for you at a specific point: before a command, after an edit, when a session starts. Use them to enforce a rule ("never let it touch the main branch"), keep things tidy ("format every file Claude edits"), or log activity. Set it once; it just happens. This is a Power-Track (terminal) feature — a hook runs a shell command and is configured in a settings file, so it's aimed at technical users and team setup, not the everyday Desktop chat.
A hook is a command the tool runs for you, automatically, at a specific moment in
the work. The moments are named: a PreToolUse hook fires before Claude runs a
command or edits a file; a PostToolUse hook fires after; others fire when a
session starts or ends. You pick the moment, you supply the command, and from then on
it just happens.
This is a Power-Track feature, and worth saying plainly: a hook runs a shell command and is wired up in a settings file, so it’s aimed at technical users and team configuration — not the everyday Claude Desktop chat. A non-technical professional almost never needs to set one up; if your team has a developer, this is the kind of guardrail they’d configure once for everyone.
That gives you three useful jobs. Enforce a rule — a PreToolUse hook can inspect
what’s about to happen and block it (“never let it touch the main branch”), so the
guardrail is mechanical, not a thing you have to remember. Tidy — run your
formatter on every file Claude edits, and the diff is always clean. Log — record
what happened, for an audit trail or just peace of mind.
One rule of thumb keeps hooks pleasant: keep the command fast. Hooks run inline,
in the flow of the work, so a slow hook slows down every action it’s attached to. See
what you’ve got configured with /hooks. Where a scheduled agent
runs on the clock, a hook runs on an event — the “always do this, right when X
happens” chore you’d otherwise forget.
Generator
Build a settings.json
Pick permission rules and hooks, then copy out a settings.json for your .claude/ folder.
Permissions
allow run without asking
ask always confirm first
deny never, full stop
Hooks
{
"permissions": {
"allow": [
"Bash(npm run test:*)"
],
"deny": [
"Read(./.env)",
"Bash(rm -rf:*)"
]
},
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "npx prettier --write ."
}
]
}
]
}
}
A starting point — copy it into your project and adapt.
why it helps Automate the 'always do this after' chores so you never forget them.
examples- Hooks are a Power-Track / team-setup tool — they run a shell command, so they're for technical users, not the everyday Desktop chat.
- Reach for a hook for the 'always do this' chores — formatting, linting, logging — that you'd forget.
- Use a
PreToolUsehook to block risky actions (like touchingmain) before they happen. - Keep hook commands fast; they run inline, so a slow hook slows every action it's attached to.
Questions people ask
- What's the difference between a hook and a scheduled agent?
- A hook runs on an *event* — before a command, after an edit, when a session starts. A scheduled agent runs on the *clock* — every morning, every Monday. Reach for a hook when something should happen the moment X occurs, automatically.
- Can a hook do what a skill does?
- No. A hook runs a shell command — it can't change how Claude thinks or writes. A skill shapes Claude's behaviour and knowledge. They're complementary, not interchangeable.
- Will a hook slow Claude down?
- It can if the command is slow, because hooks run inline in the flow of the work. Keep hook commands fast — a slow one slows every action it's attached to.
- How do I see what hooks I have configured?
- Run `/hooks` in a session to list the hooks currently set up and which moments they fire on.
- Do I need the terminal to use hooks?
- Effectively yes — a hook runs a shell command and is set up in a settings file, so it's a Power-Track, technical feature. A non-technical Desktop user rarely needs one; the everyday work happens in the chat with accept/reject and the "Ask permissions" mode.