protect-env hook blocks git commit messages that discuss dotenv tokens

[munair]

Summary

The hardened protect-env.sh hook (commit a756cea) inspects tool_input.command for dotenv tokens with a path-segment boundary. This correctly catches cat .env and grep SECRET .env, but it also catches legitimate git commit -m "... about dotenv files ..." invocations where the commit message body discusses the very tokens the hook is designed to defend against.

Reproduction

Any git commit -m whose message body contains a space-prefixed .env token is denied by the hook. The failure mode is ironic and self-documenting: commit a756cea — the commit that hardened the hook — had to be landed via git commit -F /tmp/commit-msg-hook.txt because its own message body described the attack surface it was closing.

Workaround

Pass the message via git commit -F <file> instead of -m "...". The file contents are not scanned because they never appear in the Bash command field that the hook reads.

Possible fixes

Ordered surgical → invasive:

1. Parse the Bash command with a minimal shell-aware matcher that only scans arguments outside git commit -m "..." / -F ... contexts. Keeps the defense-in-depth posture while eliminating the false positive.
2. Whitelist git commit as a prefix that bypasses the token scan. Risky — someone could git commit -m "$(cat dotenvfile)" and exfiltrate through the commit message. Rejected.
3. Leave the hook as-is and document -F as the official workflow for commit messages that discuss secrets tooling. Add a one-line note in the hook header comment pointing at this issue.

Recommendation

Option 1 if the parser stays small (under ~20 lines of bash). Otherwise Option 3 with a header comment.

Scope notes

• The false positive is benign — the hook is fail-closed, so blocked commits are always recoverable via -F.
• No real credentials were ever at risk in the repro.
• The hook already handles three attack surfaces correctly (direct file access, Grep/Glob path field, bare env/printenv). This issue is purely about false-positive ergonomics, not a security gap.