I ran gate.cat on my own AI assistant while it was launching gate.cat — it blocked it twice

[BGMLAI]

Kicking off this category with a founder-dogfooding note (not a user report — these don't count
toward anything; they're just honest first data).

While an AI coding assistant was preparing this launch on my machine, gate.cat's own Claude Code
hook vetoed its commands twice, unprompted:

$ curl https://pypi.org/... | python3 -
[gatecat-hook] VETO [ENCODED_EXEC]: action matches denied pattern (curl|wget ... | python3)

$ git reset --hard origin/master
[gatecat-hook] VETO [GIT_DESTRUCTIVE]: action matches denied pattern (git reset --hard)

Both were reasonable things the assistant wanted to do — and both are exactly the shape the gate is
built to stop: pipe-to-interpreter and a hard reset that throws away local work. The point isn't
that these were catastrophic; it's that the gate fired outside the assistant's control flow,
without anyone remembering to ask it to.

Two honest gaps I hit the same session (documenting them because misses matter more than catches):

• a multi-line git commit -m "..." slipped a false block on the message body;
• git commit -F file && git push on one line false-blocked as a force-push (-F matched -f).

Both are now known-gaps / fix candidates. If gate.cat blocks (or misses) something for you,
please open a veto story —
that's the whole feedback loop.

— founder