Skip to content

[BUG] Bash permission pattern fails to match commands with .exe extension on Windows #27537

@dmki

Description

@dmki

Preflight Checklist

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

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

  1. Add this to .claude/settings.local.json:
{
  "permissions": {
    "allow": [
      "Bash(mytool.exe *)",
      "Bash(dotnet *)"
    ]
  }
}
  1. Run dotnet --version via Bash tool - auto-approved (no prompt)
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingstaleIssue is inactive

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions