additionalDirectories with Unix-style paths don't work for Bash cd on Windows (MINGW64)

Description

On Windows (MINGW64/Git Bash), additionalDirectories entries using Unix-style paths (e.g. /tmp or \tmp) don't grant Bash command permissions, while Windows-style paths (e.g. C:\Users) work correctly.

Environment

• Platform: win32 (MINGW64_NT-10.0-26200)
• Shell: bash (Git Bash / MINGW64)
• Claude Code: latest

Reproduction

In .claude/settings.json:

{
  "permissions": {
    "additionalDirectories": [
      "\tmp",
      "C:\Users"
    ]
  }
}

Works

• cd C:/Users — auto-approved, no permission prompt
• Read/Write/Glob tools work for both /tmp and C:\Users

Doesn't work

• cd /tmp — always prompts for permission, never auto-approved

We also tried "//tmp" as the entry — same result.

Additional context

This appears to be a path normalization issue. On MINGW64, /tmp is a valid Unix-style path but doesn't map to a Windows drive letter path like C:\Users does. The Bash permission check seems to require Windows-style absolute paths to match, while the file-access tools (Read, Write, Glob, Grep) handle both formats fine.

We also confirmed that Bash allow rules like "Bash(cd:*)", "Bash(cd *)", and "Bash(cd*)" don't work for cd — which is a separate known issue with shell builtins. The additionalDirectories approach works for Windows paths but not Unix-style paths.

Expected behavior

additionalDirectories entries should work with Unix-style paths (/tmp) on MINGW64, granting the same Bash command permissions as Windows-style paths.