[BUG] PowerShell(git commit *) allow rule never suppresses the confirmation prompt, while other git subcommands work

Preflight Checklist

• [x] Searched existing issues (closest: #79885, different repro shape — multi-root workspace + blanket Bash rule, not verb-specific)
• [x] Single bug report
• [x] Using the latest version

Note: This must be a regression, as I'm 99% sure it worked just a few weeks ago

What's wrong?

git commit -m "message" prompts for permission every time via the PowerShell tool, even with PowerShell(git commit *) already present in permissions.allow. Every other plain PowerShell git subcommand tested (status, log, diff, rev-parse) is silently auto-approved by the equivalent allow entry. commit is the only verb that never respects an allow rule, in any form tried.

Steps to reproduce

1. .claude/settings.json: { "permissions": { "allow": ["PowerShell(git commit *)", "PowerShell(git status)", "PowerShell(git log *)", "PowerShell(git diff *)"] } }
2. Run git status, git log, git diff via the PowerShell tool → all auto-approved, no prompt.
3. Run git commit -m "message" via the PowerShell tool → prompts every time.

Ruled out

• Not the quote/wildcard matcher bug (#75549 family) — retried with a single-quoted here-string (git commit -m @'...'@), no literal " anywhere in the command, still prompted.
• Not a .claude/settings.local.json override — checked, empty.
• Not subagent-specific — reproduces in a plain foreground session with the rule in that exact settings file.

Expected behavior

PowerShell(git commit *) should suppress the confirmation the same as any other verb-scoped allow rule. Per the permissions docs, git commit *-style rules are the documented canonical example of a rule that suppresses confirmation — there's no documented special-casing of commit as an always-confirm action.

Environment

• Claude Code 2.1.263
• Windows 11 Pro 10.0.26200
• VS Code extension, PowerShell integrated terminal

Related

• #30519 — general "permissions matching is fundamentally broken" tracking issue
• #79885 — different repro (multi-root workspace, blanket Bash rule), possibly same underlying matcher fragility