Bash permission pattern matching fails for registered commands (e.g. mkdir:*) on Windows/MINGW64

Bug Description

Bash(mkdir:*) is registered in .claude/settings.local.json but mkdir -p <path> commands still trigger approval prompts every time.

Steps to Reproduce

1. Register Bash(mkdir:*) in .claude/settings.local.json:

{
  "permissions": {
    "allow": [
      "Bash(mkdir:*)"
    ]
  }
}

1. Ask Claude Code to run a simple mkdir command:

mkdir -p C:/Users/KimHwan/IdeaProjects/herp_v2/test-permission-check

1. Result: Approval prompt still appears despite the pattern being registered.

1. Select option 2 ("Yes, and always allow access to ... from this project").

1. Result: settings.local.json is NOT modified — the system recognizes the existing Bash(mkdir:*) entry and skips adding a duplicate, yet the pattern still doesn't match at runtime.

Expected Behavior

Bash(mkdir:*) should match any command starting with mkdir, including mkdir -p ....

Actual Behavior

• Permission prompt appears for mkdir -p ... despite Bash(mkdir:*) being registered.
• Selecting "always allow" does not add a new entry (recognizes existing one), but matching continues to fail.

Screenshot

The approval prompt shown:

Bash command

  mkdir -p C:/Users/KimHwan/IdeaProjects/herp_v2/test-permission-check
  Test mkdir permission matching

Do you want to proceed?
> 1. Yes
  2. Yes, and always allow access to C:\Users\KimHwan\IdeaProjects\herp_v2\ from this project
  3. No

Environment

• OS: Windows (MINGW64_NT-10.0-26100 3.6.5)
• Claude Code model: claude-opus-4-6
• Date: 2026-02-10

Additional Context

This likely affects other similar patterns as well (e.g. Bash(ls:*), Bash(mv:*), Bash(cp:*)). The issue may be specific to Windows/MINGW64 environments.