Describe the bug
On a POSIX host, passing a Windows-style path such as C:\Users\me\notes\file.md to write_file does not fail. It succeeds, and the server answers Successfully wrote to C:\Users\me\notes\file.md.
What actually happens is that a single file is created directly inside the allowed root, whose filename is the entire string, backslashes included:
/Users/me/C:\Users\me\notes\file.md
This is not a containment failure — nothing escapes the sandbox, and isPathWithinAllowedDirectories is doing its job. It is the absence of a rejection for a string that can only mean something on another OS. The caller believes it wrote to a Windows location; what exists is an unpronounceable file at the root of the allowed directory, and the success message gives no hint. In our case the file sat unnoticed for about three weeks.
Why it happens
In src/filesystem/lib.ts:
export async function validatePath(requestedPath: string): Promise<string> {
const expandedPath = expandHome(requestedPath);
const absolute = path.isAbsolute(expandedPath)
? path.resolve(expandedPath)
: resolveRelativePathAgainstAllowedDirectories(expandedPath);Under POSIX, path.isAbsolute("C:\\Users\\me\\notes\\file.md") is false. The string therefore takes the relative branch, and resolveRelativePathAgainstAllowedDirectories does path.resolve(allowedDir, thatString). The result lands inside the allowed root, so isPathWithinAllowedDirectories legitimately approves it, and the write proceeds.
The same reasoning applies to C:/Users/me/... — there the directory tree C:/Users/... is created inside the allowed root instead.
To Reproduce
- Run the server on macOS or Linux with a single allowed directory, e.g.
/tmp/sandbox.
- Call
write_file with path: "C:\\Users\\me\\notes\\file.md" and any content.
- Observe the response:
Successfully wrote to C:\Users\me\notes\file.md.
ls /tmp/sandbox shows one entry named C:\Users\me\notes\file.md.
Expected behavior
validatePath should refuse a string that matches a Windows drive-letter prefix (^[A-Za-z]:[\\/], and the bare ^[A-Za-z]:$) when process.platform !== 'win32', instead of silently treating it as a relative path. An explicit error — something like Access denied - Windows-style path received on a POSIX host — turns a silent, late-discovered mistake into an immediate one.
A narrower alternative, if outright rejection is considered too strict: keep accepting it but never let a drive-letter string reach the relative branch, and say so in the response.
Please be careful not to reintroduce #3628
That report is the mirror image of this one: a Linux path like /h/user/data was converted into H:\user\data. The fix proposed here is deliberately one-directional and platform-guarded — reject the drive-letter form, only when not running on Windows, and never rewrite POSIX paths.
Environment
@modelcontextprotocol/server-filesystem — reproduced against the code currently on main (src/filesystem/lib.ts, the validatePath / resolveRelativePathAgainstAllowedDirectories pair quoted above).- Also reproduced against the shipped Claude Desktop Filesystem extension, version
2026.7.10, on macOS with Node v24.19.0.
Describe the bug
On a POSIX host, passing a Windows-style path such as
C:\Users\me\notes\file.mdtowrite_filedoes not fail. It succeeds, and the server answersSuccessfully wrote to C:\Users\me\notes\file.md.What actually happens is that a single file is created directly inside the allowed root, whose filename is the entire string, backslashes included:
This is not a containment failure — nothing escapes the sandbox, and
isPathWithinAllowedDirectoriesis doing its job. It is the absence of a rejection for a string that can only mean something on another OS. The caller believes it wrote to a Windows location; what exists is an unpronounceable file at the root of the allowed directory, and the success message gives no hint. In our case the file sat unnoticed for about three weeks.Why it happens
In
src/filesystem/lib.ts:Under POSIX,
path.isAbsolute("C:\\Users\\me\\notes\\file.md")isfalse. The string therefore takes the relative branch, andresolveRelativePathAgainstAllowedDirectoriesdoespath.resolve(allowedDir, thatString). The result lands inside the allowed root, soisPathWithinAllowedDirectorieslegitimately approves it, and the write proceeds.The same reasoning applies to
C:/Users/me/...— there the directory treeC:/Users/...is created inside the allowed root instead.To Reproduce
/tmp/sandbox.write_filewithpath: "C:\\Users\\me\\notes\\file.md"and any content.Successfully wrote to C:\Users\me\notes\file.md.ls /tmp/sandboxshows one entry namedC:\Users\me\notes\file.md.Expected behavior
validatePathshould refuse a string that matches a Windows drive-letter prefix (^[A-Za-z]:[\\/], and the bare^[A-Za-z]:$) whenprocess.platform !== 'win32', instead of silently treating it as a relative path. An explicit error — something likeAccess denied - Windows-style path received on a POSIX host— turns a silent, late-discovered mistake into an immediate one.A narrower alternative, if outright rejection is considered too strict: keep accepting it but never let a drive-letter string reach the relative branch, and say so in the response.
Please be careful not to reintroduce #3628
That report is the mirror image of this one: a Linux path like
/h/user/datawas converted intoH:\user\data. The fix proposed here is deliberately one-directional and platform-guarded — reject the drive-letter form, only when not running on Windows, and never rewrite POSIX paths.Environment
@modelcontextprotocol/server-filesystem— reproduced against the code currently onmain(src/filesystem/lib.ts, thevalidatePath/resolveRelativePathAgainstAllowedDirectoriespair quoted above).2026.7.10, on macOS with Node v24.19.0.