Claude Code Hooks & Permissions Generator
Build the guardrails layer for Claude Code — a settings.json with lifecycle hooks (PreToolUse, PostToolUse, Stop…) and allow/deny/ask permission rules. Auto-format after edits, block dangerous bash, protect secrets. Everything runs in your browser.
1 Guardrail Recipes Click to add
2 Hooks Shell at lifecycle events
settings.json.
3 Permission Rules allow / deny / ask
5 Scope Which settings file
Rules from every scope merge rather than override — and a deny rule from any scope always beats an allow from another.
Where to place your file
my-project/
├── .claude/
│ ├── settings.json ← project scope, committed
│ └── settings.local.json ← personal overrides, gitignored
└── ...All settings scopes (rules merge; deny always wins):
~/.claude/settings.jsonUser — every project on your machine
.claude/settings.jsonProject — committed, shared with the team
.claude/settings.local.jsonLocal — gitignored, machine-specific
managed policyOrganization-wide, highest authority
Frequently asked questions
Quick answers about Claude Code hooks, permission rules, and how they interact across settings scopes.
What are Claude Code hooks?
Shell commands that Claude Code runs automatically at lifecycle events — before a tool call (PreToolUse), after one succeeds (PostToolUse), when a turn ends (Stop), and more. Each hook receives event data as JSON on stdin and can allow, block, or add context. Unlike an instruction in your prompt, a hook never "forgets" between turns.
What's the difference between hooks and permissions?
Permissions are static allow/deny/ask rules matched against tool calls, like Bash(npm run *) or Read(./.env). Hooks are dynamic shell scripts that can inspect the full tool input and decide at runtime. Use permissions for anything expressible as a pattern; use a PreToolUse hook when the rule needs logic. They're complementary, not redundant.
How does a PreToolUse hook block a tool call?
Two ways. Exit with code 2 and write a reason to stderr — the call is blocked and the reason is fed back to Claude. Or exit 0 and print JSON with hookSpecificOutput.permissionDecision set to deny (or allow / ask) plus a permissionDecisionReason. Don't mix them: when a hook exits 2, any JSON on stdout is ignored.
Why does a deny rule beat an allow rule?
Permission rules merge across every settings scope (user, project, local, managed policy), and within the merged set a deny can never be cancelled by an allow. This is deliberate: a project's guardrails can't be loosened by personal settings, and vice versa.
Which settings.json file should I use?
~/.claude/settings.json applies to every project on your machine — good for personal guardrails like blocking rm -rf. .claude/settings.json lives in the repo and is committed, so the whole team inherits it. .claude/settings.local.json is gitignored, for machine-specific rules you don't want to share.
Are hooks safe to use?
Hooks execute shell with your user permissions and no confirmation prompt — a misconfigured or malicious hook can do real damage. Review any hook before committing it to a shared settings.json, and never execute unvalidated data from the JSON a hook receives. Treat the model's output as untrusted input.
Is anything I configure sent to a server?
No. The generator builds the settings.json entirely in your browser. Nothing you type leaves the page.