Deny rules with absolute Windows paths do not block file access

Description

Permission deny rules using absolute Windows paths in global settings.json (~/.claude/settings.json) do not block Read/Edit/Write tool calls. Files under denied paths remain fully accessible.

Environment

• OS: Windows 11 Pro
• Shell: Git Bash
• Claude Code: VSCode extension (latest)

Steps to reproduce

1. Add deny rules in ~/.claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(D:/some/protected/path/**)",
      "Edit(D:/some/protected/path/**)",
      "Write(D:/some/protected/path/**)"
    ]
  }
}

1. Restart VSCode / start a new session
2. Ask Claude to read a file under that path
3. Expected: tool call is blocked
4. Actual: file is read successfully, no blocking

Patterns tested (all failed to block)

• Read(D:/some/path/**)
• Read(//D:/some/path/**)
• Read(**/dirname/**)

Why this matters

In enterprise environments, blocking access to shared drives (OneDrive, SharePoint, network shares) and sensitive directories is a baseline security requirement before deploying Claude Code. Without reliable absolute path deny rules on Windows, there is no native mechanism to enforce directory-level access control.

Hooks can partially work around this, but deny rules should be the primary, reliable mechanism.

Expected behavior

Deny rules with absolute Windows paths should block tool access consistently, matching the behavior on Unix-like systems.