move_file fails with non-ASCII characters in file path (e.g. French accents, œ, typographic apostrophe)

[Eclipse972]

Server: @modelcontextprotocol/server-filesystem
OS: Linux (Ubuntu)

Description:
move_file fails with ENOENT when the source path contains non-ASCII characters
such as French accented letters (é, è, à), ligatures (œ), or typographic
apostrophes (').

Other tools like read_text_file, list_directory, and search_files handle
these characters correctly.

Steps to reproduce:

1. Have a file named e.g. C1.1 - Mettre en œuvre une démarche.md
2. Call move_file with that path as source
3. → ENOENT: no such file or directory

Expected: file is moved/renamed
Actual: ENOENT error

[AmirF194]

Reproduced, and it isn't specific to move_file: read_text_file and search_files fail the same way, list_directory just happens not to need the failing comparison.

Root cause: fs.realpath/fs.rename/fs.readFile compare filenames as raw bytes with no Unicode normalization. If the file's real on-disk name and the string a caller passes in differ only in normalization form (NFC composed vs NFD decomposed), the OS lookup misses even though the two strings look identical.

Verified by driving the real server over stdio (build + tools/call, not a unit test) against HEAD 76d64c8, node:22-slim:

• Created a file whose real name is NFD-decomposed ("...démarche.md".normalize("NFD"), the form macOS's HFS+/APFS store for accented names by default).
• Called move_file with the visually identical NFC (composed) form as source: ENOENT: no such file or directory, rename '/data/C1.1 - Mettre en œuvre une démarche.md' -> ..., matching the error in this report.
• The same mismatch also breaks read_text_file (ENOENT ... open ...) and search_files (silently returns "No matches found"). list_directory only "works" because it echoes fs.readdir()'s raw bytes back; it never has to match a caller-supplied name against disk.

So the differential in the report (move_file fails, the others don't) is more likely about where each path string came from (copied from a prior list_directory result vs. retyped or pasted from elsewhere) than something specific to move_file's code. validatePath (lib.ts:99) is shared by all of these tools; the actual OS-level miss happens at fs.realpath(absolute) (lib.ts:116) or the direct fs.rename/fs.readFile call (index.ts:634 for move_file).

One nuance worth flagging: this looks like a known limitation rather than an oversight. path-validation.test.ts already has a test for exactly this class ("handles unicode characters in paths", added in d00c60d) asserting that a decomposed path does not match an allowed directory (comment: "not normalized"). That test only covers the isPathWithinAllowedDirectories security check, though, not the OS-level filename lookup that's actually failing here, so the gap this issue reports hasn't been covered.

There's also an open PR touching this same area, #3238 ("Add UTF-8 encoding and Unicode normalization for umlauts and symlinks"). It NFC-normalizes inside normalizePath(), which only feeds the security check; the value actually passed to fs.realpath/fs.rename/fs.readFile is absolute (the caller's original string) or fs.realpath's own return, neither of which goes through that normalization. So as written, #3238 would not fix this specific ENOENT, worth knowing since it's easy to assume the two issues are the same fix.

[KXHXK]

I'd like to work on this. I plan to keep the current lexical and realpath-based allowed-directory checks intact, and only fall back after ENOENT to resolving canonically equivalent (NFC/NFD) directory entries component by component. The fallback will reject ambiguous matches and re-check each resolved path before use. I'll cover existing files, normalized parent directories for new destinations, ambiguity, and boundary preservation with focused tests.

[yun520-1]

Non-ASCII path failures in move_file are a boundary-encoding bug: the file system handles the bytes fine (the file exists on disk with those characters), but the server layer mangles or rejects the path before it reaches the filesystem. The data is not the problem; the transport is.

The standard fix is to avoid re-encoding entirely — use the path as an opaque byte sequence end-to-end. If the protocol layer requires UTF-8 (JSON), then the JSON layer must be UTF-8-clean at both ends: the server should accept UTF-8, normalize to NFC once, and pass the bytes through without re-encoding. The failure mode to watch is any layer that assumes ASCII or re-encodes (e.g. a surrogate-escape loss, or a locale-dependent codec).

The test: move_file with a path containing œ, é, 中文, emoji — assert the move succeeds and the destination path round-trips byte-identical. That test would currently fail, and it should be part of the server contract: file-system servers must be encoding-agnostic, because the filesystem itself is.