Permission matcher treats quoted dash strings as flags

Bug Description

The Bash permission matcher appears to scan the full command string for dash-prefixed tokens and treats them as unrecognized flags/options, even when they are quoted string arguments. This causes unexpected permission prompts for commands that should be auto-allowed.

Reproduction

Given these allow rules in ~/.claude/settings.json:

"Bash(echo *)",
"Bash(ls *)",
"Bash(head *)"

Commands that pass (no prompt):

echo "---"              # single command, no chain
echo "a-b" && echo "end"  # dash mid-string
echo "a" && echo "b" && echo "c"  # chain without dashes
ls /tmp | head -3 && echo "xxx" && echo "end"  # no dash-only strings

Commands that prompt unexpectedly:

echo "-" && echo "end"      # dash in quoted string
echo "--" && echo "end"     # double dash in quoted string
echo "---" && echo "end"    # triple dash in quoted string
ls /tmp | head -3 && echo "---" && echo "end"  # dash string in chain

Analysis

The pattern is consistent:

• A quoted string argument whose content starts with - (e.g., "-", "--", "---")
• In a chained command (&&, ||)
• Triggers a permission prompt even though the leading command matches an allow rule

The matcher seems to be tokenizing the full command string and flagging any token starting with - as a potential flag, without respecting shell quoting. Single commands with the same arguments pass fine — it only triggers in chains.

Expected Behavior

Quoted string arguments like "---" should not be interpreted as flags by the permission matcher. The shell quoting context should be respected when scanning for options/flags.

Environment

• Claude Code CLI
• macOS (Darwin 23.6.0)
• Permission rules defined in ~/.claude/settings.json