DEV Community: SDVSignal

You changed the file. Your buyers are still downloading the old one.

SDVSignal — Tue, 22 Sep 2026 05:16:33 +0000

This one cost me an evening, so here it is in case it saves you the same evening.

I sell a few small zip files. Templates, config packs, that kind of thing. They are paid downloads, so they cannot sit in a public bucket where anyone with the URL can grab them. The setup I landed on is a Cloudflare Pages Function that checks a key in the query string and streams the archive back:

/d/my-pack?k=<key>   ->  200 + application/zip
/d/my-pack           ->  403
/d/my-pack?k=wrong   ->  403

The file itself is not an asset in the repo. It is base64 in the function, generated by a build step. That part is deliberate. If the zip were a static file in the Pages project, Pages would serve it at its own path and the key check would be theatre, because anyone could skip the function and hit the file directly.

That design is fine. The trap is what it does to your update loop.

The trap

I changed a template inside one of the packs. Re-zipped. Committed. Moved on.

Buyers kept getting the old pack.

Nothing failed. No error, no warning, no red anywhere. The zip on my disk was correct. The zip in git was correct. Every check I had was looking at the zip on disk, and the zip on disk was right.

The bytes buyers actually receive live in the function, and the function is only as fresh as the last time I ran the build step and deployed. Re-zipping updates one of three copies:

the source folder
the built zip in out/
the base64 blob compiled into the function
and then, separately, whatever is actually deployed

I had been treating that as one step. It is four, and three of them can silently disagree.

The fix is not a better memory

My first instinct was a note in the runbook. "Remember to re-run the build step." That is not a fix, that is a wish. The runbook already said it. I had read it. I still shipped the stale pack, because reading a step and doing it are different events and only one of them leaves a trace.

What actually fixed it was making the smoke test compare the deployed bytes, not the built ones. The check downloads the live file over https, exactly the way a buyer does, and diffs it against the build output:

# what a buyer gets, right now, from production
curl -s -o /tmp/live.zip "https://your.site/d/my-pack?k=$KEY"

# what the build says they should get
BUILT=~/packs/out/my-pack.zip

# compare CONTENTS, not the archive bytes
cmp <(unzip -p /tmp/live.zip | shasum) <(unzip -p "$BUILT" | shasum) \
  && echo "deployed == built" \
  || echo "STALE: production is serving an older pack"

Note what that last bit is doing. Do not shasum the two .zip files against each other. Zip archives store a modification time per entry, so rebuilding the exact same content a second later gives you a different archive hash:

$ shasum a1.zip a2.zip          # same files inside, rebuilt 1s apart
3db6cd34...  a1.zip
dbf6dcd8...  a2.zip

$ unzip -p a1.zip | shasum      # the contents
f572d396...
$ unzip -p a2.zip | shasum
f572d396...

So the moment your build step runs for any reason, an archive-bytes check goes red while nothing is actually wrong. You will learn to ignore it, and then it is worse than having no check at all. Unpack and compare what came out.

Same reason unzip -l counts are a bad assertion: it lists directory entries too, so "7 files" in your build script and "8 lines" from unzip -l are both correct and will still make you doubt a green run at 1am.

While you are in there, check the other end

The download route was only half of it. The other half was the redirect.

Stripe Payment Links have an "after payment" setting. If you never set it, the default is a hosted confirmation page, which is a bare Stripe receipt with no link to anything. The buyer paid. Nothing arrives. Nothing is broken enough to alert you, and they are not going to email you about it, they are going to file a dispute or just eat it and never come back.

Worth reading the config back from the API rather than trusting your memory of a dashboard click:

curl -s https://api.stripe.com/v1/payment_links?limit=100 -u "$STRIPE_KEY:" \
| python3 -c "
import json,sys
for p in json.load(sys.stdin)['data']:
    ac = p.get('after_completion') or {}
    url = (ac.get('redirect') or {}).get('url','')
    print(p.get('active'), ac.get('type'), url)
"

