UNC/network share paths (\\server\share\subdir) fail access check despite being under allowed directory

Environment:

Claude Desktop App (Windows)
MCP Filesystem Server
Windows 11, accessing SMB shares on a QNAP NAS
@modelcontextprotocol/server-filesystem version: 2026.1.14
node.js version: v24.13.1

Configured allowed directories (from list_allowed_directories):
\192.168.4.96\Plex\
\192.168.4.96\Mega
C:
D:
E:\

Issue:
Filesystem server can list the root of a UNC allowed directory but rejects access to any subdirectory within it, even though subdirectory access should be permitted by the path prefix check.

Reproduction steps:

Configure \192.168.4.96\Mega\ as an allowed directory
Call list_directory with path \192.168.4.96\Mega — succeeds, returns full directory listing
Call list_directory with path \192.168.4.96\Mega\Drops — fails with: Access denied - path outside allowed directories: \192.168.4.96\Mega\Drops not in [allowed list]

Observations:

NOT a spaces-in-path issue. Tested with Drops (no spaces) and 00R RPGs (has space) — both fail identically.
Local drive paths (C:, D:, E:) appear to handle subdirectory traversal correctly.
Bug is specific to UNC paths — the prefix matching logic doesn't recognize \server\share\subfolder as a child of \server\share.
Exact root match works (listing the share itself), but any path one level deeper fails the access check.

Expected behavior:

If \192.168.4.96\Mega\ is an allowed directory, all paths under it (e.g., \192.168.4.96\Mega\Drops, \192.168.4.96\Mega\00R RPGs) should pass the access check, consistent with how local drive paths behave.

Impact:

All UNC/network share allowed directories are effectively limited to root-level listing only. No subdirectory navigation is possible, making NAS-hosted file access non-functional for any real use.

Additional note:

Windows mapped drive letters (ie B: mapped to \192.168.4.96\Mega) are not visible to the MCP server process, presumably because mapped drives are per user/per session and the server process doesn't inherit them. This means UNC paths are the only way to access network shares making this bug a complete blocker for NAS-based workflows.

Start by locating the MCP Filesystem Server access check used by list_directory and reproduce the difference between a UNC share root and its subdirectory. Compare the UNC prefix-matching behavior with local drive paths. Done means an allowed UNC directory permits access to nested paths while still rejecting paths outside the allowed list.