filesystem MCP server doesn't support legal Windows pathnames in claude_desktop_config.json
Describe the bug
In claude_desktop_config.json, legal Windows characters in pathnames appear unsupported:
Accepted: "C:\\NS\\AI" (works with no spaces and doubled up \ characters)
Accepted: "/Users/NEMANS~1/FOO~2/BAR~1/Thing/Other~1" (used short name / 8.3 name since it avoids risk of spaces or LFN problems)
Unaccepted: "C:\\NS\\My Kindle Content" (problem: spaces)
Unaccepted: "/c/NS/MyKindleContent" (problem: inclusion of drive letter)
Unaccepted: "/mnt/c/NS/MyKindleContent" (problem: inclusion of drive letter)
There are probably other examples too, but I've run out of patience.
Error message:
MCP server filesystem disconnected. For troubleshooting guidance, please visit our debugging documentation.
Note "/Users/NEMANS~1/FOO~2/BAR~1/Thing/Other~1", displays with strikethrough in the UI after the "c:\users\nemans" portion of the resolved pathname string. It's exactly what we see when "/Users/NEMANS~1/FOO~2/BAR~1/Thing/Other~1" isn't marked as code in the bug report editor.
To Reproduce Add a path into the config that includes spaces (and probably other legal-in-Windows characters) or add a path that includes the drive letter.
Expected behavior
- Accept pathnames allowable in Windows in the Windows application's config file
- Improved documentation in the Windows section of https://modelcontextprotocol.io/quickstart/user#2-add-the-filesystem-mcp-server that shows how to include other legal forms of Windows pathnames into the config.
In response to this prompt: List only the files in the folders you have access to. Nothing else.
We get the error: It looks like we can't access the folders named in the config using the 8.3 format: The other two directories (with the shortened/tilde names) appear to be inaccessible - I get an error that their parent directories don't exist, which might be due to the way the paths are written with shortened names
Are my initials part of the problem? The folder C:\NS has \N (newline) in it. It's clearly not the only problem though, since the folders without tildes were properly parsed and analyzed. The complaint is specifically about folders with tildes in the pathnames.
Running into something similar here. Not able to use any filenames with spaces in them. Very frustrating.
I don't think this is an unsupported issue. I think you can try running Claude Desktop as an administrator in Windows. This is how I configured the filesystem of my Claude Desktop.
@cmrhyq doesn't change for me when I run it as admin or regular user. The screenshot is after having added a folder into the config with a space in the folder name then running as admin. Same error, same behaviour. Upon removing that path from the config, all was good again.
This is my configuration for your reference
Thanks @cmrhyq. What happens when you include a folder with a space in the name? My config includes a few folders as I understand it only allows access to explicitly-named folders, not any subfolders, peers, etc. (I don't believe I saw any in yours.)
The config you see in my screen cap works. It fails when I include something like "C:\\NS\\My Kindle Content", regardless of whether run as admin or regular user.
Any news on this topic?
Hi, I was also having issues on one of my machines due to a space in one of my paths. My workaround (not great) was to just create a junction with powershell.
i.e. if it was in your user folder
New-Item -ItemType Junction -Path "C:\Users\john" -Target "C:\Users\John Smith"
I, too, cannot access a folder with spaces in the pathname in Claude Desktop for Windows with the filesystem-server MCP server.
Same here. I'm surprised this has been overlooked at this point
Im having a probably related issue where "C:\Test" will break out t incorrectly resulting in dropping of the t "C:\ est"
@zane-lazare \t is the escape sequence for a horizontal tab (ASCII 0x09); I expect that's what you're seeing.
You'll note in my sample config I've escaped the escape character so \ becomes \\.
See what happens if you write out C:\Test as C:\\Test. (Inside the double quotation marks, of course.)
As long as this bug is not fixed creating a symlink, as @leependu suggested, seems the only way forward. However, I can't get it to work for some reason. Here is Claude's response:
The system showed the following allowed directory path:
C:\Users\[user]\AppData\Local\AnthropicClaude\app-0.9.2\[link]
However, when I attempted to access this directory, the system returned an error indicating that the parent directory doesn't exist. This suggests that while this is technically listed as an "allowed" path, it doesn't actually exist or isn't properly accessible in your current filesystem.
The symlink works but its parent directory contains a space--that's why I created the symlink in the first place. What could be wrong?
FWIW I filed a more tightly scoped, but perhaps related issue, that I observed on MacOS:
https://github.com/modelcontextprotocol/servers/issues/1597
This seems like a fault in Claude Desktop, where it handles invoking shell commands incorrectly.
Using Process Monitor to investigate how it was creating the shell, the command from the Claude executable on my system is:
C:\WINDOWS\System32\cmd.exe /C "C:\Program Files\nodejs\npx.cmd" -y @modelcontextprotocol/server-filesystem C:\Users\username\Desktop C:\Users\username\Downloads C:\Users\username\Documents\Obsidian "C:\Users\username\Documents\Obsidian\My Vault"
(when I add escaped quotes in the JSON file to deal with the space in the last file name)
Running this by itself in PowerShell reproduces the same error - with the quoted path at the end, it fails with the same 'C:\Program' is not recognized as an internal or external command that shows up in the MCP log files.
Reading about quoting rules for cmd by running cmd /? you get these weird rules where having more than two quotes means the first and last get stripped (??):
If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:
1. If all of the following conditions are met, then quote characters
on the command line are preserved:
- no /S switch
- exactly two quote characters
- no special characters between the two quote characters,
where special is one of: &<>()@^|
- there are one or more whitespace characters between the
two quote characters
- the string between the two quote characters is the name
of an executable file.
2. Otherwise, old behavior is to see if the first character is
a quote character and if so, strip the leading character and
remove the last quote character on the command line, preserving
any text after the last quote character.
One way to deal with this seems to be wrapping the whole command in double quotes, which means when rule 2 applies those get removed and we end up with the intended string:
C:\WINDOWS\System32\cmd.exe /C ""C:\Program Files\nodejs\npx.cmd" -y @modelcontextprotocol/server-filesystem C:\Users\username\Desktop C:\Users\username\Downloads C:\Users\username\Documents\Obsidian "C:\Users\username\Documents\Obsidian\My Vault""
^ This works in PowerShell
I don't know how to enforce this through the JSON file though, you'd have to modify Claude's source to fix this.
Hey all, I just rfeallized that MCP server does not take spaces between file name properly in cmd. It been a month that I was findng solutions and doing several things one by one. I think it needs to be fixed.
Heya! Is someone with a Windows device able to confirm that the filesystem MCP works in other clients correctly with spaces in paths? (e.g. Claude Code or VS Code)
If so, this is a Claude Desktop issue. Otherwise, it suggests it's an issue with the MCP server. Knowing this will allow us to put forward a fix in the right place.
Thanks!
I don't believe this is thoroughly resolved. Upon adding the yellow-highlighted line into claude_desktop_config.json:
"C:\\NS\\My Kindle Content",
and no other changes, Claude desktop 0.12.55.0 throws the error:
MCP filesystem: Server disconnected.
at launch. (I can use it otherwise.)
I don't know if this warrants reopening the issue. Maybe there's an unclear undocumented syntax? All other listed folders worked and caused no errors.
Spaces in paths folders are still causing Claude to fail (as of 0.14.10) filesystem MCP on Windows
Fully legal pathnames with spaces are still a problem with Claude Desktop 1.0.0332 (b563c9). There are no mentions of how to handle spaces in the debugging guide or really anywhere. Spaces are not only legal characters in Windows pathnames but are actually path of OOB OS folders (e.g. C:\Program Files (x86)) or other virtually guaranteed-to-be-used paths (e.g. C:\Users\NemanSyed\OneDrive - Company Name\My Folder).
It's now also rejecting the
"/Users/NEMANS~1/blah/blah"
style paths which previously worked (see my last screen caps), so it's not only not fixed, it's getting worse. :-(
MCP Filesystem Server - Windows "Program Files" Path Issue Workaround
Environment
- Windows 11
- Claude Desktop 1.0.1217
- Node.js installed at
C:\Program Files\nodejs\
Problem
When Node.js is installed in a path containing spaces (like C:\Program Files\nodejs\), the MCP filesystem server fails to start with:
'C:\Program' is not recognized as an internal or external command
Claude Desktop's JSON config parser doesn't properly handle the space in the path when resolving npx.
Solution: Use cmd as Wrapper
Instead of letting Claude Desktop resolve npx directly, use cmd as the command and let Windows handle PATH resolution:
{
"mcpServers": {
"localfiles": {
"command": "cmd",
"args": [
"/c",
"npx",
"-y",
"@modelcontextprotocol/server-filesystem",
"C:\\Users\\YourUsername\\Documents\\Your Folder"
]
}
}
}
Why This Works
-
cmdis inC:\Windows\System32\(no spaces) -
cmd /cthen uses Windows' native PATH resolution to findnpx - Windows handles the
Program Filespath correctly internally
Additional Issue: Naming Collision with Built-in Extension
Claude Desktop has a built-in Filesystem MCP extension. If you name your custom server filesystem or Filesystem, it can cause:
- Duplicate entries in the tools list
- Claude Desktop using the built-in instead of your config
- Immediate crashes after initialization with "Server transport closed unexpectedly"
Solution
Use a completely different name for your custom filesystem server:
{
"mcpServers": {
"localfiles": {
"command": "cmd",
"args": ["/c", "npx", "-y", "@modelcontextprotocol/server-filesystem", "C:\\Your\\Path"]
}
}
}
Good names: localfiles, myfiles, userfs, anything that doesn't match the built-in.
Complete Working Example
{
"mcpServers": {
"localfiles": {
"command": "cmd",
"args": [
"/c",
"npx",
"-y",
"@modelcontextprotocol/server-filesystem",
"C:\\Users\\hfgot\\Documents\\Stuff For Claude"
]
}
}
}
Log Evidence
Before fix (failing):
Using MCP server command: C:\Windows\System32\cmd.exe with args and path:
args: ['/C', 'C:\\Program Files\\nodejs\\npx.cmd', ...]
Result: Path with space breaks.
After cmd wrapper (working):
Using MCP server command: C:\Windows\system32\cmd.exe with args and path:
args: ['/c', 'npx', '-y', '@modelcontextprotocol/server-filesystem', ...]
Server started and connected successfully
Message from client: {"method":"tools/list"...}
Client does not support MCP Roots, using allowed directories set from server args
Summary
Two issues, two fixes:
-
Space in path → Use
cmdwrapper instead of directnpx -
Naming collision → Don't name your server
filesystemorFilesystem