Then take every URL that prints and actually curl it. A redirect Stripe is holding is worth exactly what that URL returns today. The key embedded in it can be stale, the route can have moved, and Stripe will keep cheerfully sending people there forever.

When I ran that across my own account I found 15 of 16 links fine and one leftover from a product I had retired months earlier, still active, still chargeable, still pointed at a dead end. Nothing links to it. An old bookmark would have been enough.

The thing I would tell past me

A green build is not proof that a feature works. I knew that. What I did not have was a check positioned on the buyer's side of the wire.

Every verification I owned was upstream of the deploy. Source correct, zip correct, commit correct, all green, all true, all useless, because none of them could see what production was serving. The check has to start from the public URL and work backwards, or it is checking your intentions rather than your product.

Two questions worth asking about any paid download you run:

If I change the file and forget a step, does anything tell me, or do buyers just quietly get the old one?
If I never set the after-payment behaviour on that checkout link, where does the buyer land?

If the honest answer to either is "I would find out when someone complains", that is the thing to go fix tonight.

I write these up as I hit them while building Kit, a set of small Claude Code and MCP setup packs. The checks above are the ones running against my own delivery rail right now. Steal them, they are not complicated.

Two of our products cost the same, and pointed at each other's checkout

SDVSignal — Tue, 22 Sep 2026 04:29:20 +0000

We keep a public changelog, and the rule I set for it is that it has to include the things we broke. Otherwise it is marketing with a date column on it.

Here is the entry from last week I would rather not have written, and the boring thing that actually caught it.

The bug

We sell a handful of small packs. Two of them are priced the same, $149 each.

Every product on the site carries JSON-LD in the page head, and each one has an Offer block with a url that goes straight to a Stripe checkout. That is the path a lot of machine traffic takes now. Search engines read it, and so do the AI assistants that answer "where do I buy X" without anybody clicking a link.

Those two url values were swapped. Pack A's structured data pointed at Pack B's checkout, and the other way around.

Why nothing looked wrong

This is the part worth sitting with. Both packs cost $149.

So the checkout opened, and it said $149, which is the number the buyer expected. The Stripe page was real. The payment would have gone through. Nothing in the flow contradicted anything the buyer had read. They would have paid the correct price and been handed the wrong product, and the first person to find out would have been them, after paying.

If the two packs had been priced differently the mismatch would have been obvious in about four seconds. Matching prices is what made it invisible.

I have no evidence anyone hit it. I also have no evidence nobody did, which is a worse sentence to write than the first one.

What found it

Not a test. Not a customer email. A script that does one dumb thing.

It fetches the live page, parses every JSON-LD block, collects every Offer.url, and asserts that the count of offers equals the count of distinct URLs. That is the whole check.

offers: 12   distinct urls: 12

When those two numbers disagree, two products are pointing at the same checkout, or at each other's. It cannot tell you which, and it does not need to. It tells you to go look.

It runs against production, not a fixture, because the thing I care about is what the page is actually serving right now. A fixture would have passed happily the entire time the live site was wrong.

The general shape

The checks that have earned their keep here all have the same feel. They are not "does this function return the right value." They are closer to "do two things that must agree still agree."

A few that now run before every deploy:

Every Offer.url is distinct.
Every page's dateModified equals its lastmod in the sitemap. Two freshness signals that drift apart are worse than one.
Every internal link on a page returns 200. Cheap, and it catches renames.
Every secret the build needs was actually bound at the last deploy, read back from the platform rather than from the config file that claims to set it.

None of these are clever. Every one of them has caught something real, and each one exists because it caught something the first time I ran it.

The crossed checkout is the one I think about, though, because it is the only one where a paying customer was the next line of defense. The other bugs on that list were embarrassing. That one was going to cost somebody money and take their afternoon.

The uncomfortable part

I found this while writing a changelog entry about something else.

The honest version of ship-in-public is that the changelog itself is a check. Writing down what shipped forces you to go look at whether it shipped the way you think it did, and about one time in five, it did not.

Full entry and the rest of the log: https://kit.sdvsignal.com/changelog/

