Exact error
Match the message before using the fix
Error accessing directory ... ENOENT: no such file or directory, stat ...Server transport closed unexpectedlyMCP Filesystem: Server disconnectedCould not attach to MCP server FilesystemQuick answer
Start here
Check every configured allowed directory. Restore or remount the missing path, or remove only that stale entry while keeping at least one valid allowed directory, then restart the MCP server and client. One missing path can stop the entire server before tools become available. If the client supplies MCP Roots, update those roots instead of editing a duplicate command-line list.
Diagnosis
Why it happens
- Startup validation can reject the full allowed-directory set when one path returns ENOENT.
- A folder may have been renamed, or a mapped drive, NAS share, external disk, or synced location may be offline.
- Clients that support MCP Roots can replace server-side allowed directories, so the stale path may come from the client rather than the launch command.
Safest first
Fixes, in order
Find the missing allowed directory
Applies when: First step when the log names a path followed by ENOENT
The exact missing path is the useful signal; the later disconnected message is only the consequence of startup failure.
- Copy the exact path from the first ENOENT line.
- Check whether that folder currently exists and whether its drive or network share is connected.
- Compare it with every allowed directory in the client or server configuration.
- Do not widen access to a parent drive just to make startup succeed.
Expected: You identify one absent, renamed, or unavailable path in the allowed-directory set.
Restore the path or remove only the stale entry
Applies when: When the missing directory is no longer valid or its storage is temporarily offline
Reports confirm that correcting the allowed-directory set lets the server initialize again.
- Remount the volume or recreate the intended folder if it should still exist.
- Otherwise, back up the MCP configuration and remove only the stale path.
- Keep at least one narrow, existing allowed directory.
- Restart both the MCP server and its client.
Expected: The server remains connected and exposes its Filesystem tools.
Update client Roots when Roots are authoritative
Applies when: Clients that negotiate MCP Roots instead of relying only on launch arguments
The current Filesystem documentation says Roots can replace server-side allowed directories.
- Inspect the roots shown by the client after the server connects.
- Remove or correct the missing workspace root in the client.
- Avoid maintaining conflicting directory lists in both places.
- Run `list_allowed_directories` to confirm the active set.
Expected: The active allowed-directory list contains only valid, intended roots.
Verification
Prove the fix worked
- Run `list_allowed_directories` and confirm every returned path exists.
- List or read one harmless file inside a valid root.
- Confirm an unrelated path outside the allowed roots is still rejected.
Escalation
If it still fails
- Capture the first server log line before the generic disconnected message.
- Check service-account permissions if the path exists but the process still cannot stat it.
- Record the server package, client name, active Roots, and whether the path is local, mapped, UNC, or removable.
Scope
Environment and version notes
- The behavior appears in a January 2026 Filesystem report and later Windows secure-filesystem-server 0.2.0 reports.
- The upstream issue was closed as not planned; that status does not mean the startup behavior was fixed.
- 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 missing allowed-directory ENOENT followed by transport closure.
Windows report where one missing configured path prevents server startup.
Current primary documentation for allowed directories, MCP Roots, and list_allowed_directories.