[BUG] Bash(ls:*) allow rule still prompts for ls commands in settings.local.json

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

I have Bash(ls:*) in my project's .claude/settings.local.json allow list, but Claude Code still prompts me to approve ls commands. I'm also in "Edit Automatically" permission mode, which I initially expected would help, but I understand that mode only affects file edits, not Bash commands.

What Should Happen?

The Bash(ls:*) allow rule should match any command starting with ls and auto-approve it without prompting.

Error Messages/Logs

Steps to Reproduce

Add "Bash(ls:*)" to .claude/settings.local.json → permissions.allow
Start a conversation where Claude runs a command like:

ls -la /c/Users/jonat/Documents\ \(Local\)/pinman/pinman2/envdata/source_fixtures/richtree/
Claude Code prompts for approval instead of auto-approving

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

v2.1.71

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

Looking at the docs, it appears the tool: syntax (with colon) may be deprecated in favor of tool (with space), e.g. Bash(ls *). However:

It's unclear whether the colon syntax still works at all or silently fails
There's no migration warning or documentation calling out the deprecation clearly
If the colon syntax is broken, many users with older configs will hit this silently
Additionally, the path in my command contains escaped parentheses (\(, \)) and escaped spaces — special characters in command arguments may also be interfering with the prefix matcher.

Environment:

Platform: Windows 11 (Git Bash)
Claude Code: latest (as of 2026-03-12)
My full allow list for reference:

"Bash(ls:*)",
"Bash(cat:*)",
"Bash(find:*)",
"Bash(grep:*)"
Suggestion:

If :* is deprecated, emit a warning or auto-migrate to the space syntax
Document the exact matching semantics for Bash allow rules more prominently
Clarify that "Edit Automatically" mode does not affect Bash command approval (this is a common point of confusion)