Your Cloudflare Pages secret is set. Production cannot see it.

SDVSignal — Tue, 22 Sep 2026 03:38:25 +0000

Your Cloudflare Pages secret is set. wrangler pages secret list shows it. Production cannot see it.

I lost most of a day to this on a paid download route, so here is the mechanism, the one-line reason, and a check you can run that answers it exactly instead of guessing.

The symptom

Two delivery routes on a Pages project started returning 403 to everyone. The routes read a secret, the secret was missing, so they failed closed, which is correct behaviour and also completely invisible from outside.

Every obvious thing looked right:

$ npx wrangler pages secret list --project-name my-project
The "production" environment of your Pages project "my-project" has access to the following secrets:
  - DELIVERY_KEYS_VAULT49: Value Encrypted
  - DELIVERY_KEYS_PERMIT39: Value Encrypted

There they are. The code reads env.DELIVERY_KEYS_VAULT49. The names match. The route 403s.

The reason, from Cloudflare's own docs

"When setting secrets with Wrangler or in the Cloudflare dashboard, it needs to be done before a deployment that uses those secrets."

That one sentence is the whole bug. Pages binds environment variables and secrets at deploy time, into that deployment. They are not looked up per-request from some live project-level store. So wrangler pages secret put does not change what the currently-serving build can see. It changes what the next build will see.

Set a secret and walk away, and it sits in the project doing nothing at all until something deploys. The secret list is telling you the truth about the project. It is telling you nothing about production.

This is different from Workers, which is where the intuition comes from. On a Worker, wrangler secret put applies to the running script. The same muscle memory on Pages gets you a secret that exists, reads correctly in every tool you check, and is invisible to the thing serving traffic.

Why it is so hard to see

Every signal points the wrong way.

The secret list shows it. Correct, and irrelevant.
The dashboard shows it. Same.
The code is right, so a code review finds nothing.
The route fails closed, so you get a 403 and not a stack trace. A good failure mode hides this one.
Redeploying for an unrelated reason fixes it silently, so it looks intermittent, which sends you hunting for a caching problem that does not exist.

Ours only surfaced because someone asked why a paid link had never worked.

The fix

npx wrangler pages deploy . --project-name my-project

That is it. Deploy anything, even a no-op, and the secret binds. Order matters: secret put first, then deploy. Both orders "work" in the sense that neither errors, and only one of them serves.

The part worth keeping: how to detect it

"Redeploy after setting a secret" is a rule you will follow for two weeks and then forget at 11pm. I wanted a check instead, and my first instinct was to compare timestamps: when was this secret last changed, versus when did we last deploy?

Cloudflare does not give you that. There is no modification time on a secret. Not in wrangler pages secret list, not on the project's deployment_configs (every entry is literally {"type": "secret_text", "value": ""}), nowhere I could find.

But you do not need a timestamp, because every deployment record carries its own env_vars snapshot — the exact set of names that were bound when that build ran:

curl -s -H "Authorization: Bearer $CF_TOKEN" \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT/pages/projects/$PROJECT/deployments?per_page=25" \
  | jq '.result[] | {id: .short_id, on: .created_on, vars: (.env_vars // {} | keys)}'

Which makes the question a set difference, with no clock involved:

set-but-not-bound  =  (project's current secrets)  −  (last successful deploy's secrets)

That is strictly better than the timestamp comparison I originally wanted. An mtime would tell me when a secret changed. This tells me whether production can actually see it, which is the thing that 403s a user.

Walking my own history, the snapshots grow 3 → 4 → 5 → 6 → 8, and each step is a secret becoming visible. The two that broke the routes first appear in a specific deploy — which is exactly when those routes started working. The outage window is sitting there in the data, if you know to look.

Two traps if you build this into a gate

Skipped and failed builds carry an empty env_vars. Pick your baseline by recency alone and you will land on one of those, and then every secret in the account reports as stale. A gate that goes red on a perfectly healthy project gets deleted within a week. Filter to: production environment, not skipped, status success, and a non-empty snapshot.

Run it after the deploy, not before. As a pre-deploy check this is red for every legitimate secret put → deploy, which is the correct workflow and the one you are trying to protect. Run it after, and a red means the binding genuinely did not happen. I got this backwards first and the check immediately failed on the exact thing it was written to support.

I write this kind of thing up at kit.sdvsignal.com, and there is a free MIT starter repo at kit-claude-code-starter if you want a working .claude/ to copy rather than assemble. The hooks guide is the same flavour of "this looks like it works and does not".

Has anyone found a way to get a real modification time out of a Pages secret? I could not, and the snapshot trick is a workaround for something I would rather just ask the API directly.

The 15-minute Claude Code setup, and the four things people get wrong

SDVSignal — Tue, 22 Sep 2026 03:32:28 +0000

Claude Code works the moment you install it. Then it spends your first week asking permission for npm test and forgetting how your repo builds.

Fixing both takes about fifteen minutes and four plain-text files. I have done this on nine repos now, so here is the version without the ceremony, plus four things I had wrong for longer than I would like.

The clock

Min	Step
0–2	`npm install -g @anthropic-ai/claude-code`, run `claude` once in your repo to sign in
2–5	Copy `CLAUDE.md`, `.claude/` and `.mcp.json.example` into your repo root
5–10	Fill in your four commands and your never-do list in `CLAUDE.md`
10–12	Edit `permissions.allow` to match your real test and lint commands
12–15	Run `claude`, then your ship-check skill. It should run tests and lint and report PASS/FAIL

Minutes 5 to 10 are the job. The rest is typing.

Minute 5 to 10: the only step that matters

Claude Code starts every session knowing nothing about your repo. CLAUDE.md is what it reads first, every time. Most people write an essay here. The essay is what makes it useless.

Four commands and a short list of things not to do beats three paragraphs of architecture:

# My Project

## Commands
- install: `pnpm install`
- dev: `pnpm dev`
- test: `pnpm test`
- lint: `pnpm lint --fix`

## Layout
- `src/` app code · `src/db/` migrations, hand-written · `e2e/` Playwright

## Never
- Never edit anything in `src/generated/`
- Never commit to `main`; branch first
- Migrations are forward-only. No editing an applied one

If you do one thing from this post, write the four commands. Everything downstream is about commands Claude already knows how to run.

Minute 10 to 12: why it stops asking

Approving a command approves that run. It is not remembered. That is why you can approve npm test forty times and get asked a forty-first.

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Read(./.env*)"
    ]
  }
}

The bit that catches everyone: Bash(npm test) matches that exact string, so npm test -- --watch still prompts. Bash(npm test:*) covers the arguments too.

And do not allow everything. The point of an allowlist is that you can stop reading the prompts, which is only safe while the prompts you would want to read still show up.

The four things I had wrong

1. You do not need to restart after editing settings

I restarted Claude Code after every settings change for weeks. You do not have to. It watches the files. If a change looks like it did not take, the configuration is usually wrong rather than stale.

2. A hook matcher is not a glob

I wrote Edit(*) and wondered why nothing fired. A plain matcher value is an exact, case-sensitive tool name, or a pipe-separated list of them. Only a value containing regex characters gets treated as a regex. So "Edit|Write" works and Edit(*) matches nothing at all.

The Bash(npm test:*) shape is permission syntax, which is a different mechanism with different rules. I had been mixing them.

3. Exit 1 does not block anything

A hook returns exit 2 to block a tool call. exit 0 is success and exit 1 is a non-blocking error. So the Unix reflex of returning 1 on failure gets you a hook that reports a problem and then lets the action through. Mine "worked" for a week in the sense that it never blocked anything.

4. A failing hook says nothing where you can see it

Hook stderr goes to the debug log, never to the transcript. So a hook that crashes on line one and a hook that was never wired up look identical from the chat. This is the single most confusing thing in the whole setup.

claude --debug hooks

That prints hook resolution, the source file for each hook, the process spawn, and the error. /hooks in-session lists what is actually loaded. If it is not in that list it is a config problem; if it is, it is a script problem. Two different afternoons.

What you can skip on day one

Four words get used as one thing, and three of them can wait:

A skill — yes, one. It is a SKILL.md and it is also the slash command. Start with a ship-check.
Hooks — later. Useful once you know what should be enforced rather than requested.
An MCP server — only if Claude needs to reach something outside your machine. Words cannot query your database.
A plugin — no. Plugins are about handing a setup to other people. Nothing to package on day one.

Copy a working one

All four files, filled in, MIT, nothing held back: kit-claude-code-starter.

git clone https://github.com/sdvsignal/kit-claude-code-starter
cp -r kit-claude-code-starter/{CLAUDE.md,.claude,.mcp.json.example} your-repo/
cd your-repo && claude

There is no paid tier of that repo. If you already know your build commands, this post plus that clone is the whole job.

Longer version of this with the tables and the fix pages it links to: the 15-minute Claude Code setup. We do also sell the fifteen minutes done for you, which is on that site, but the free repo is the honest recommendation for most people and I would rather say so than not.

Checked against Claude Code 2.1.278.

Your agent said the tests passed. Check whether they ran.

SDVSignal — Tue, 22 Sep 2026 03:23:03 +0000

There is a failure mode in agent-assisted coding that does not look like a failure. You ask for a fix, the agent works for a while, and the summary says the tests pass. They did not fail. They also did not run.

A failing test is information. A test that never ran, reported as a pass, is worse than having no tests at all, because now you believe something.

This is not about any one tool being bad. It is a reporting gap, and it shows up the same way in Claude Code, Cursor, Copilot Workspace or a shell script somebody wrote in 2014. Here is what causes it and the smallest thing you can do about it.

The three ways a test run turns into a lie

1. The command was never found.

The agent does not know how you run tests. It guesses npm test, your project uses pnpm vitest run, the guess errors out, and the error gets folded into the summary as "no test failures". Technically true. Completely useless.

2. A flag made nothing count as something.

npm test -- --passWithNoTests

That flag does exactly what it says. Zero tests collected, exit code 0, green checkmark. Jest and Vitest both have it, and it exists for good reasons in a monorepo, which is precisely why it turns up in commands where it does not belong.

3. Somebody appended a shrug.

pytest || true

Now the command cannot fail. Whatever pytest thinks, the shell reports success. You see this a lot in CI files that somebody was trying to unblock at 6pm on a Friday, and once it is there nobody removes it.

How to tell, in one question

When an agent tells you the tests pass, ask for three things. It takes one line and it is the difference between a verified change and a claimed one.

Ask for	Good answer	Bad answer
The command it ran	The exact string, matching your repo	A paraphrase, or nothing
The output	A count: "42 passed, 0 failed"	"Tests pass"
The exit code	`0`, and it says so	Not mentioned

If you get a count and an exit code, something ran. If you get the word "pass" and nothing else, treat it as unverified. That is not cynicism, it is the same standard you would apply to a pull request from a contractor you have not met.

Half the fix is writing the command down

If you use Claude Code, the file it reads at the start of every session is CLAUDE.md at the root of your repo. Put the real commands in it, verbatim, flags included. It is copied, not interpreted, so a paraphrase is worse than nothing.

## Commands
- Test: `pnpm vitest run --silent`
- Lint: `pnpm eslint .`

## Never
- Never add `--passWithNoTests` or `|| true` to a command that is supposed to prove a change works

Then let it actually run them without asking, in .claude/settings.json:

{
  "permissions": {
    "allow": ["Bash(pnpm vitest:*)", "Bash(pnpm eslint:*)"]
  }
}

Miss that second half and you have traded a "cannot find it" prompt for a "may I run it" prompt, every single time, forever. Most people quietly stop reading those prompts after a day, which is its own problem.

The other half is a hook, because writing it down is not enforcement

An instruction in a markdown file is a request. Some days it gets followed. If you want the masked test run to be impossible rather than discouraged, Claude Code will run a script before it executes a Bash command, and if that script exits with code 2, the command is blocked and the reason goes back to the agent so it can correct itself.

