Filesystem Desktop Extension: path validation fails on Windows with spaces and German umlauts in subdirectory names

[Hinz-Y]

The Filesystem Desktop Extension (installed via Claude Desktop's built-in extension
directory) fails to access subdirectories that contain spaces or German umlauts
(ä, ö, ü, Ä, Ö, Ü) in their names. The root drive letter is accepted, but all
subdirectory access is blocked with a path validation error.

This is a significant issue for enterprise environments in German-speaking countries,
where folder names like 03- FORMBLÄTTER or Qualitätsmanagement are standard on
corporate file servers.

I'm aware of #447 and #2437, and that PR #543 added support for spaces in the npx-based
server. However, the issue persists in the Claude Desktop Filesystem Extension
(installed via Settings → Extensions → Filesystem), suggesting the extension may bundle
an older version without the fix.

To Reproduce

1. Install the Filesystem Desktop Extension via Claude Desktop → Settings → Extensions
   → Filesystem
2. Add a mapped network drive (e.g. Q:\) as an allowed directory
3. The network drive's UNC path has no spaces (e.g. \\server\gpe-qm)
4. The drive contains subdirectories with spaces and/or umlauts, e.g.:
   • Q:\03- FORMBLÄTTER
   • Q:\Qualitätsmanagement\Dokumente
5. Ask Claude to list or read files in any subdirectory

Expected behavior

Claude should be able to traverse and read files in subdirectories regardless of
spaces or special characters (umlauts) in folder names.

Actual behavior

Claude reports:

"Der Filesystem-Server verweigert aktuell den Zugriff auf alle Unterordner
(vermutlich ein Pfad-Validierungsfehler bei Leerzeichen in UNC-Pfaden).
Ich kann daher keine Dateiinhalte lesen."

The root drive Q:\ is recognized as an allowed directory, but access to ALL
subdirectories fails — not just those with spaces/umlauts.

Environment

• OS: Windows 10/11 (Enterprise, managed via Microsoft Intune)
• Claude Desktop: Latest version (March 2026)
• Filesystem Extension: Installed from built-in extension directory
• Drive mapping: Q: → \\server\gpe-qm (UNC path has no spaces)
• Subdirectory examples: Q:\03- FORMBLÄTTER, contains spaces + umlaut (Ä)

Additional context

• The UNC path behind the drive letter contains no spaces
  (\\srvgpenwm3\gpe-qm) — confirmed via net use Q:
• The issue affects the Desktop Extension variant, not a manually configured
  npx-based MCP server
• Related issues: filesystem MCP server doesn't support legal Windows pathnames in claude_desktop_config.json #447, Filesystem server fails with directory paths containing spaces #2437
• Related fix: PR Windows filesystem MCP enhancements #543 (merged Aug 2025) — may not be included in the Desktop
  Extension build

[Hinz-Y]

Update: Additional testing reveals fundamental UNC path validation bug

After further testing with both the Desktop Extension AND the npx-based server
(@modelcontextprotocol/server-filesystem), I can confirm the issue is not limited
to spaces or umlauts in folder names. The path validation for UNC paths is
fundamentally broken.

Test setup

• Mapped drive: Q:\ → \\fileserver\sharename (no spaces in UNC path)
• Config: "Q:\\" as allowed directory in claude_desktop_config.json
• Server resolves Q:\ to UNC path \\fileserver\sharename on startup

Test results

Test	Path	Result
list_allowed_directories	—	✅ Shows \\fileserver\sharename\ (correctly resolved)
list_directory	Q:\	❌ "Access denied - path outside allowed directories"
list_directory	\\fileserver\sharename	✅ Works — lists all subdirectories
list_directory	\\fileserver\sharename\SimpleFolder	❌ "Access denied - path outside allowed directories"
list_directory	\\fileserver\sharename\03- FORMBLÄTTER	❌ "Access denied - path outside allowed directories"

Key findings

1. Root UNC path works, but ALL subdirectories are rejected — even those
   without spaces or special characters (e.g. a folder named SimpleFolder
   with no spaces, no umlauts).
2. The server correctly resolves Q:\ → \\fileserver\sharename at startup,
   but then the validatePath() function fails to recognize subdirectories as
   being inside the allowed root.
3. The drive letter itself (Q:\) is also rejected after resolution, meaning
   neither the original path nor the resolved UNC path works for traversal.
4. This affects both the Desktop Extension and the npx-based server.

Likely root cause

