← Blog · 2026-10-15

Claude Code Hooks for Non-Developers: 5 Guardrails Before It Touches Client Files

Shortcut: our free hooks & settings.json generator builds all five guardrails below as one file. Tick boxes, copy, done. It runs in your browser.

If you're a consultant or freelancer using Claude Code, your project folder probably isn't code. It's proposals, signed contracts, invoices, meeting notes and a .env file with an API key you set up once and forgot about. Claude Code is careful by default and asks before it runs commands or edits files. But "it asks first" only helps if you read every prompt, and after the fiftieth "Yes" most people stop reading.

Guardrails fix that. You decide once, in a settings file, what Claude Code can never do, what it must always ask about, and what it can do without bothering you.

Two tools, in plain English

Claude Code gives you two ways to set guardrails. You'll usually want both.

• Permission rules are a list in your settings file: things to allow, things to ask about, things to deny. They're simple patterns like Read(./.env) or Bash(git push *). No scripting.
• Hooks are small commands Claude Code runs at set moments, for example right before it uses a tool (PreToolUse) or right after (PostToolUse). A hook can look at what Claude is about to do and block it. They handle the cases a simple pattern can't.

Both live in a settings.json file. Where you put it decides what it covers:

For guardrails that protect client data, the first one (your user settings) is usually right, because then they follow you into every client folder.

Guardrail 1: Never read secrets

Your .env file, private keys and credential files have no business in a chat context. A deny rule keeps Claude Code from reading them at all:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

The generator adds the same idea for secrets/ folders and common key files, and pairs it with a hook that blocks edits to those files too.

Guardrail 2: No mass deletes

rm -rf on the wrong folder is the one mistake you can't take back. Claude Code would normally ask first, but this is exactly the prompt you don't want to approve on autopilot. A PreToolUse hook on the Bash tool can check the command and refuse it outright.

The official docs show this pattern: the hook reads what Claude is about to run and, if it contains rm -rf, returns a "deny" decision with a reason. Claude sees the reason and picks a safer approach, like deleting one named file. Note that the docs' example script uses jq, a small free tool you'd need installed. The generator writes the same check for you.

Guardrail 3: Nothing leaves your computer without a yes

This is the one most consultants miss. If you've connected Claude Code to email, Slack or another service through an MCP server (the add-on system that lets Claude use outside apps), Claude can potentially send things as you. Drafting is great. Sending a half-finished note to a client is not.

MCP tools have names like mcp__<server>__<tool>, so a hook can match anything whose name contains send, post, reply, forward or publish and make it ask you first, or deny it outright. Draft tools still work normally. The generator has a checkbox for this with both options.

Guardrail 4: Ask before pushing or publishing

If you keep any of your work in Git (lots of consultants version their templates and proposals there), an ask rule on Bash(git push *) means nothing goes to a shared repository without you seeing it. While you're there, a hook that blocks force pushes and git reset --hard protects your history from a confident mistake.

Guardrail 5: A log you can check later

A PostToolUse hook can append every command Claude Code ran to a plain text file. You'll rarely open it. But when a client asks "what exactly touched my files?", you'll have an answer. Pair it with a Notification hook that pings you when Claude Code is waiting for approval, so you're not tempted to approve prompts unread just to keep it moving.

How to check it worked

1. Save the file, then type /hooks in Claude Code. It opens a read-only list of your hooks and where each one came from (user, project, local or plugin).
2. Ask Claude to read your .env file. It should refuse.
3. Ask it to rm -rf a test folder you created for this. It should be blocked with your reason.
4. If something misbehaves, set "disableAllHooks": true in your settings to switch every hook off while you fix it.

One thing to know: a hook that prints anything other than its JSON answer (for example a greeting from your shell profile) can stop Claude Code from reading its decision. If a hook seems to do nothing, that's the first thing to check.

Checklist

• Deny reads of .env, keys and secrets/
• Block rm -rf, force pushes and git reset --hard
• Ask (or deny) before any MCP send/post/reply tool
• Ask before git push
• Log commands; get notified when Claude is waiting
• Tested with /hooks and two deliberate "bad" requests

Want the guardrails pre-installed?

Build the file yourself with the free hooks & settings.json generator, or start from a kit that already ships with them:

• Free 3-skill sample: client follow-ups, meeting-to-tasks and invoice chase
• Solo Consultant Kit ($29): 8 draft-only skills, 12 CLAUDE.md practice templates and safety hooks that block sends and mass deletes

More free tools: CLAUDE.md generator and SKILL.md builder.

Disclosure: I make Solo Stack Kits. The sample is free; paid kits are optional.

Not affiliated with Anthropic. "Claude" is a trademark of Anthropic.