block-dangerous-git.sh fails open: without jq it allows commands on its own denylist and exits 0

[timujinne]

.claude/hooks/block-dangerous-git.sh fails open: when its JSON parser is unavailable, a command on its own denylist passes through and the hook reports success.

The dependency

Line 4 parses the hook payload with jq:

COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command')

jq is not declared as a requirement anywhere in the repository. On a machine without it — ours was one — the substitution yields an empty string, no pattern matches, and the script reaches its final exit 0.

Measured, both directions

Revision 3d6c941d52. With jq removed from PATH, feeding it a command from its own denylist:

hooks/block-dangerous-git.sh: line 4: jq: command not found
exit status 0

Zero means allowed. With jq present, the same input behaves correctly:

dangerous input -> exit 2, "BLOCKED: ... matches dangerous pattern ..."
ordinary input  -> exit 0, silent

So the matching logic is sound; the failure mode is not. The only way this guard can fail is by silently permitting.

The fix worth making

A parser being unavailable is not evidence that a command is safe. If the payload cannot be parsed, the hook should exit 2 with a clear message rather than 0. That matters more than the jq dependency itself: with jq present, any other parse failure still yields the same silent permission.

Worth noting what this guard protects. Its denylist includes git reset --hard, which is exactly the class of command that destroys uncommitted work belonging to someone else. A guard for that should not have "allow everything" as its failure mode.

Lower priority, but a real cost

Matching is a substring test over the whole command with no notion of data versus execution, so writing about these commands is blocked too. We were unable to send an incident report through the normal path twice, because the report quoted one of the patterns inside a heredoc. It errs in the safe direction, but it means the guard cannot be documented by an agent working under it.

[timujinne]

Addendum on the substring matching, with a sharper example than the one above.

We noted that the guard blocks writing about the commands it blocks. The cost turned out larger than "cannot send a message".

A shift handover — the document that carries a working session's state to whoever comes next — could not be written. Its "state of the machine" section described an uncommitted local edit to this very hook, and quoting that edit meant quoting a pattern from the hook's own denylist. The file write was refused.

So the guard prevents documenting a change made to itself. The section was rewritten to describe the pattern in prose instead, which is a workaround, not a fix.

This does not change the priority — it still errs in the safe direction, and the failure mode in the issue title is the one worth fixing first. We are adding it because "you cannot document the guard while working under it" is a more concrete cost than the one we first described.

[timujinne]

Addendum: the hook fails open for any parse failure, not only a missing jq.

There is no set -e, set -u, or pipefail in the script — at 3d6c941d52, grep -c '^set ' returns 0. Line 4 is therefore the only thing between the payload and the denylist, and every way it can yield an empty COMMAND ends identically: no pattern matches, the loop completes, and the script reaches its final exit 0.

Two more, measured at 3d6c941d52:

payload without .tool_input.command  -> exit 0, no output
malformed JSON on stdin              -> jq prints "parse error: Invalid numeric
                                        literal", hook still exits 0

The second is the uncomfortable one: the failure is visible on stderr and the hook still reports "allowed".

Worth naming the shape, because it decides how long such a bug survives: the permission path runs on every ordinary command, while the refusal path only runs on input that ordinary work never produces. A hook that fails open therefore looks healthy indefinitely — its failure mode is silence, and the first evidence that it was broken is the destructive command it let through.

Failing closed covers the whole class in two lines:

COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command') || exit 2
[ -n "$COMMAND" ] || exit 2

---

Separately, while testing the above — the patterns are matched with unanchored grep -qE, so push --force also matches the safe alternative:

git push --force-with-lease  -> exit 2, "matches dangerous pattern 'push --force'"

--force-with-lease is what someone reaches for instead of --force, so the denylist currently pushes them back toward the more dangerous command. "push --force($|[^-])" keeps plain --force blocked while letting the lease form through — measured: --force exit 2, --force-with-lease exit 0. Happy to send that as a PR if you want it.