Exact error
Match the message before using the fix
Access denied - path outside allowed directories: Y:\k8s not in \\server\share\gitAccess denied - path outside allowed directoriesQuick answer
Start here
Run `list_allowed_directories`, then use the exact UNC spelling it returns for Filesystem tool calls instead of the mapped drive letter. In the confirmed report, `Y:\...` was rejected while the equivalent `\\server\share\...` path succeeded. Keep the allowed share narrow; do not authorize the whole server or drive.
Diagnosis
Why it happens
- Windows can expose the same network location as both a mapped drive and a UNC path.
- The server's boundary check compared the requested `Y:` form with an allowed directory normalized to `\\server\share`, so the strings did not share the same root.
- A similar message can also mean the share is offline or genuinely outside the allowed root, so confirm the active allowed directories first.
Safest first
Fixes, in order
Read the active allowed-directory form
Applies when: First step when the rejected path begins with a mapped drive letter
The server itself shows which canonical spelling its boundary check is using.
- Run the Filesystem tool `list_allowed_directories`.
- Find the allowed root corresponding to the mapped drive.
- Copy its exact UNC prefix, including server and share names.
- Confirm the intended target is actually beneath that narrow root.
Expected: The active root is visible as a UNC path such as `\\server\share\git`.
Use the returned UNC path in the tool call
Applies when: When `list_allowed_directories` returns UNC but the failed request uses `Y:` or another drive letter
Using the server's own canonical form was the confirmed workaround in the upstream report.
- Replace only the mapped-drive prefix with the exact returned UNC root.
- Keep the rest of the subdirectory unchanged.
- Retry a harmless directory listing before any write.
- Use the same UNC form consistently in later Filesystem calls.
Expected: The same network directory is accepted when requested in UNC form.
Separate normalization from connectivity
Applies when: When both mapped and UNC forms fail
An offline share, expired credentials, or a genuinely different root is not the normalization bug.
- Open both the mapped drive and UNC path outside MCP using the same Windows account.
- Reconnect the share or credentials if Windows itself cannot access it.
- Compare the exact target with the narrow allowed root.
- Do not broaden access beyond the share required for the task.
Expected: Windows connectivity works and the MCP request uses a path truly inside the active allowed root.
Verification
Prove the fix worked
- List the same harmless directory through its UNC path.
- Confirm `list_allowed_directories` still shows the intended narrow share.
- Confirm a sibling path outside that allowed root remains blocked.
Escalation
If it still fails
- Capture the exact output of `list_allowed_directories` and the exact rejected request path.
- Record the client, Filesystem server version, Windows account context, and mapping command.
- Check whether the client rewrites Roots after startup before changing server arguments.
Scope
Environment and version notes
- The confirmed report used Claude Desktop 1.6608.2 and Filesystem server 0.2.2 on Windows.
- The upstream issue was closed as not planned; the UNC workaround remains evidence, not proof of an upstream fix.
- Sources rechecked August 20, 2026.
Evidence
Sources
Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.
First-hand mapped-drive rejection, UNC allowed-directory output, and confirmed UNC workaround.
Current primary documentation for allowed directories and list_allowed_directories.
Related upstream Windows path-normalization discussion linked from the report.