block-no-verify over-matches: blocks commits when the flag appears in the commit message body

[baselito]

Summary

The block-no-verify PreToolUse hook (wired via the plugin's hooks/hooks.json, currently npx block-no-verify@1.1.2) over-matches: it blocks git commit whenever the literal string --no-verify (or no-verify) appears anywhere in the command string, including inside the commit message body — not just when it is actually passed as a flag.

Impact

Legitimate commits are blocked when their message merely mentions the flag. Real-world examples that get blocked even though no --no-verify flag is passed:

• A commit documenting the hook itself, or a docs change that explains "don't use --no-verify".
• Any commit whose body references bypassing git hooks by name.

In a recent session this fired twice on legitimate commits whose message bodies referenced the flag, forcing the message to be reworded before the commit would go through. (Ironically, even a commit message containing the hook's own name, block-no-verify, is blocked because it contains the substring no-verify.)

Reproduction

# No --no-verify flag is passed, yet this is blocked:
git commit -m "docs: explain why we never pass --no-verify"

Result: BLOCKED: --no-verify flag is not allowed with git commit. Git hooks must not be bypassed.

Suggested fix

Tighten the matcher to detect --no-verify (and -n for commit, if covered) only in flag/argument position, not as a substring of the whole command — e.g.:

• Match the token only when it appears as a standalone argument (word-boundary / argv element), and
• Exclude content that is part of the commit message (after -m/-F, or inside a heredoc body).

This preserves the safety guarantee (you still can't actually bypass hooks) while removing the false positives on message bodies.

Environment

• block-no-verify@1.1.2 invoked as a Claude Code PreToolUse Bash hook via the ECC plugin's hooks/hooks.json.
• Observed on macOS, Claude Code, ECC plugin 1.9.0.

Thanks for ECC — the safety-guard hooks are great; this is just a matcher-scope refinement.

[chenhz01]

The fix in #2177 routes the Cursor surface through the in-repo scripts/hooks/block-no-verify.js, which does flag-position-aware tokenisation and pins the message-body false positives from this issue in regression tests. One residual gap: the published block-no-verify@1.1.2 npm package still ships the substring matcher — the fix routed around it rather than patching it. Any custom hooks.json that still invokes npx block-no-verify@1.1.2 directly, outside ECC's dispatcher, keeps blocking commits that merely mention the flag in the message body — including, as reported here, a commit whose message contains the hook's own name. Worth a deprecation notice on the package, or repointing remaining references at the in-repo hook:

// hooks.json: replace "npx block-no-verify@1.1.2"
// with "node scripts/hooks/block-no-verify.js"

I do freelance work on agent tooling — this would be a quick turnaround as a paid fix.

[chenhz01]

The fix in d8a84b5 (#2177) routes the Cursor surface through the in-repo scripts/hooks/block-no-verify.js, which does flag-position-aware tokenisation and pins the message-body false positives from this issue in regression tests. One residual gap: the published block-no-verify@1.1.2 npm package still ships the substring matcher — the fix routed around it rather than patching it. Any custom hooks.json that still invokes npx block-no-verify@1.1.2 directly, outside ECC's dispatcher, keeps blocking commits that merely mention the flag in the message body — including, as reported here, a commit whose message contains the hook's own name. Worth a deprecation notice on the package, or repointing remaining references at the in-repo hook:

// hooks.json: replace "npx block-no-verify@1.1.2"
// with "node scripts/hooks/block-no-verify.js"

If this is still biting your team, I'm available for a short paid engagement to close it out.