[BUG] Windows: permission prompt generates backslash allow-rules that never match forward-slash Bash commands

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
``

1. Observe the permission prompt:

```
Do you want to proceed?

1. Yes
2. Yes, and always allow access to trackers\ from this project
3. No

```

1. Note trackers\ (backslash) in option 2, even though the command used trackers/ (forward slash)
2. 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