Here is the whole thing. Save it as .claude/hooks/no-skip-tests.sh:

#!/usr/bin/env bash
# Blocks the flags that make a test run report success whatever happens.
set -uo pipefail
payload="$(cat)"

if command -v jq >/dev/null 2>&1; then
  cmd="$(printf '%s' "$payload" | jq -r '.tool_input.command // empty')"
else
  cmd="$payload"   # no jq: match against the raw payload rather than failing open
fi
[ -z "$cmd" ] && exit 0

case "$cmd" in
  *--passWithNoTests*|*"|| true"*|*--exitcode-zero*)
    echo "BLOCKED: that flag makes the test run report success even when nothing ran." >&2
    echo "Run the suite for real, or say out loud that you are skipping it." >&2
    exit 2 ;;
esac
exit 0

Wire it up in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/no-skip-tests.sh\"" }
        ]
      }
    ]
  }
}

Two details that matter more than they look:

Exit 2, not exit 1. Exit 2 is the code that blocks the tool call and hands your message back to the agent. Other non-zero codes get treated as the hook itself being broken, which is not what you want.

Handle a missing jq. If your hook parses the payload with jq and jq is not installed, the naive version silently allows everything through. A security or safety hook that fails open is worse than no hook, because you think you are covered. The fallback above matches against the raw payload instead, which is cruder and still blocks the thing.

Test the hook, because an untested hook is a comfort blanket

You can check it without launching an agent at all. The hook reads JSON on stdin, so hand it some:

echo '{"tool_input":{"command":"npm test -- --passWithNoTests"}}' | bash .claude/hooks/no-skip-tests.sh; echo "exit $?"
# exit 2

echo '{"tool_input":{"command":"npm test"}}' | bash .claude/hooks/no-skip-tests.sh; echo "exit $?"
# exit 0

Run both. A hook that blocks everything passes the first check and fails you on a Tuesday, so the allow case matters as much as the block case. That is also the difference between a hook you keep and one you delete in a fortnight when it gets in the way.

What this actually buys you

Not much, individually. It stops one specific lie. The reason it is worth ten minutes is that it moves a rule out of your head and into the repo, where it applies to every session, every contributor and every agent that touches the project, without anybody remembering to be careful.

That is the whole pattern: write the commands down so they cannot be guessed, allowlist them so they actually run, and hook the two or three things you never want to happen so being tired is not enough to cause them.

If you want the starting point rather than building it from scratch, our setup is public and free: kit-claude-code-starter is a real CLAUDE.md, an allowlist and a doctor script, and kit-plugins is four small Claude Code plugins that each install on their own. Nothing is gated behind an email.

There is a longer write-up of this specific problem here: Claude Code cannot find my test command.

And if you would rather not do the reading, we set it up for one repo for $29 and hand it back as a pull request you review: kit.sdvsignal.com. Take the free starter first though. We would rather you had that than bought something you did not need.

Your Claude Code hook exits 1. It is not blocking anything.

SDVSignal — Tue, 22 Sep 2026 02:29:32 +0000

Your Claude Code hook exits 1 when it wants to stop something. It is not stopping anything.

That is the whole post, really, but the reason is worth five minutes because the failure is silent. A hook that exits 1 runs, prints its complaint, gets logged as an error — and the command it objected to executes anyway. You get the feeling of protection with none of it, which is strictly worse than having written no hook at all, because you have stopped watching for the thing yourself.

The contract

From Anthropic's hooks reference:

Exit	What actually happens
`0`	No decision reported. The call continues through the normal permission flow. Silence is not approval, but it is not refusal either.
`2`	Blocking error. On `PreToolUse`, the tool call does not run.
anything else	Does not block on its own. Reported as an error.

And the part people miss even after getting the exit code right: when you exit 2 without printing a JSON decision, your stderr text is the reason Claude is shown. So stderr is not a log. It is the message. Write it for the reader.

