Summary
The Claude Code / Codex agent bash-guard (.agent_harness/command_guard_core.py) treats certain command names as forbidden via a regex that matches the whole command string, not just the command token. As a result, English words like find, open, and grep appearing inside a quoted argument (e.g. an issue title or PR body) trigger a false positive.
Evidence
-
.agent_harness/command_guard_core.py:71-82 defines SEARCH_OR_DISCOVERY_RE:
SEARCH_OR_DISCOVERY_RE = re.compile(
r"""(?ix)
(^|[^\w./-])
(
grep|egrep|fgrep|zgrep|rgrep|
rg|ripgrep|ag|ack|ack-grep|
find|fd|fdfind|locate|mlocate|mdfind
)
(?=$|[^\w./-])
"""
)
-
It is applied in _FORBIDDEN_COMMAND_PATTERNS at :138 against the full command string. The same applies to _MACOS_AUTOMATION_COMMANDS and "open".
Reproduction
Running this command from an agent is blocked:
gh issue create --title "search: 'broaden --path' hint fires even when query has 0 hits" --body-file /tmp/issue.md
…because --path is fine but a body containing the literal phrase "cdidx find" trips the regex. Same for gh issue list --state open — "open" is the value, not the command.
Impact
- Agents writing legitimate
gh issue create / gh pr create commands have to euphemise common technical English words.
- The workaround (writing the body to a file first and passing
--body-file) is non-obvious and slows down audit workflows.
Proposed direction
Apply the regex check only to the command token position (first token of each shell-control segment after splitting), not the whole string. The existing token-level check in _tokenized_forbidden_command_reason already does the right thing for _SEARCH_OR_DISCOVERY_COMMANDS; the redundant whole-string regex pass is what produces the false positives.
A minimal fix: remove SEARCH_OR_DISCOVERY_RE (and the analogous \b(?:open|osascript|automator)\b whole-string check) from _FORBIDDEN_COMMAND_PATTERNS, relying on the token-level checks alone.
Repro env
Summary
The Claude Code / Codex agent bash-guard (
.agent_harness/command_guard_core.py) treats certain command names as forbidden via a regex that matches the whole command string, not just the command token. As a result, English words likefind,open, andgrepappearing inside a quoted argument (e.g. an issue title or PR body) trigger a false positive.Evidence
.agent_harness/command_guard_core.py:71-82definesSEARCH_OR_DISCOVERY_RE:It is applied in
_FORBIDDEN_COMMAND_PATTERNSat:138against the full command string. The same applies to_MACOS_AUTOMATION_COMMANDSand "open".Reproduction
Running this command from an agent is blocked:
…because
--pathis fine but a body containing the literal phrase "cdidx find" trips the regex. Same forgh issue list --state open— "open" is the value, not the command.Impact
gh issue create/gh pr createcommands have to euphemise common technical English words.--body-file) is non-obvious and slows down audit workflows.Proposed direction
Apply the regex check only to the command token position (first token of each shell-control segment after splitting), not the whole string. The existing token-level check in
_tokenized_forbidden_command_reasonalready does the right thing for_SEARCH_OR_DISCOVERY_COMMANDS; the redundant whole-string regex pass is what produces the false positives.A minimal fix: remove
SEARCH_OR_DISCOVERY_RE(and the analogous\b(?:open|osascript|automator)\bwhole-string check) from_FORBIDDEN_COMMAND_PATTERNS, relying on the token-level checks alone.Repro env
main@ 2ee912d (release v1.21.0)