block-no-verify hook is pinned to 1.1.2, which blocks legitimate commits (fixed in 1.3.0)

[pangpond]

Summary

hooks/hooks.json pins the pre:bash:block-no-verify hook to npx block-no-verify@1.1.2. That version has false positives that were fixed upstream in 1.3.0, so anyone running the plugin today is getting refused on legitimate commits for no reason.

{
  "type": "command",
  "command": "npx block-no-verify@1.1.2"
}

What it looks like in practice

Any commit whose message happens to contain the flag text is refused:

$ git commit -m "the bash -n syntax check passes"
BLOCKED: --no-verify flag is not allowed with git commit. Git hooks must not be bypassed.

Nothing is being bypassed — -n is inside the quoted message. 1.1.2 tests /\s-n(?:\s|$)/ against the whole command string (dist/has-no-verify-flag.js), so quoted text counts.

This is not hypothetical: it cost two blocked commits in a session before the cause was obvious, and the natural workaround an agent reaches for is to reword the message — i.e. the hook silently edits people's commit messages rather than protecting anything.

Measurements

18 cases (10 legitimate commands that must be allowed, 8 real bypass attempts that must be blocked), fed to each version as PreToolUse payloads on stdin:

version	passed	false positives	real bypasses caught
1.1.2 (pinned here)	13/18	5	8/8
1.3.0 (latest)	18/18	0	8/8

The five 1.1.2 false positives:

git commit -m 'the bash -n syntax check passes'
git commit -m "run.sh nx-smoke.spec.js -n dry"
git commit -m 'fix: handle -n and --no-verify in docs'
git -C /repo commit -m 'note about -n flag'
echo 'git commit --no-verify'                     # merely mentions it

Detection strength is unchanged — 1.3.0 still catches all eight real ones (--no-verify, -n, -nm, git -C … --no-verify, cd … && git commit -n, and the push/merge long forms), and still correctly allows -n on git push (--dry-run) and git merge (--no-commit).

Upstream tracked these as tupe12334/block-no-verify#1, #5 and #9, all closed.

Suggested fix

Bump the pin:

"command": "npx block-no-verify@1.3.0"

One caveat worth knowing before you pin

1.3.0 still has a separate false positive, already filed upstream as tupe12334/block-no-verify#86 — a -n belonging to a chained command is attributed to the git commit:

echo -n hi && git commit -m x            # blocked, wrongly
grep -n TODO file.txt && git commit -m x # blocked, wrongly
head -n 5 file.txt; git commit -F msg    # blocked, wrongly

1.1.2 fails these too, so bumping is still a strict improvement (5 fewer false-positive classes, none added). The upstream fix for this one is reportedly merged on main but unreleased, so it may be worth tracking #86 and bumping again when it ships, rather than pinning to a version that will need revisiting.

Environment

• plugin ecc 1.10.0, hooks/hooks.json line 10
• macOS, node 20.20.2
• verified against block-no-verify 1.1.2 (from the npx cache) and 1.3.0 (installed fresh with its @polyhook/sdk dependency — note the packed tarball alone will not run, every case errors out and can look like "blocks everything")

[ArthitBIE]

Hi @pangpond, thanks for the detailed report and measurements.

This issue is already resolved on main. The npx block-no-verify@1.1.2 dependency was replaced with a local scripts/hooks/block-no-verify.js implementation that runs directly via Node, avoiding the false positives you documented. The hook is now wired through the consolidated Bash preflight dispatcher in hooks/hooks.json.

See the script header comment: "Replaces the previous npx-based invocation that failed in pnpm-only projects (EBADDEVENGINES) and could not be disabled via ECC_DISABLED_HOOKS."

No action needed. Feel free to close this issue.

--- — Jcode agent (automated triage), on behalf of @affaan-m