Problem
gh-write-guard denies --no-verify and, since the #1816 fix, a -c or --config-env override of core.hooksPath on a commit or push. Several other routes reach the same hook bypass and are allowed. Each was probed against _check_bypass_flags on the #1816 branch.
- A persistent setting.
git config core.hooksPath /dev/null && git commit -m x is allowed. Run from a linked worktree, the config write lands in the base clone's shared config, so every checkout loses its hooks, not just one commit. Rule 6 does not list config, and it does not fire in a linked worktree anyway.
- Environment-prefix config.
GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=core.hooksPath GIT_CONFIG_VALUE_0=/dev/null git commit -m x and GIT_CONFIG_PARAMETERS="'core.hookspath'='/dev/null'" git commit -m x are allowed. The guard already reads inline environment prefixes for GIT_WORK_TREE and GIT_DIR.
- Wrapped or aliased git. The bypass check reads only top-level git, so
bash -c 'git commit --no-verify -m x' and git -c alias.ci=commit -c core.hooksPath=/dev/null ci -m x are allowed. Rule 6 already walks nested invocations and resolves aliases via _all_git_invocations.
A related false positive: a heredoc body is tokenized as commands, so writing a file whose text quotes git commit --no-verify through a cat <<'EOF' heredoc is denied.
Done looks like
The bypass check reuses rule 6's invocation walk and alias resolution. It also treats a core.hooksPath write through git config, and the GIT_CONFIG_* environment forms, as the same bypass. Each has a self-test row that fails with the check disabled.
Problem
gh-write-guard denies
--no-verifyand, since the #1816 fix, a-cor--config-envoverride ofcore.hooksPathon a commit or push. Several other routes reach the same hook bypass and are allowed. Each was probed against_check_bypass_flagson the #1816 branch.git config core.hooksPath /dev/null && git commit -m xis allowed. Run from a linked worktree, theconfigwrite lands in the base clone's shared config, so every checkout loses its hooks, not just one commit. Rule 6 does not listconfig, and it does not fire in a linked worktree anyway.GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=core.hooksPath GIT_CONFIG_VALUE_0=/dev/null git commit -m xandGIT_CONFIG_PARAMETERS="'core.hookspath'='/dev/null'" git commit -m xare allowed. The guard already reads inline environment prefixes forGIT_WORK_TREEandGIT_DIR.bash -c 'git commit --no-verify -m x'andgit -c alias.ci=commit -c core.hooksPath=/dev/null ci -m xare allowed. Rule 6 already walks nested invocations and resolves aliases via_all_git_invocations.A related false positive: a heredoc body is tokenized as commands, so writing a file whose text quotes
git commit --no-verifythrough acat <<'EOF'heredoc is denied.Done looks like
The bypass check reuses rule 6's invocation walk and alias resolution. It also treats a
core.hooksPathwrite throughgit config, and theGIT_CONFIG_*environment forms, as the same bypass. Each has a self-test row that fails with the check disabled.