fix(filesystem): resolve symlinked allowed directories to both forms

[wingding12]

Summary

Fixes #3253

Problem
On macOS, /tmp is a symlink to /private/tmp. When users specify /tmp as an allowed directory:

1. Server startup resolves /tmp to /private/tmp and stores only /private/tmp in allowedDirectories
2. When user requests /tmp/file.txt, the initial validation check fails because /tmp doesn't match /private/tmp
3. User gets "Access denied - path outside allowed directories" error

Solution
Store both the original normalized path andthe resolved path in allowedDirectories. This allows users to access files through either form:

• /tmp/file.txt matches /tmp in allowedDirectories
• /private/tmp/file.txt matches /private/tmp in allowedDirectories

Changes

• src/filesystem/index.ts: Modified allowed directory initialization to store both original and resolved paths when they differ
• src/filesystem/__tests__/path-validation.test.ts: Added test for the symlink behavior

Tests

• Added new test "allows paths through both original and resolved symlink directories"
• Verified fix works on macOS by observing both paths in allowedDirectories output

Reproduction

Before fix:

npx -y @modelcontextprotocol/server-filesystem /tmp
# Then request /tmp/test.txt -> REJECTED

After fix:

npx -y @modelcontextprotocol/server-filesystem /tmp
# Server logs: allowed directories: ['/tmp', '/private/tmp']
# Then request /tmp/test.txt -> ACCEPTED

[olaservo]

Review: APPROVE with suggestions

Correct fix for a real macOS usability bug. The approach of storing both the original symlink path and the resolved realpath in allowedDirectories is sound and security-neutral.

Bug analysis

The root cause is in validatePath() (lib.ts:108-111): it checks the lexically-normalized request path against allowedDirectories before calling fs.realpath(). When startup only stores the resolved form (/private/tmp), a request for /tmp/file.txt fails the pre-realpath gate and never reaches the second check.

Storing both forms fixes this cleanly at the source — the startup resolution step — without touching the runtime validation logic.

Verified

• validatePath() pre-realpath gating (lib.ts:108-111) confirmed
• isPathWithinAllowedDirectories is pure sync prefix-match, no fs I/O
• normalizePath is purely lexical
• Security properties unchanged: both stored paths resolve to the same physical directory; symlink-target validation in validatePath() remains intact
• No conflict with #3229, #3238, or #3205

Suggestions (non-blocking)

1. Integration test gap: The test in path-validation.test.ts manually constructs allowedDirsWithBoth — it tests isPathWithinAllowedDirectories given correct input, but doesn't verify the startup code in index.ts actually produces both forms. Consider adding a symlink case to startup-validation.test.ts that spawns the server with a symlinked directory argument.

2. Code comment on catch block: When a directory doesn't exist at startup, only the unresolved path is stored. If it later appears as a symlink, the mismatch could recur for that dir. A brief comment noting this acceptable tradeoff would help future maintainers.

---

Disclosure: This review was conducted with assistance from Claude Code (claude-opus-4-6). All claims were verified against the source files.