Bash permission allow-list rules fail to match Windows drive-letter paths

Bug: Bash permission allow-list rules fail to match for Windows drive-letter paths

Summary

Permission rules in .claude/settings.json that reference an absolute Windows path with a drive letter (e.g. C:/Program Files/... or /c/Program Files/...) never match the command they're written for — regardless of whether the rule is a wildcard or an exact literal match, and regardless of quoting style. Plain commands with no path (echo *, grep *) match correctly every time, including when combined with pipes, redirects, and parentheses in arguments.

This forces a fresh "Allow this bash command?" prompt on every invocation of tools like Blender or Unity launched by absolute path, even when a rule for that exact command already exists in the allow list. Evidence of long-term impact: the affected user's global ~/.claude/settings.json has accumulated dozens of near-duplicate one-off exact-match rules for the same Blender executable (different scripts/args each time) — consistent with this having silently failed for a long time, with each approval only ever saving a new one-off rule rather than actually generalizing.

Environment

• OS: Windows 11 Pro 10.0.26200
• Shell: Git Bash (via Claude Code's Bash tool)
• Permission mode: project .claude/settings.json sets "defaultMode": "dontAsk"

Repro steps

Project .claude/settings.json contains (among others):

"Bash(C:/PROGRA~1/BLENDE~1/BLENDE~1.1/blender.exe *)",
"Bash(\"/c/Program Files/Blender Foundation/Blender 5.1/blender.exe\" *)",
"Bash(\"/c/Program Files/Blender Foundation/Blender 5.1/blender.exe\" --version)"

1. Run C:/PROGRA~1/BLENDE~1/BLENDE~1.1/blender.exe --version → prompts, despite matching the first (wildcard) rule as a plain prefix.
2. Run "/c/Program Files/Blender Foundation/Blender 5.1/blender.exe" --version → prompts, despite being a byte-for-byte match of the third (exact, non-wildcard) rule.
3. Compare against Bash(echo *) / Bash(grep *), both present in the same file: any invocation of echo or grep, including with pipes (|), 2>&1 redirects, and literal parentheses in quoted arguments, matches its rule correctly and never prompts.
4. Reconstructing the exact failing Blender command's argument shape (same quoting, -- separator, 2>&1, multi-flag grep -e) but substituting echo for blender.exe also passes cleanly with no prompt — ruling out pipe/redirect/quote/parentheses handling as the cause and isolating the failure specifically to path-based rules.

Expected behavior

A command that is a literal prefix match (wildcard rule) or literal exact match (non-wildcard rule) of an existing allow-list entry should execute without a permission prompt, regardless of whether the pattern contains a Windows drive-letter path.

Actual behavior

Path-based rules (short 8.3 path form, long quoted form, wildcard, and exact) all fail to match. Only rules with no absolute path in them appear to match reliably.

Secondary bug observed during investigation: defaultMode: "dontAsk" not honored

With "defaultMode": "dontAsk" set in .claude/settings.json, any command not explicitly present in the allow list still produces a permission prompt — behavior indistinguishable from "default" mode. Either "dontAsk" is not a recognized value and silently falls back, or it isn't wired into the Bash permission check path.

Tertiary bug observed during investigation: allow-list edits don't hot-reload mid-session

Adding a brand-new, deliberately simple rule (Bash(bash tools/run_blender.sh *) — no drive letter, no quotes) to .claude/settings.json via a file edit mid-session did not take effect; the very next invocation of that exact command still prompted. This suggests the permission allow-list is loaded once at session start rather than watched for live changes (unlike some other settings-driven features which are known to require a /hooks-style reload).

Impact

For any project-based tooling that shells out to an absolute-path binary on Windows (game-dev pipelines calling Blender, Unity, etc. by full path), the allow-list is effectively non-functional — every invocation prompts, and approvals don't generalize, leading to unbounded accumulation of near-duplicate rules in global settings over time.

Workaround in use

Wrapping the absolute-path binary in a thin shell script referenced by a bare relative path (no drive letter, no spaces) and allow-listing the wrapper invocation instead, e.g.:

# tools/run_blender.sh
#!/bin/bash
exec "C:/Program Files/Blender Foundation/Blender 5.1/blender.exe" "$@"

"Bash(bash tools/run_blender.sh *)"

Not yet confirmed effective — see tertiary bug above (requires a session restart to test, since the rule was added mid-session).

      "PowerShell(& \"e:\\Files\\GIT\\MillManager.NET\\.claude\\scripts\\parse-dialog-xml.ps1\"*)",
      "PowerShell(& \"e:\\\\Files\\\\GIT\\\\MillManager.NET\\\\.claude\\\\scripts\\\\*)",
      "PowerShell(& 'e:\\\\Files\\\\GIT\\\\MillManager.NET\\\\.claude\\\\scripts\\\\*)",
      "PowerShell(& \"e:\\Files\\GIT\\MillManager.NET\\.claude\\scripts\\parse-dialog-xml.ps1\" -XmlPath *)",

"Bash(cygpath *)"