Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Windows: permission prompt generates backslash allow-rules that never match forward-slash Bash commands [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46783•Fetched 2026-04-12 13:33:08
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
mikeprince-acmikeprince-ac
Participants
mikeprince-acmikeprince-ac
Timeline (top)
labeled ×4

On Windows (Git Bash), when Claude Code prompts the user to approve a Bash command that contains a file path, the "always allow" option generates a rule using Windows backslash separators — even though the original command used forward slashes.

This means the saved rule can never match future commands (which also use forward slashes), so the user gets prompted again every time.

Root Cause

  • #30736 — allowedTools glob patterns never match Windows backslash paths (same root cause: path separator mismatch in permission matching)
  • #30524 — unnecessary cd prepended due to path format mismatch
  • #21878 — hook scripts fail due to backslash path interpretation

Code Example

sed -n '/pattern/p' docs/trackers/backlog.yaml

---

Do you want to proceed?
   1. Yes
   2. Yes, and always allow access to trackers\ from this project
   3. No
RAW_BUFFERClick to expand / collapse

Description

On Windows (Git Bash), when Claude Code prompts the user to approve a Bash command that contains a file path, the "always allow" option generates a rule using Windows backslash separators — even though the original command used forward slashes.

This means the saved rule can never match future commands (which also use forward slashes), so the user gets prompted again every time.

Steps to Reproduce

  1. Run Claude Code on Windows with Git Bash
  2. Have Claude execute a Bash command with a forward-slash path, e.g.: 
    sed -n '/pattern/p' docs/trackers/backlog.yaml
  3. Observe the permission prompt: 
    Do you want to proceed?
1. Yes
2. Yes, and always allow access to trackers\ from this project
3. No
  4. Note trackers\ (backslash) in option 2, even though the command used trackers/ (forward slash)
  5. If user picks option 2, the saved allow rule uses backslash — but all subsequent commands use forward slashes, so the rule never matches and the user is prompted again

Expected Behavior

The "always allow" rule should normalize to forward slashes (matching the Bash/POSIX convention), or the permission matcher should normalize both sides before comparing — so a rule saved from one invocation actually matches the next identical command.

Related Issues

  • #30736 — allowedTools glob patterns never match Windows backslash paths (same root cause: path separator mismatch in permission matching)
  • #30524 — unnecessary cd prepended due to path format mismatch
  • #21878 — hook scripts fail due to backslash path interpretation

Environment

  • OS: Windows 11 Pro
  • Shell: Git Bash
  • Claude Code: latest

extent analysis

TL;DR

The "always allow" option should be modified to use forward slashes in the saved rule or the permission matcher should be updated to normalize path separators before comparing.

Guidance

  • Investigate the code responsible for generating the "always allow" rule and update it to use forward slashes instead of backslashes.
  • Consider implementing path normalization in the permission matcher to ensure consistent comparison regardless of the path separator used.
  • Review related issues (#30736, #30524, #21878) to identify potential areas where similar path separator mismatches may be occurring.
  • Test the updated code with various path formats to ensure the "always allow" rule is correctly saved and matched.

Example

No explicit code example is provided, but the issue implies that the code generating the "always allow" rule may need to be updated to use a consistent path separator, such as:

# Original code (hypothetical)
rule_path=$(echo "$command" | sed 's#/\\#g')

# Updated code (hypothetical)
rule_path=$(echo "$command" | sed 's#\\#/#g')

Note that this is a hypothetical example and the actual code changes required may vary.

Notes

The issue is specific to Windows and Git Bash, and the solution may need to account for these environment specifics. Additionally, the related issues suggest that this may be a broader problem with path separator handling in Claude Code.

Recommendation

Apply a workaround to update the permission matcher to normalize path separators before comparing, as this may be a more comprehensive solution to address the root cause of the issue. This approach can help ensure consistent behavior across different environments and path formats.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#API routing#API middleware#SSR setup#ISR setup#authentication setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING