You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
File system tools unable to traverse symlinked directories beyond top level #734
Describe the bug
The file system tools can't access child directories within a symlinked directory. While the tools can successfully list the contents of the symlinked directory itself, any attempt to access subdirectories results in an error claiming the parent directory doesn't exist.
To Reproduce
Steps to reproduce the behavior:
Create a symbolic link to a directory (e.g., MCP_Servers in MCP_Root)
Use file system tools to access the symlinked directory (succeeds)
Attempt to access any subdirectory within the symlinked directory (fails)
Error message states that the parent directory doesn't exist
Expected behavior
The file system tools should be able to traverse the entire directory structure through the symlink, not just the top level.
list_directory("F:/MCP_Root/MCP_Servers/src")
Error: Parent directory does not exist: F:\MCP_Root\MCP_Servers
read_file("F:/MCP_Root/MCP_Servers/src/filesystem/README.md")
Error: Parent directory does not exist: F:\MCP_Root\MCP_Servers\src\filesystem`
Additional context
This issue prevents programmatic access to configuration details and documentation within the server implementation directories. The symlink appears to be valid as accessing the top-level directory works, but the link cannot be followed deeper into the structure.
Thank you for reporting this, and apologies for the long wait for a response.
Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. Path validation was rewritten: a symlinked allowed directory now admits its whole tree through both the link and its target, while a link inside an allowed directory that points outside it is refused consistently at every level rather than failing only below the top.
This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.
If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see CONTRIBUTING.md.
Activity
cliffhall commentedon Oct 19, 2026
Closing: superseded by the v2 release.
Thank you for reporting this, and apologies for the long wait for a response.
Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. Path validation was rewritten: a symlinked allowed directory now admits its whole tree through both the link and its target, while a link inside an allowed directory that points outside it is refused consistently at every level rather than failing only below the top.
This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.
If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see
CONTRIBUTING.md.Thanks for taking the time to report it.