_run_hook_guard in graphify/cli.py decides whether a Bash tool call is a search with:
is_bash_search = any(tok in cmd_str for tok in (
"grep", "ripgrep", "rg ", "find ", "fd ", "ack ", "ag "))That is a plain substring test over the entire command string, including quoted arguments and heredoc bodies. Observed on graphifyy 0.9.48:
| Command |
Result |
Correct? |
grep -rn foo . |
fires |
yes |
rg foo |
fires |
yes |
git commit -m x |
quiet |
yes |
git log -S foo |
quiet |
yes |
git commit -m "add flag support" |
fires |
no — "flag " contains "ag " |
gh pr create --body "you can find it here" |
fires |
no — prose contains "find " |
echo "see grep docs" |
fires |
no |
| heredoc whose body mentions grep |
fires |
no |
The "ag " and "fd " tokens are the worst offenders: any English word ending in ag or fd followed by a space matches. flag, tag, diag, bag all trip it.
The heredoc case is self-inflicting for anyone whose project documents its own use of graphify — writing a design doc that mentions grep fires the guard on the write.
Each false positive injects a context line into a tool call where graphify has nothing to contribute, and trains the agent to skim the line, weakening it where it is correct.
Suggested fix: decide on the command's executed tokens rather than the raw string — strip heredoc bodies and quoted spans, split on shell operators (|, ||, &&, ;, &, newline, (, do, then), skip leading VAR=value assignments, and check whether the first remaining word of any segment basenames to a search tool. Worth reconsidering whether find should fire at all: it locates files by path, which the AST index does not cover.
Reported from a downstream project that has worked around it with a wrapper script.
_run_hook_guardingraphify/cli.pydecides whether a Bash tool call is a search with:That is a plain substring test over the entire command string, including quoted arguments and heredoc bodies. Observed on graphifyy 0.9.48:
grep -rn foo .rg foogit commit -m xgit log -S foogit commit -m "add flag support""flag "contains"ag "gh pr create --body "you can find it here""find "echo "see grep docs"The
"ag "and"fd "tokens are the worst offenders: any English word ending inagorfdfollowed by a space matches.flag,tag,diag,bagall trip it.The heredoc case is self-inflicting for anyone whose project documents its own use of graphify — writing a design doc that mentions grep fires the guard on the write.
Each false positive injects a context line into a tool call where graphify has nothing to contribute, and trains the agent to skim the line, weakening it where it is correct.
Suggested fix: decide on the command's executed tokens rather than the raw string — strip heredoc bodies and quoted spans, split on shell operators (
|,||,&&,;,&, newline,(,do,then), skip leadingVAR=valueassignments, and check whether the first remaining word of any segment basenames to a search tool. Worth reconsidering whetherfindshould fire at all: it locates files by path, which the AST index does not cover.Reported from a downstream project that has worked around it with a wrapper script.