Bash(echo *) permission pattern does not match commands containing env vars that expand to paths

Describe the bug

A Bash(echo *) entry in settings.json permissions.allow does not suppress the permission prompt when the command contains an environment variable that expands to a value with / characters.

Steps to reproduce

1. Add "Bash(echo *)" to permissions.allow in ~/.claude/settings.json
2. Have an environment variable set to a path, e.g. MY_REPO=/Users/username/dev/my-repo
3. Ask Claude to run echo $MY_REPO
4. Observe: permission prompt appears despite the pattern matching

Expected behavior

Bash(echo *) should match any echo command, including echo $SOME_VAR. The * wildcard should match the literal command string as written, not the shell-expanded result.

Actual behavior

A permission prompt is shown for Bash(echo $MY_REPO).

Hypothesis

The permission pattern appears to be evaluated against the shell-expanded command value rather than the literal command string. Because $MY_REPO expands to /Users/username/dev/my-repo, the effective check becomes whether echo /Users/username/dev/my-repo matches echo *. Standard glob * does not match /, so the match fails.

If correct, any Bash(<cmd> *) pattern will silently fail to match commands whose arguments expand to filesystem paths — a common case for environment variables in developer tooling.

Environment

• OS: macOS 15.x (Darwin 25.4.0)
• Claude Code CLI
• Model: claude-sonnet-4-6

Workaround

Add the literal variable reference as an explicit allow entry: "Bash(echo $MY_REPO)". This is fragile and defeats the purpose of wildcard patterns.