fix(filesystem): normalize paths to NFC for Unicode consistency#4016
Closed
Will-hxw wants to merge 3 commits intomodelcontextprotocol:mainfrom
Closed
fix(filesystem): normalize paths to NFC for Unicode consistency#4016Will-hxw wants to merge 3 commits intomodelcontextprotocol:mainfrom
Will-hxw wants to merge 3 commits intomodelcontextprotocol:mainfrom
Conversation
The roots/list_changed handler was unconditionally replacing allowedDirectories with MCP roots, even when CLI directories were set. Adding the same guard as oninitialized to prevent MCP roots from overriding CLI directories when both are present.
macOS and Linux filesystems use different Unicode normalizations:
- macOS APFS stores filenames in NFD (decomposed)
- Linux typically uses NFC (composed)
This caused path validation to fail when:
- A directory name contains characters like dakuten (シ/ジ) or
non-breaking spaces (common in Japanese directory names on macOS)
- Screenshot files created by macOS system dialogs
- Any path where client-supplied NFC path doesn't match NFD-stored path
The fix applies .normalize('NFC') to both the absolutePath and allowed
directory paths after path.resolve.normalize(), ensuring consistent
comparison regardless of the Unicode form used in the filesystem.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Author
|
The test assertion at line 204 expects decomposed paths not to match, but the fix intentionally normalizes both paths to NFC so they match. The test needs updating: either change toBe(false) to toBe(true) or split into a separate test case verifying that genuinely different paths still do not match. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Apply
.normalize("NFC")to path strings inisPathWithinAllowedDirectories()so that paths stored in different Unicode normalizations (NFD on macOS APFS, NFC typical) are compared correctly.Problem
macOS APFS stores filenames using NFD (decomposed) Unicode normalization, while most clients supply NFC (composed) paths. This causes
isPathWithinAllowedDirectories()to returnfalsefor valid paths when the normalization forms differ — a directory named01_ナレッジベース(containing a dakuten/combining character) would be inaccessible even though it appears in the allowed list.The same issue affects macOS system-generated screenshot files whose names contain non-breaking spaces (U+00A0) in different forms.
Fix
After
path.resolve(path.normalize(...)), apply.normalize("NFC")to both the input path and each allowed directory path before comparison. This converts all paths to the same Unicode normalization form regardless of how they're stored on disk.Validation
npm run build)handles unicode characters in pathswhich now passes with the fixRelated