The validatePath() / normalizePath() functions in lib.ts / path-utils.ts
appear to not correctly handle the parent-child relationship for UNC paths
(\\server\share\subfolder should match as child of \\server\share\).
This may be a string prefix comparison issue where the trailing backslash or
path normalization breaks the match.

Impact

This makes the Filesystem MCP Server unusable for mapped network drives in
enterprise Windows environments — a very common setup. Users can list the root
directory but cannot access any files or subdirectories, which defeats the purpose.

Environment

• Windows 11 Enterprise (managed via Microsoft Intune)
• Node.js v22.x LTS
• @modelcontextprotocol/server-filesystem (latest via npx, March 2026)
• Claude Desktop latest version
• Network drive mapped via GPO/Intune to a Windows file server share

[vibemarketing99]

I think this is more likely a path-normalization / validation mismatch than a raw UTF-8 issue.

In the filesystem server, the risky path is usually: user-supplied path -> validation against allowed directories -> later normalization/resolution. On Windows, that tends to break on some mix of:

• drive-letter casing
• slash normalization
• UNC handling
• paths containing spaces or non-ASCII characters

The first thing I’d tighten is making sure both:

• the requested path, and
• the configured allowed directories

are canonicalized through the same normalization / resolution path before the prefix/containment check happens.

I’d also add a regression test for:

• a Windows path with spaces
• a path with non-ASCII characters
• and, if supported, a UNC-style path

If helpful, I can also sketch the exact place in the filesystem server where I think that comparison should be tightened.

[Hinz-Y]

Additional test results: root cause identified via Node.js path analysis

After further debugging I can now pinpoint the exact root cause of the UNC subdirectory access failure. The issue is not in startsWith() itself — it is in the fact that path.resolve() in Node.js does not resolve drive letters to their underlying UNC path.

Test setup

• Mapped drive: X:\ → \\fileserver\sharename (no spaces in UNC path)
• Config: "X:\\" as allowed directory in claude_desktop_config.json
• Node.js version: v24 LTS

Node.js REPL results

const path = require('path');

// 1. String comparison works correctly on its own
const root = '\\\\fileserver\\sharename';
const sub  = '\\\\fileserver\\sharename\\SimpleFolder';
const sub2 = '\\\\fileserver\\sharename\\';

console.log(sub.startsWith(root));   // true  ✅
console.log(sub.startsWith(sub2));   // true  ✅

// 2. path.resolve() does NOT resolve drive letters to UNC
console.log(path.resolve('X:\\'));             // X:\        ❌ (not \\fileserver\sharename)
console.log(path.resolve('X:\\SimpleFolder')); // X:\SimpleFolder  ❌

// 3. path.resolve() on UNC root adds a trailing backslash
console.log(path.resolve('\\\\fileserver\\sharename'));
// \\fileserver\sharename\   ← trailing backslash added

Root cause

The server correctly resolves X:\ → \\fileserver\sharename at startup (via WNetGetConnection or equivalent) and stores the UNC path as the allowed directory.

However, when a request comes in for X:\SimpleFolder, the server calls path.resolve('X:\\SimpleFolder'), which returns X:\SimpleFolder — not \\fileserver\sharename\SimpleFolder. Node.js path.resolve() has no mechanism to translate drive letters to UNC paths; that requires a Windows API call.

The resulting comparison is:

'X:\SimpleFolder'.startsWith('\\fileserver\sharename')  →  false  ❌

Access is denied for every subdirectory — even ones with no spaces or special characters — because the path normalization happens on two different representations of the same location.

Secondary issue

path.resolve('\\\\fileserver\\sharename') appends a trailing backslash, producing \\fileserver\sharename\. Depending on whether the stored allowed-directory value includes this trailing backslash or not, even a direct UNC request for the root may fail the prefix check for subdirectories.

Suggested fix

Before the validatePath() containment check, both the requested path and the allowed directory must be canonicalized through the same resolution step. On Windows, if the allowed directory was stored as a UNC path after startup resolution, any incoming drive-letter path must also be resolved to its UNC equivalent before comparison — not just normalized via path.resolve().

One approach: use fs.realpathSync() or a WNetGetConnection-equivalent (e.g. via a native addon or PowerShell subprocess) on the incoming path before validation, so both sides of the comparison are always in UNC form.

Impact

This makes the Filesystem MCP Server completely unusable for mapped network drives on Windows — a very common enterprise setup. The root directory appears accessible (list_allowed_directories shows the correct UNC path), but every subdirectory access fails, regardless of whether the path contains spaces or special characters.

Environment: Windows 11 Enterprise, Node.js v24 LTS, @modelcontextprotocol/server-filesystem latest (March 2026), Claude Desktop latest