echo "BLOCKED: '--passWithNoTests' makes this run report success whatever happens." >&2
echo "Run the tests for real. If some genuinely cannot run here, say which and why." >&2
exit 2

Claude reads that and fixes its own command. Compare it to a bare exit 2 with nothing on stderr, which gets retried, because nothing told it what was wrong.

Do not let `jq` decide whether you are protected

Nearly every hook example starts like this:

cmd=$(jq -r '.tool_input.command')

On a machine without jq, that is an empty string. Your hook finds nothing to object to, exits 0, and the command runs. A security hook that fails open is the worst object in the repository.

payload="$(cat)"
JQ="${JQ_BIN:-jq}"   # override to test the fallback: JQ_BIN=/nonexistent
if command -v "$JQ" >/dev/null 2>&1; then
  cmd="$(printf '%s' "$payload" | "$JQ" -r '.tool_input.command // empty' 2>/dev/null)"
else
  cmd="$payload"     # coarser, still catches the pattern
fi
[ -z "$cmd" ] && exit 0

The JQ_BIN indirection exists so the no-jq path is testable. A fallback nobody has executed is a guess with good intentions.

A whole hook

This one refuses the flags that make a test run report success whatever happens — the failure mode where CI is green and nothing ran.

#!/usr/bin/env bash
# PreToolUse(Bash): refuse the flags that make a test run lie.
set -uo pipefail
payload="$(cat)"
JQ="${JQ_BIN:-jq}"
if command -v "$JQ" >/dev/null 2>&1; then
  cmd="$(printf '%s' "$payload" | "$JQ" -r '.tool_input.command // empty' 2>/dev/null)"
else
  cmd="$payload"
fi
[ -z "$cmd" ] && exit 0

# narrow first: this hook has no opinion about your git status
case "$cmd" in
  *test*|*pytest*|*vitest*|*jest*|*go\ test*) ;;
  *) exit 0 ;;
esac

bad="$(printf '%s' "$cmd" | grep -oEm1 -- '(--passWithNoTests|--no-verify|\|\| *true|; *true$)' || true)"
if [ -n "$bad" ]; then
  echo "BLOCKED: '$bad' makes this run report success whatever happens." >&2
  echo "Run the tests for real. If some genuinely cannot run here, say which and why." >&2
  exit 2
fi
exit 0

Three details matter more than the regex:

It narrows before it judges. Everything that is not a test command exits 0 immediately.
The message says what to do instead. That is the difference between a correction and a retry loop.
It names its own file in the output, so when it blocks something you actually wanted, you know which file to open while you are annoyed.

Wire it up in .claude/settings.json so it can be committed:

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash",
        "hooks": [
          { "type": "command",
            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/no-skip-tests.sh\"" }
        ] }
    ]
  }
}

$CLAUDE_PROJECT_DIR is not optional decoration. Without it the path resolves against the working directory, and the hook stops firing the moment Claude runs cd.

Test it in a minute, with no Claude Code involved

It reads stdin and sets an exit code. A pipe is the entire test rig.

# should block -> 2
echo '{"tool_name":"Bash","tool_input":{"command":"npm test -- --passWithNoTests"}}' \
  | bash .claude/hooks/no-skip-tests.sh; echo "exit=$?"

# should allow -> 0
echo '{"tool_name":"Bash","tool_input":{"command":"npm test"}}' \
  | bash .claude/hooks/no-skip-tests.sh; echo "exit=$?"

Write the allow cases first. A hook that returns 2 for everything passes a block-only test suite with a perfect score and gets deleted within the hour. Every block needs a near-miss beside it that must return 0: rm -rf node_modules next to rm -rf ~, .env.example next to .env. The near-misses are where the actual thinking is.

I write this stuff up at kit.sdvsignal.com — the longer version of this post is there, and there is a free MIT starter repo at kit-claude-code-starter with a working .claude/ to copy if you would rather read one than assemble one.

What is your hook blocking that a CLAUDE.md line could not? I am genuinely collecting these — the interesting ones are always the project-specific rules, not the generic rm -rf guards.