[BUG] Filesystem MCP: create_file reports success but file never persists (related to closed #15060, still reproducible)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Context — related to a previously closed issue
This closely matches #15060 ("[BUG] Filesystem Connector Write Operations
Failing Silently"), which was closed as "not planned" without a fix. That
issue is now locked for comments, so filing fresh with additional, more
precise evidence.

What's wrong
The filesystem MCP server's create_file tool consistently reports success
("File created successfully") when creating a new file, but the file
does not actually exist afterward — confirmed via immediate read_text_file
on the same path returning ENOENT.

A more precise distinction than the original report
#15060 described "the write pathway" as broadly broken. In my reproduction,
it's narrower and more specific:

• Editing an EXISTING file (edit_file / str_replace): 100% reliable, every

time, across a multi-hour session.

• Reading files: 100% reliable.
• Creating a NEW file (create_file): fails silently and consistently.

Reproduced well over a dozen times, in multiple different folders under
the same Synology Drive-synced mount.

Persistence across a full app relaunch
Not a stale-connection issue. Quit and relaunched Claude Desktop entirely
mid-session; the exact same create-fails-silently behavior reproduced
immediately afterward on a fresh MCP connection. Reads and edits to
existing files worked correctly post-relaunch; new-file creation did not.

One partial data point on possible cause
Pulled the actual MCP server log from
%APPDATA%\Claude\logs\mcp-server-filesystem.log and found a genuine
server crash/reconnect cycle during the same session:
[timestamp] Server transport closed unexpectedly, process exiting early
[timestamp] [error] Server disconnected
...15 minutes later...
[timestamp] Initializing server... (reconnect)
This only partially correlates — some write failures occurred well before
this specific crash, and the create-vs-edit asymmetry persisted after
reconnecting too, so this crash likely isn't the sole cause.

Environment

• Claude Desktop, Windows
• Filesystem MCP server (npx @modelcontextprotocol/server-filesystem)
• Synology Drive-synced directories (multiple, tested)

Impact
Makes create_file effectively unusable — every new file requires manual
paste as a workaround, with no reliable way to detect the silent failure
other than immediately re-reading the path after every create.

What Should Happen?

When create_file is called with a new file path, the file should be
created on disk exactly as specified, and the tool's success response
should only be returned once that write is actually confirmed to have
completed. If the write genuinely fails for any reason (permissions,
sync conflict, disk issue, etc.), the tool should return an error
indicating failure — not a success message — so the difference between
"file created" and "file silently failed to create" is never ambiguous
to the user or to Claude.

Error Messages/Logs

Steps to Reproduce

1. In an active Claude Desktop conversation with the filesystem MCP

server connected, ask Claude to create a new file that does not
already exist, e.g.:
"Create a file called notes.md with the text 'test' in it"
at a path such as C:\Users\<user>\SynologyDrive\<some-folder>\notes.md

1. Claude calls create_file and reports success

("File created successfully").

1. Immediately ask Claude to read the same file back:

"Read notes.md and confirm its contents"

1. Claude calls read_text_file on the same path and receives:

ENOENT: no such file or directory, open '<path>\notes.md'
— despite step 2 having reported success moments earlier.

1. Repeat steps 1-4 with edit_file/str_replace on a file that

ALREADY exists instead of create_file on a new one — this
consistently succeeds and persists correctly, every time.

1. Optionally: fully quit and relaunch Claude Desktop, then repeat

steps 1-4 again. The same create-fails-silently behavior
reproduces immediately on the fresh session.

Reproduced consistently (10+ times) across multiple different
Synology Drive-synced folders during a single multi-hour session.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.96 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Note: this template's fields are oriented toward Claude Code CLI usage.
The actual bug reported here occurred entirely within Claude Desktop's
chat interface, using its built-in filesystem MCP server connector — not
via the Claude Code CLI tool or a terminal session. Claude Code version
above is included for environment context only; it was not directly
involved in reproducing this bug.