Claude Code Hooks: settings.json Setup and Examples by Event

Are you still reminding Claude Code to "run the tests before committing" or "never touch that file," only to find it forgot again and undo the change yourself? Rules in an instruction file are something the model tries to follow, so they can slip once a conversation gets long.

Claude Code hooks are user-defined commands that Claude Code runs automatically at fixed points, such as right before or after a tool call or when a response ends. The key idea is that a hook makes the same action happen every time, instead of leaving it to the model's judgment. Based on the official docs as of October 2026, this guide covers how hooks differ from CLAUDE.md and skills, practical examples for each event, how to add a hook to settings.json, how to make failures block an action, and how to keep secrets out of logs. At the end, you will see how daglo transcripts of team meetings help you decide which rules deserve a hook.

What are Claude Code hooks, and how do they differ from CLAUDE.md and skills?

CLAUDE.md and skills are instructions that Claude reads and interprets. Hooks are commands that the Claude Code program itself executes. Put rules that must always hold in hooks, and guidance that needs judgment in instructions or skills.

For building skills, see our Claude Code skills guide. For designing instructions, tools, and permissions together, read the harness engineering guide.

Hook examples by event

You choose when a hook runs by naming an event. Four events cover most rules: PreToolUse (before a tool runs), PostToolUse (after it finishes), Stop (when Claude ends a response), and Notification (when Claude waits for you).

The official docs list more than 30 events, including subagent stops, context compaction, and worktree creation. New events arrive with new versions, so check the hooks reference before you rely on one.

How to add a hook in settings.json

Hooks live under the hooks key in settings.json, in three levels: event, matcher, and the command to run. The matcher filters which tools trigger the hook. For example, Edit|Write runs it only after file edits.

1. Pick a location: Use ~/.claude/settings.json for every project, .claude/settings.json in the project for hooks your team shares, and .claude/settings.local.json for personal ones. Hooks from all of these files are merged, not replaced.
2. Write the hook: To format every file Claude edits, add:
   {"hooks": {"PostToolUse": [{"matcher": "Edit|Write", "hooks": [{"type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"}]}]}}
3. Move logic into a script: When conditions grow, put a script in .claude/hooks/ and call it with a project-relative path such as "$CLAUDE_PROJECT_DIR"/.claude/hooks/protect-files.sh. The hook receives event data as JSON on stdin, so read fields like tool_name and tool_input.
4. Confirm it is registered: Type /hooks in Claude Code to see each event's hooks and the file that defines them.
5. Test it directly: Pipe sample input with echo '{"tool_name":"Bash","tool_input":{"command":"ls"}}' | ./my-hook.sh and check the exit code. Use claude --debug for detailed logs.

Matchers are case-sensitive. If a hook never fires, check the event and matcher names in /hooks first.

Blocking on failure and keeping secrets safe

When a hook script exits with code 2, Claude Code blocks the action and passes the stderr message to Claude as the reason. Exit code 0 means pass. Any other code shows a warning and lets the work continue.

• Where blocking works: Exit code 2 blocks on events such as PreToolUse, UserPromptSubmit, and Stop. PostToolUse runs after the tool, so it cannot undo the action. Instead, it tells Claude what went wrong so the next step changes.
• Fail closed when it matters: By default, a hook that errors or times out lets the action proceed. If a broken safety check must never let a risky command through, add "onFailure": "block" to the hook. This option is recent, so confirm your version supports it.
• Finer control: Instead of exit codes, print JSON with a permissionDecision of allow, deny, or ask.

Hooks run with your own account permissions, so treat secrets with care.

• Never write tokens or API keys directly into settings.json or a hook command. Project settings get committed to your repository. Keep values in environment variables or files outside the repo, and let scripts read them by path.
• Hook output lands in Claude's context and in debug logs. Do not echo token values or full request bodies in error messages.
• A hook that logs every command can capture passwords typed on the command line. Add the log file to .gitignore and mask sensitive patterns before writing.
• Read the commands in any hook or plugin someone else wrote before you enable it.

Finding hook candidates in daglo meeting transcripts

The best hooks come from rules your team keeps repeating. If you record retrospectives or ops meetings with daglo, you get a speaker-labeled transcript and summary, so you can point to the exact moments when the same mistake came up again.

1. Get everyone's consent, record the meeting, and upload it to daglo for transcription.
2. Collect several weeks of transcripts on one board, then ask Board Chat: "List the working rules and mistakes that came up in more than one meeting."
3. Check each answer against the original transcript. Turn rules that must run the same way every time (file protection, tests, alerts) into hooks, and keep judgment calls in CLAUDE.md or a skill.

If you want every meeting summarized as "repeated rules and mistakes," save that request in daglo My Templates. daglo remembers the prompt and applies that format automatically each time a recording ends.

In short: pick one rule that must never be skipped, turn it into a PreToolUse or PostToolUse hook, verify it with /hooks and sample input, and add more over time. You will spend far less time repeating yourself to Claude Code.

#ClaudeCode #ClaudeCodeHooks #Hooks #SettingsJson #PreToolUse #AIAgents #HarnessEngineering #daglo

👉 Transcribe your next meeting free