{"id":6123,"date":"2026-07-30T16:11:55","date_gmt":"2026-07-30T16:11:55","guid":{"rendered":"https:\/\/jonjones.ai\/uncategorized\/claude-code-hooks-operator-guide-2026\/"},"modified":"2026-07-30T16:11:55","modified_gmt":"2026-07-30T16:11:55","slug":"%e5%85%8b%e5%8b%9e%e5%be%b7%e4%bb%a3%e7%a2%bc%e9%89%a4%e5%ad%90%e6%93%8d%e4%bd%9c%e5%93%a1%e6%8c%87%e5%8d%97-2026","status":"publish","type":"post","link":"https:\/\/jonjones.ai\/zh\/%e4%ba%ba%e5%b7%a5%e6%99%ba%e6%85%a7\/%e5%85%8b%e5%8b%9e%e5%be%b7%e4%bb%a3%e7%a2%bc%e9%89%a4%e5%ad%90%e6%93%8d%e4%bd%9c%e5%93%a1%e6%8c%87%e5%8d%97-2026\/","title":{"rendered":"\u514b\u52de\u5fb7\u4ee3\u78bc\u9264\u5b50\uff1a\u904b\u71df\u5546\u5982\u4f55\u4e00\u591c\u4e4b\u9593\u5c07\u7de8\u78bc\u52a9\u624b\u8b8a\u6210\u503c\u5f97\u4fe1\u8cf4\u7684\u4ee3\u7406\u5546\uff082026\uff09"},"content":{"rendered":"

It’s 2am in Taipei. I’m asleep. Inside a Docker container on my VPS, a Claude Code agent wakes up on a cron schedule, writes a 2,600-word blog post, generates seven images, publishes it to WordPress, updates three Airtable tables, and files an Asana task — then goes back to sleep. Nobody watches it happen. That only works because of one feature most people treat as a coding convenience: Claude Code hooks<\/strong>. Hooks are the difference between hoping<\/em> an unattended agent behaves and enforcing<\/em> that it does.<\/p>\n\n

Search “claude code hooks” and every result teaches you the same thing: auto-format your files, tidy your commits, get a desktop ping when Claude needs input. All useful. All framed for a developer sitting at the keyboard. But if you run agents the way I do — headless, on a schedule, doing real business work while you sleep — hooks are something bigger. They’re the guardrail-and-audit layer that makes an autonomous business agent safe enough to leave alone. This guide reframes hooks for operators, not just coders.<\/p>\n\n

What Claude Code Hooks Actually Are<\/h2>\n\n
\"claude<\/figure>\n\n

Claude Code hooks are user-defined handlers — shell commands, HTTP endpoints, or short LLM prompts — that Claude Code runs automatically at specific points in its lifecycle. Think of them like git hooks, but for your AI agent instead of your repository. When an event fires, Claude Code hands your handler a JSON payload describing what’s happening (which tool, which file, which command), your handler inspects it, and it can take action or return a decision that Claude must obey.<\/p>\n\n

The critical word is automatic<\/strong>. A hook is not something the model chooses to invoke. It fires because the event happened, full stop. For a command hook, the event context arrives on stdin<\/code>; for an HTTP hook, it arrives as the POST body. Your handler exits with a status code — or returns a small JSON object — and Claude Code respects it. A PreToolUse<\/code> hook that returns a “block” decision stops the tool call before it ever runs. That’s not a suggestion the model weighs against its other instincts. It’s a gate.<\/p>\n\n

There are three flavours of handler, and it’s worth knowing which is which. A command hook<\/strong> runs a shell command or script — the workhorse, and where you’ll spend 90% of your time. An HTTP hook<\/strong> POSTs the event to an endpoint and reads the response, useful when the decision logic lives in a shared service. And a prompt hook<\/strong> hands the decision to a fast Claude model when the check needs judgment rather than a hard rule — “does this commit message actually describe the change?” is a prompt-hook question; “is this command rm -rf \/<\/code>?” is a command-hook question. Start with command hooks; graduate to the others only when a real need appears.<\/p>\n\n

This is worth sitting with, because it inverts how most people think about controlling an AI. You don’t control an agent by writing better instructions and hoping it listens. You control it by wrapping deterministic checks around the exact moments where it could do damage — and hooks are those checks. If you’re brand new to the tool, our Claude Code tutorial for beginners<\/a> covers the basics of getting a first session running before you start bolting guardrails onto it.<\/p>\n\n

Why Rules Aren’t Enough — and Claude Code Hooks Are<\/h2>\n\n
\"A<\/figure>\n\n

Here’s the uncomfortable truth every operator learns the first time an agent goes off-script: your CLAUDE.md<\/code> is a polite request. So is every “IMPORTANT: never do X” you type into a prompt. The model reads them, usually respects them, and then one night — new context, a weird edge case, a confidently wrong plan — it does the thing you explicitly told it not to. I’ve watched Claude reformat files I never touched, run commands I’d have vetoed, and declare a job “done” when it plainly wasn’t.<\/p>\n\n

The distinction that matters is probably versus always<\/strong>. If you tell Claude in your CLAUDE.md<\/code> not to write to .env<\/code>, it will probably comply. If you set a PreToolUse<\/code> hook that blocks writes to .env<\/code>, it always<\/em> blocks them — this session, next session, on a night when the model is having an off run. For anyone operating in production, or running an agent unattended on a schedule, that gap between “probably” and “always” is the entire ballgame.<\/p>\n\n

Rules live inside the model’s judgment. Hooks live outside it. When you’re sitting at the keyboard, the model’s judgment plus your eyes on the screen is usually enough. When you’re asleep and the agent is three tool calls into something you didn’t anticipate, only the hook is still awake. That’s why I treat hooks not as a nice-to-have but as the precondition for trusting an agent to run without me. The same logic is why I never launch a build without Claude Code planning mode<\/a> either — you scope with planning, and you enforce with hooks.<\/p>\n\n

The Lifecycle Events Worth Knowing First<\/h2>\n\n
\"The<\/figure>\n\n

Claude Code exposes a lot of lifecycle events, and the reference docs list every one. But you don’t need all of them to run a safe agent. You need a handful, understood in operator terms — what each one is for<\/em> when your goal is an autonomous system, not a tidy coding session.<\/p>\n\n

\n
Event<\/th>When it fires<\/th>What an operator uses it for<\/th><\/tr><\/thead>
SessionStart<\/strong><\/td>Once, when a session begins<\/td>Inject fresh context — pull the day’s config, load a secret, stamp a run ID into the log.<\/td><\/tr>\n
UserPromptSubmit<\/strong><\/td>Each time a prompt is submitted<\/td>Validate or annotate the incoming task before the agent touches it; reject malformed instructions.<\/td><\/tr>\n
PreToolUse<\/strong><\/td>Before every tool call in the loop<\/td>The guard rail. Inspect the command or file path and block<\/em> anything dangerous before it runs.<\/td><\/tr>\n
PostToolUse<\/strong><\/td>After every tool call completes<\/td>The audit trail. Append what just happened to a log you read over coffee the next morning.<\/td><\/tr>\n
Stop \/ StopFailure<\/strong><\/td>When the agent tries to finish<\/td>Verify the work is actually done; force the agent to keep going, or fire your completion alert.<\/td><\/tr>\n
SessionEnd<\/strong><\/td>Once, when the session closes<\/td>Clean up temp files, flush the log, send the end-of-run summary.<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n

Two cadences matter here. SessionStart<\/code> and SessionEnd<\/code> fire once per run. PreToolUse<\/code> and PostToolUse<\/code> fire on every single tool call<\/em> — which is exactly why they’re the right place to enforce discipline and capture an audit trail. If you learn only three events, learn PreToolUse<\/code> (block), PostToolUse<\/code> (log), and Stop<\/code> (verify and notify). Everything else is refinement.<\/p>\n\n

Here’s why the timing<\/em> is the whole point. A PreToolUse<\/code> hook fires before<\/em> the action, so it can prevent it — that’s the only moment you can stop rm -rf<\/code> from actually deleting anything. A PostToolUse<\/code> hook fires after<\/em>, so it can’t undo, but it can record what happened for later. Get those two backwards and your “guardrail” is really just a post-mortem. Matchers refine this further: attach the guard to the Bash<\/code> tool specifically, or to file-writing tools, so it only runs when there’s something worth checking and never adds friction to a harmless read.<\/p>\n\n