Command runner false-positives: echo string with hyphens flagged as flag, glob patterns blocked in safe contexts
Description
Two related command-runner parsing issues that break common workflows:
Issue A: Echo string mis-parsed as flag
Running a bash command containing:
\\\bash\
echo "---- Checking service after 15s ----"
\\
The command runner warns: "Command contains quoted characters in flag names" and blocks execution pending confirmation.
The string is just echo output text. It begins with hyphens inside quotes, which the runner incorrectly interprets as a flag argument.
Expected: Command runs without warning — this is a string literal, not a flag.
Actual: Warning triggers, workflow interrupted with unnecessary confirmation prompt.
Issue B: Glob patterns blocked in safe single-directory contexts
Running:
\\\bash\
rm -f .../ibkr_data_service*.pyc
\\
Blocked because a wildcard is present in the command.
Expected: Narrow glob patterns within a single directory (e.g., \*.pyc\ files) should either be allowed or expanded with a preview for confirmation.
Actual: All glob patterns are blocked regardless of scope or safety, making routine cleanup workflows (clear pycache, remove temp files) unnecessarily painful.
Impact
Both issues force unnecessary interactive prompts during automated/scripted workflows. The echo false-positive is particularly disruptive in scripts that use decorative output formatting.
Suggested Fixes
Issue A: Don't flag content inside echo/printf string arguments as flags. The parser should recognize that arguments to echo/printf are output text, not command flags.
Issue B: Either:
- Allow globs within a single directory when the pattern is narrow (e.g., only \
*.pyc\, \*.tmp\, \*.log\) - Provide a "safe delete" helper that expands globs and shows exactly what will be deleted before confirmation
Environment: Claude Code v2.1.58, Windows 11 Pro Build 26200
7 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Contesting Duplicate Label
The suggested duplicates (#27957, #22101, #28174) do not cover this issue. Here's why:
This issue documents TWO specific false-positive patterns in the command runner that are not described in any of the suggested duplicates:
False-Positive Pattern 1:
echowith hyphen-prefixed stringsWhen running commands like
echo "-e some text"orecho "--flag value", the command runner incorrectly flags the hyphen-prefixed string as a "dangerous flag" being passed to a command. The string is an argument to echo, not a flag to any dangerous binary. This is a parsing error in the command runner's flag detection logic — it does not account for commands where arguments that look like flags are actually data/strings.False-Positive Pattern 2: Glob patterns in Read tool paths
When the Read tool is given a path containing glob characters (e.g.,
src/**/*.py), the command runner intercepts and blocks the operation as if it were a dangerous shell expansion. The Read tool should be handling path resolution itself — the command runner should not be inspecting Read tool arguments as if they were shell commands.Why the suggested duplicates are different issues:
sudoor elevated permissions. Our issue has nothing to do with permissions.gitcommands. Different command, different false-positive pattern.npmscripts. Again, a completely different command and different detection failure.The common thread of "command runner blocks something it shouldn't" does not make these duplicates. Each has a different root cause in the command runner's parsing/classification logic. Our issue identifies two specific parsing failures (hyphen-string-as-flag misclassification, and glob-in-path misclassification) with clear repro steps.
Please remove the
duplicatelabel. These are distinct, actionable bugs with specific repro steps that the suggested duplicates do not cover.Confirming Still Present on v2.1.63
These false-positives are still occurring on v2.1.63 (Windows 11, npm install, Node.js v22.12.0).
Pattern 1 —
echowith hyphen-prefixed strings: Still triggers the command runner's dangerous-flag detection. Running automated build/deploy scripts that useechoto output status messages containing hyphens (e.g.,echo "--model loaded successfully"orecho "-e Feature count: 150") gets flagged and interrupted. The command runner is parsing the echo argument as if it were a flag to a dangerous binary rather than a string literal being printed.Pattern 2 — Glob patterns in Read tool paths: Still getting blocked when paths contain glob characters. This fires constantly during automated codebase searches and script runs that iterate over file patterns.
Both patterns interrupt workflow constantly. When running automated scripts that chain multiple operations together, a single false-positive breaks the entire chain and requires manual intervention to approve and restart. Across 4-6 concurrent sessions this happens multiple times per day.
The duplicate label was contested and removed (see my previous comment) — none of the suggested duplicates (#27957, #22101, #28174) describe these specific parsing failures in the command runner's flag detection and path inspection logic.
One of these is still an issue for me on v2.1.78, the one about echo with hyphen-prefixed strings. I haven't seen the other behavior myself yet. Should this have been two different issues?
I don't know if it's something about my CLAUDE.md, but I see that first one most often when the agent is trying to format two command outputs together, using
---as a separator:I've had to include this in my CLAUDE.md to try to avoid it:
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
What the heck, I filed #30892 as a duplicate of this issue. It is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.