Preflight Checklist
What's Wrong?
Description
On Windows (Git Bash), Bash(mytool.exe *) permission rule in settings.local.json fails to auto-approve commands starting with mytool.exe, while Bash(dotnet *) successfully auto-approves dotnet commands from the same settings file.
Environment
- OS: Windows 10 Pro 10.0.19045
- Shell: Git Bash (
C:\Program Files\Git\bin\bash.exe)
- Claude Code version: 2.1.49 / 2.1.50
- Executable: A custom
.exe tool installed in a directory on the system PATH
Steps to Reproduce
- Add this to
.claude/settings.local.json:
{
"permissions": {
"allow": [
"Bash(mytool.exe *)",
"Bash(dotnet *)"
]
}
}
- Run
dotnet --version via Bash tool - auto-approved (no prompt)
- Run
mytool.exe /somecommand -arg:"value" via Bash tool - prompts for confirmation
Evidence from Debug Logs
Rules are loaded correctly
Replacing all allow rules for destination 'localSettings' with N rule(s):
["Bash(mytool.exe *)","Bash(dotnet *)","Bash(node *)"]
dotnet command auto-approved (no Permission suggestions entry between PreToolUse and PostToolUse)
[DEBUG] executePreToolHooks called for tool: Bash
[DEBUG] Getting matching hook commands for PostToolUse with query: Bash
(No Permission suggestions log between these two lines = auto-approved)
.exe command fails to match (Permission suggestions triggered, user prompted)
[DEBUG] executePreToolHooks called for tool: Bash
[DEBUG] Permission suggestions for Bash: []
[DEBUG] executePermissionRequestHooks called for tool: Bash
...
[DEBUG] Bash tool permission denied
Patterns Tested (all fail for .exe commands)
Bash(mytool.exe:*) - colon format
Bash(mytool.exe *) - space format
Bash(mytool *) - without .exe extension
Bash(/full/path/to/mytool.exe *) - full resolved path
Expected Behavior
Bash(mytool.exe *) should auto-approve any command starting with mytool.exe , just as Bash(dotnet *) auto-approves commands starting with dotnet .
Hypothesis
The permission matcher may be resolving .exe executables to their full filesystem path on Windows before pattern matching, causing prefix-based rules to fail. Alternatively, the .exe extension may trigger special handling in the command parser.
Workaround
None found. The only option is to manually approve each invocation.
What Should Happen?
mytool.exe should have been executed without prompt
Error Messages/Logs
Steps to Reproduce
see above
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
No response
Claude Code Version
2.1.49 / 2.1.50
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Bug report produced by Claude Code / Opus 4.6 after extensive, long, expensive research. It really tried to find a solution and considers it a bug.
Preflight Checklist
What's Wrong?
Description
On Windows (Git Bash),
Bash(mytool.exe *)permission rule insettings.local.jsonfails to auto-approve commands starting withmytool.exe, whileBash(dotnet *)successfully auto-approvesdotnetcommands from the same settings file.Environment
C:\Program Files\Git\bin\bash.exe).exetool installed in a directory on the system PATHSteps to Reproduce
.claude/settings.local.json:{ "permissions": { "allow": [ "Bash(mytool.exe *)", "Bash(dotnet *)" ] } }dotnet --versionvia Bash tool - auto-approved (no prompt)mytool.exe /somecommand -arg:"value"via Bash tool - prompts for confirmationEvidence from Debug Logs
Rules are loaded correctly
dotnetcommand auto-approved (no Permission suggestions entry between PreToolUse and PostToolUse)(No
Permission suggestionslog between these two lines = auto-approved).execommand fails to match (Permission suggestions triggered, user prompted)Patterns Tested (all fail for .exe commands)
Bash(mytool.exe:*)- colon formatBash(mytool.exe *)- space formatBash(mytool *)- without .exe extensionBash(/full/path/to/mytool.exe *)- full resolved pathExpected Behavior
Bash(mytool.exe *)should auto-approve any command starting withmytool.exe, just asBash(dotnet *)auto-approves commands starting withdotnet.Hypothesis
The permission matcher may be resolving
.exeexecutables to their full filesystem path on Windows before pattern matching, causing prefix-based rules to fail. Alternatively, the.exeextension may trigger special handling in the command parser.Workaround
None found. The only option is to manually approve each invocation.
What Should Happen?
mytool.exe should have been executed without prompt
Error Messages/Logs
Steps to Reproduce
see above
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
No response
Claude Code Version
2.1.49 / 2.1.50
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Bug report produced by Claude Code / Opus 4.6 after extensive, long, expensive research. It really tried to find a solution and considers it a bug.