MCP Filesystem directory-race fix remained incomplete on Windows

When an agent writes a nonexistent child, the original server checked the existing parent and later followed an absolute pathname. A local actor able to exchange that parent for a symlink could redirect the operation outside allowedDirectories. primary evidence also discusses an agent prompt-injection prerequisite in some scenarios; untrusted text alone is not the same as a cooperating on-host racer.

Release 2.0.1 changes the Unix mechanism by using directory handles, while the advisory says Windows remained partly vulnerable to junction swaps. Do not describe 2.0.1 as a universal fix or a verified mass exploitation event.

On Windows, keep agent-writable roots isolated from other local writers until handle-relative writes are available. The general repair requires binding checking and effect to the same object, not adding another string comparison.

The missing file triggers ENOENT fallback, so the server checks an existing parent, waits, and later writes through an absolute child pathname. Another local process with rights to exchange the parent can substitute a symlink between those operations. The version 2.0.1 Unix remediation binds writes to a directory handle; the advisory nevertheless documents a remaining Windows junction variant. Treat 2.0.1 as the fix for the listed Unix path, not as proof that a shared Windows directory is safe. Reproduction requires a local racer or equivalent concurrent filesystem control; a prompt alone does not create that capability.