DEV Community: Ashton Du Toit

My release pipeline was about to ship my private notes

Ashton Du Toit — Wed, 29 Jul 2026 10:32:41 +0000

sell a small digital product, and the delivery side of it is deliberately
boring. Push a git tag, a GitHub Action zips up the product folder, the zip
gets attached to a release, buyer downloads it. Wrote the whole thing in
about four minutes and never opened it again.

Then I went looking through the product folder for something unrelated and
noticed what was actually in there.

Two files, sitting next to the guide and the configs people pay for.
source-material.md, which is my raw notes — unedited, real paths off my
machine, half-finished thoughts, the ugly version of everything the
polished guide says properly. And SANITIZATION-CHECKLIST.md, which is the
checklist I use to make sure none of that ever leaks.

The zip step said, roughly, put this folder in a zip. Both files were in
that folder. So the checklist for preventing the leak was part of the leak.

Nobody had bought anything yet. That's the only reason I'm writing this up
instead of emailing someone an apology.

The step:

- name: Zip the product folder
  run: |
    SLUG=${GITHUB_REF_NAME%-v*}
    cd products/$SLUG && zip -r ../../$GITHUB_REF_NAME.zip .

There's no bug in it. It does what it says. What it says is "ship the whole
directory", and directories fill up.

Obvious patch:

zip -r ../../$GITHUB_REF_NAME.zip . \
  -x "*.git*" -x "*source-material.md" -x "*SANITIZATION-CHECKLIST.md"

I used *source-material.md rather than the bare filename so a copy in a
subfolder gets caught too. Small thing, but that's the sort of gap a
denylist has.

Except the exclude list is really just a list of the mistakes I've already
thought of. It does nothing about the next one. notes.md. A TODO.md. An
.env.example that stopped being an example three commits ago. A
screenshot with a browser tab visible in the corner. The build ships
whatever's present and what's present grows every time I touch the product.

Two better options depending on how organised you are. Either name what
ships and let everything else be invisible by default, so adding a new file
to the release takes one deliberate line — which feels like the right
amount of friction for something going to customers. Or keep working files
and shippable files in separate directories so the build only ever sees the
clean one and there's nothing to exclude.

I haven't restructured mine yet, honestly. What I did add is a check that
looks at the finished zip instead of trusting the step that made it:

- name: Refuse to ship internal files
  run: |
    if unzip -l $GITHUB_REF_NAME.zip | grep -Ei 'source-material|SANITIZATION'; then
      echo "Internal file found in the release zip. Refusing to publish." >&2
      exit 1
    fi

Four lines, and a failed build is a much cheaper way to find out than a
customer email.

If you want to know what your own release actually contains, don't read
the workflow, read the output:

unzip -l dist/whatever-you-ship.zip

Run it against the last release you cut rather than the next one. I went
in expecting a tidy list of product files and about a third of the way
down there was a file I'd written strictly for myself.

Packaging steps get written early, when the folder has three files in it
and the whole thing is obviously fine, and then they sit there unchanged
while the folder fills up with the debris of actually doing the work.
Nobody re-reads a build step that's never failed. The question isn't
whether your build is correct, it's what your build includes today. Those
had the same answer for me in April and a different one in July.

y Claude Code safety hook wasn't blocking anything

Ashton Du Toit — Wed, 29 Jul 2026 10:31:28 +0000

I set up a hook in Claude Code a while back so it couldn't run anything
destructive on my repo. Nine lines of bash, a list of patterns, exit 2 to
block. Tested it once, saw it block, felt good about myself, forgot about
it.

Found out two months later it had been letting everything through.

The hook itself:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | python3 -c \
  "import sys,json;print(json.load(sys.stdin) \
  .get('tool_input',{}).get('command',''))")

BLOCKLIST='rm -rf /|rm -rf ~|git push --force|chmod -R 777'

if echo "$CMD" | grep -qE "$BLOCKLIST"; then
  echo "Blocked: matches destructive pattern." >&2
  exit 2
fi
exit 0

Claude Code hands the hook the tool call as JSON on stdin, so that python
one-liner is just pulling the command string out so grep can look at it.
Exit 2 blocks, exit 0 lets it run. Reads fine.

I'm on Windows, and python3 on Windows isn't necessarily Python. There's
an app execution alias that ships with Windows 10/11 which exists to open
the Microsoft Store when someone types python3 and hasn't installed
anything. I did have real Python, from python.org, and it didn't matter,
because the alias sits in WindowsApps near the front of PATH and it
claims the name python3 specifically. Plain python went to my actual
install. python3 went to the stub.

So the stub gets my JSON, does nothing useful with it, CMD ends up as an
empty string, grep finds nothing in an empty string, script falls through
to exit 0, and Claude Code reads exit 0 as the hook saying go ahead.

Every dangerous command was being explicitly approved by the thing I wrote
to stop dangerous commands.

What got me is that it never looked broken. If it had crashed I'd have
caught it in a day. Instead it ran, exited clean, printed nothing, and a
hook that says "all clear" is indistinguishable from a hook that works
unless you go looking.

Fix was one word:

CMD=$(echo "$INPUT" | python -c \
  "import sys,json;print(json.load(sys.stdin) \
  .get('tool_input',{}).get('command',''))")

You can also just turn the aliases off in Settings → Apps → Advanced app
settings → App execution aliases. I didn't, because the script lives in a
repo and I don't want it depending on a checkbox somewhere in my Windows
settings.

The word swap fixes my machine but not the actual mistake, which is that
the script's default answer was yes. Empty variable, malformed JSON,
Python missing entirely, tool payload changing shape in some future
version — all of those roads lead to exit 0. It should refuse when it
doesn't understand the question:

CMD=$(echo "$INPUT" | python -c \
  "import sys,json;print(json.load(sys.stdin) \
  .get('tool_input',{}).get('command',''))") || {
  echo "Guard could not parse tool input — blocking." >&2
  exit 2
}

A guard that blocks too much annoys you by lunchtime and you fix it. A
guard that allows too much just sits there.

If you've got hooks, don't read them, run them. Reading mine is exactly
what I did and it looked correct:

echo '{"tool_input":{"command":"rm -rf /"}}' | bash .claude/hooks/guard.sh
echo "exit code: $?"

Should be exit 2 and a message on stderr. If you get 0, it's decoration.

Do that from a normal terminal, not through Claude Code, or your live hook
sees the rm -rf / sitting in the test payload and blocks the test itself.
Took me a second to work out what was happening there.

And the broader Windows version, for anything of yours that shells out:

which python3 && python3 -c "print('real python')"

Nothing, or a WindowsApps path with no output after it, means every
script you've got calling python3 has been quietly handing back empty
strings.