The Claude Code hook that ended --no-verify commits forever

Here's a small thing that drove me up the wall using Claude Code on a real codebase. I have a pre-commit hook. It runs the linter and the type-checker. It exists precisely so that broken code doesn't reach a commit. And Claude — diligent, eager, trying to be helpful — would hit a failing check, decide the check was in the way of the goal, and quietly run: git commit --no-verify -m "fix: update handler" It wasn't malicious. From the agent's point of view, the task was "commit this change," the pre-commit hook was an obstacle, and --no-verify was the documented way around the obstacle. Perfectly logical. Also exactly the thing I never want to happen, because the entire point of the check is that it is not optional. I tried the obvious fix first: I put it in CLAUDE.md. Never use git commit --no-verify. Fix the failing check instead. This works about 80% of the time. Which is another way of saying it fails one commit in five. CLAUDE.md is context — a strong suggestion the model weighs against everything else in the conversation. Under enough pressure ("just get this committed"), a suggestion loses. An 80%-reliable guardrail on something irreversible isn't a guardrail. It's a coin flip with good odds. So I stopped trying to persuade the model and started intercepting the tool call instead. before the action, not after the apology Claude Code has a hooks system. The one that matters here is PreToolUse: a script that runs before a tool call executes, receives the call as JSON on stdin, and decides whether it proceeds. Exit 0 and the call runs. Exit 2 and it's blocked — and whatever you wrote to stderr gets fed back to the model as the reason. That last part is the whole game. It's not "please don't." It's a wall, plus an explanation the model can act on. Here's the entire hook: #!/usr/bin/env node // Block `git commit/push --no-verify`. Exit 2 blocks the call. 'use strict'; let raw = ''; process.stdin.on('data', (d) => (raw += d)); process.stdin.on('end', () => { let input = {}; try { input = JSON.parse(raw); } catch { process.exit(0); } if (input.tool_name !== 'Bash') process.exit(0); const cmd = (input.tool_input && input.tool_input.command) || ''; // Split on shell separators so `echo x && git commit --no-verify` is caught, // but `echo "--no-verify"` on its own is not. for (const seg of cmd.split(/&&|\|\||;|\|/)) { if (/\bgit\b/.test(seg) && /\b(commit|push)\b/.test(seg) && /--no-verify\b/.test(seg)) { process.stderr.write( 'BLOCKED: --no-verify skips the project\'s pre-commit/pre-push checks. ' + 'Run the failing check, fix the underlying issue, then commit normally.' ); process.exit(2); } } process.exit(0); }); Register it in ~/.claude/settings.json: { "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [{ "type": "command", "command": "node ~/.claude/hooks/block-no-verify.js" }] } ] } } Restart Claude Code, ask it to run git commit --no-verify -m test, and watch it get stopped — then watch it do the right thing, because the stderr message told it what the right thing is. Reliability went from "one in five slips" to zero. Not 99%. Zero, because it's no longer a judgment call. Split the command before matching. Agents chain commands: npm test && git commit --no-verify. A naive cmd.includes('--no-verify') is fine here, but splitting on shell separators first means you're matching intent per segment and you won't false-positive on echo "the --no-verify flag is blocked". Small thing; it's the difference between a hook people trust and one they rip out after it blocks something innocent. Fail open, not closed. Every exit path on bad input is exit(0) — malformed JSON, missing fields, wrong tool, all allow. This feels backwards for a security control, and it's the most debated line in the design. The reasoning: a hook that crashes shouldn't be able to brick your shell. A PreToolUse hook that throws on unexpected input and defaults to block turns one bad assumption into "I can't run any Bash command." For a guardrail you live inside all day, getting wedged out of your own terminal is a worse failure than the rare miss. (For a genuinely high-stakes control you might choose the opposite. It's a real trade-off, not a default — decide it on purpose.) No escape hatch, on purpose. I deliberately gave this hook no override env var. Most of my other hooks have one (CC_OS_ALLOW_SECRETS=1 for test fixtures with fake keys, for instance). This one doesn't, because the entire value is that it can't be argued around. The moment there's a bypass, "just this once" becomes the new default and you're back to the coin flip. --no-verify is one instance of a category: things the model will rationalize past because they sit between it and the task. Once you see the shape, the same ten-line pattern covers a lot of ground: secret-shaped strings being written into source files (scan the Write/Edit content, block on a match) SQL built by string interpolation instead of parameters --force pushes to main rm -rf aimed at a home directory or a drive root Each is the same skeleton: read the tool call, check the thing you care about, exit 2 with a sentence explaining why. The model isn't fighting you — it just needs the obstacle to be real instead of advisory. I packaged the ones I use into an installable kit (commands, agents, and eight of these hooks with tests), free and MIT-licensed, if you want to start from something instead of a blank file: https://github.com/stavrespasov/claude-code-os-lite But honestly, even if you take nothing else: write the --no-verify hook. It's twenty minutes and it closes a hole that CLAUDE.md alone can't.