Bash permission `allow` rules (wildcard and exact-match) never suppress prompts on WSL project opened via `\\wsl$` UNC path (VSCode WSL Remote)

## Environment

• Claude Code: VSCode native extension (win32 host), version 2.1.207
• Host OS: Windows 10 Home 10.0.19045
• Project location: WSL2 Ubuntu-20.04 filesystem, opened in VSCode via the WSL Remote extension
• Working directory as shown to the agent: \\wsl$\Ubuntu-20.04\home\someuser\projects\myproject
• Two shell tools available in-session: Bash (routes to WSL) and PowerShell (native Windows)

Summary

For this project, entries in permissions.allow in .claude/settings.json / .claude/settings.local.json never suppress the approval prompt for Bash commands — not wildcard rules, not exact-match rules, including a rule the session had just auto-persisted seconds earlier for the identical command string. This holds across every settings file location, every permission mode, and fresh vs. resumed conversations.

Repro steps

1. Open a WSL-hosted project in VSCode via the WSL Remote extension (project path surfaced to the agent as a \\wsl$\... UNC path).
2. Ensure .claude/settings.json (project root) contains a broad allow rule, e.g.:

``json
{ "permissions": { "allow": ["Bash(node *)"] } }
``

1. In a brand-new conversation, ask Claude to run:

``
node -e "console.log('marker-' + Date.now())"
``

1. Observed: prompts for approval, despite matching Bash(node *).
2. Approve it. Claude Code auto-persists an exact-match rule to .claude/settings.local.json, e.g.:

``
"Bash(node -e \"console.log\\('marker-' + Date.now\\(\\)\\)\")"
``

1. Immediately ask Claude to run the exact same command string again, in the same session.
2. Observed: prompts again, even though an exact-match rule for this literal command was written to disk moments earlier by this same session.

What was ruled out

• Stale/resumed session state — reproduces identically in a brand-new conversation.
• Wrong settings file location — tried project .claude/settings.json (git-tracked), project .claude/settings.local.json (gitignored), WSL-side user settings (/home/someuser/.claude/settings.json), and Windows-side user settings (C:\Users\someuser\.claude\settings.json). None suppressed prompts. (The Windows-side user settings file was also observed to be silently overwritten/clobbered down to a single narrow auto-generated rule shortly after being hand-edited with broader rules — separate but possibly related oddity.)
• Wildcard-matching syntax specifically — an exact-match rule (no wildcard) freshly written by the session for the identical command also failed to suppress the very next identical call.
• Permission mode — reproduced under "Edit automatically" (acceptEdits) and "Manual" (default) modes.
• Config not reloaded — opening /hooks (documented as a reload trigger) had no effect; neither did restarting the extension/VSCode.

Expected behavior

A command matching a permissions.allow rule (wildcard or exact) should run without a prompt. At minimum, a rule the current session just auto-persisted for an identical command string should suppress the very next identical invocation within the same session.

Suspected area

Given writes to settings.local.json visibly succeed (the new rule appears in the file, confirmed via Read tool) but are never subsequently honored — even same-session — this looks like the permission-checking code path is not reading back the same settings scope it writes to, possibly related to project-root/path resolution for a project opened via a \\wsl$ UNC path from a native Windows (win32) process.