Repository navigation
filesystem MCP server doesn't fully support filenames that contain the "NARROW NO-BREAK SPACE" character (U+202F) #1597
Description
Describe the bug
When using Claude desktop on a Mac together with the filesystem MCP server "@modelcontextprotocol/server-filesystem", Claude is unable to perform operations on files that contain the "NARROW NO-BREAK SPACE" Unicode character (U+202F). For example, in attempting to move such a file to a different directory, Claude reports back: "encountered file access issues that prevented the direct move operation."
Renaming the file (e.g. to replace the "NARROW NO-BREAK SPACE" character with a regular space character resolves the issue.
To Reproduce
My Mac is running Sonoma OS 14.6.1 (23G93).
My claude_desktop_config.json file looks like this:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/bserridge/Screenshots"
]
}
}
}
Steps to reproduce the behavior:
- Take a screenshot on the Mac; that'll generate a file with a name something like:
Screenshot 2025-04-26 at 9.52.38 AM.png
The filename has several spaces in it, but the last space, right before the "AM", is not the usual "SPACE" character; rather, by default on the Mac when taking a screensho, it's the "NARROW NO-BREAK SPACE" character (U+202F)
- Ask Claude to move the file to a subdirectory. For example, the following two prompts reproduce the error:
Can you make a new subdirectory (within Screenshots) called "new"?
followed by:
Could you please move the newest screenshot into the "new" subdirectory?
Expected behavior
A clear and concise description of what you expected to happen.
I would expect the screenshot that I just took to be moved into the "new" subdirectory.
Instead, Claude tries several times, using several different approaches, before giving up and concluding:
"I identified "Screenshot 2025-01-18 at 11.15.43 AM.png" as the newest file based on its filename. I attempted multiple approaches to move it, including escaped paths and programmatic methods. I successfully moved a different file (.DS_Store) to demonstrate that the file system works for files without spaces. The issue appears to be a technical limitation in how files with spaces in their names are handled."
I can then go into the terminal and rename the file, changing only the last "narrow" space to a regular space, e.g.:
mv Screenshot\ 2025-04-26\ at\ 9.46.28 AM.png Screenshot\ 2025-04-26\ at\ 9.46.28\ AM.png
After doing so, I can repeat the prompt and it gets executed with success, suggesting that the issue is in the handling of the "NARROW NO-BREAK SPACE" character.
Additional context
Add any other context about the problem here.
Full Claude interaction / conversation here:
https://claude.ai/share/490e32fe-16c6-4bf3-82bb-f22d60bd015d
Activity
bserridge commentedon May 8, 2025
I did some more testing. Here are the logs from my request to list the contents of my Screenshots directory, followed by the request to fetch the file metadata for each file:
2025-05-08T00:45:42.696Z [filesystem] [info] Message from client: {"method":"tools/call","params":{"name":"list_directory","arguments":{"path":"/Users/bserridge/Screenshots"}},"jsonrpc":"2.0","id":21}
Raw request: {
"method": "tools/call",
"params": {
"name": "list_directory",
"arguments": {
"path": "/Users/bserridge/Screenshots"
}
}
}
2025-05-08T00:45:42.711Z [filesystem] [info] Message from server: {"jsonrpc":"2.0","id":21,"result":{"content":[{"type":"text","text":"[FILE] .DS_Store\n[FILE] Screenshot 2025-04-26 at 2.52.14 PM.png\n[DIR] new\n[DIR] old\n[DIR] temp"}]}}
*** notice that in the response above, the space before the "PM" in the filename is a "NARROW NO-BREAK SPACE".
But then in the subsequent call (from the Claude Desktop app on Mac), in the request for metadata about the file, the narrow space has been replaced with a regular space (and hence: the operation fails, returning an error):
2025-05-08T00:45:46.909Z [filesystem] [info] Message from client: {"method":"tools/call","params":{"name":"get_file_info","arguments":{"path":"/Users/bserridge/Screenshots/Screenshot 2025-04-26 at 2.52.14 PM.png"}},"jsonrpc":"2.0","id":22}
Raw request: {
"method": "tools/call",
"params": {
"name": "get_file_info",
"arguments": {
"path": "/Users/bserridge/Screenshots/Screenshot 2025-04-26 at 2.52.14 PM.png"
}
}
}
I wrote some code to test the MCP server implementation directly, and it seemed to respond correctly, so I suspect the issue lies within the Claude client app code, not within the MCP server code.
royseto commentedon May 8, 2025
I did some testing with Claude and without MCP. The following additional test cases also support the conclusion that this behavior comes from Claude, not the filesystem MCP server implementation. I also did the same tests with ChatGPT, which works as I expect.
The behavior seems like it may be narrowly scoped around narrow no-break spaces in strings that look like macOS screenshot filenames. It does not seem to extend to narrow no-break spaces used in isolation or other non-ASCII characters that look similar to ASCII characters.
Full Claude chat with more test cases: https://claude.ai/share/5bf76198-3117-42f6-af10-6d493295dd8d
Versions tested:
Claude for Mac 0.9.3
Also Claude at https://claude.ai/ using Google Chrome 136.0.7103.48 arm64 (same results)
macOS 15.3.1 (24D70)
Test prompt: Does the filename "Screenshot 2025-04-26 at 2.52.14 PM.png" contain any non-ASCII characters?
Actual result from Claude (3.7 Sonnet):
The filename "Screenshot 2025-04-26 at 2.52.14 PM.png" contains only ASCII characters. Every character in this filename falls within the standard ASCII character set, which includes:
Latin letters (both uppercase and lowercase)
Numbers
Common punctuation marks (like the period, hyphen, and space)
Special characters that are part of the ASCII range
There are no non-ASCII characters like accented letters, emojis, or characters from non-Latin writing systems in this filename.
The actual result from ChatGPT (4o) is along the lines of what I expected:
Yes, the filename "Screenshot 2025-04-26 at 2.52.14 PM.png" does contain a non-ASCII character:
The space just before "PM" is a narrow no-break space (Unicode U+202F), not a regular ASCII space (U+0020).
This makes the filename non-ASCII, even though it looks normal at a glance.
This can cause issues in scripts, file matching, or cross-platform compatibility.
Would you like a tool or script to detect and replace such characters in filenames?
When I test Claude with the prompt: Does the string " " contain any non-ASCII characters?
Claude correctly states that
Yes, the string you provided contains a non-ASCII character.
What appears to be a space is actually not the standard ASCII space character (U+0020). It's a different Unicode space-like character that falls outside the ASCII range (0-127)....
domdomegg commentedon Aug 5, 2025
Thanks! Reading this it sounds like it might be a model issue, where the model doesn't like (/or can't) output the NARROW NO-BREAK SPACE character.
Really appreciate the testing by both of you here! I wanted to check if you can reproduce this if you:
mvcommandIf Claude fails in both these cases, I think that pretty much confirms this is a model issue rather than an MCP one. With that confirmation I can take this feedback to the model teams to fix.
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. The filesystem server now resolves Unicode-equivalent paths, including the U+202F narrow no-break space macOS puts in screenshot names, to the file actually on disk.
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.