Filesystem MCP server write_file intermittently hangs ~4min then succeeds instantly on identical retry

### What happened?

`write_file` calls to the local filesystem MCP server (bundled/connected `@modelcontextprotocol/server-filesystem`, or equivalent) intermittently hang for ~4 minutes with no error, timeout, or partial write — then succeed instantly on an identical retry (same path, same content, same size). This happened multiple times within a single session, not as a one-off.

When it hangs, the client eventually surfaces:

> "No result received from the Claude Desktop app after waiting 4 minutes. The local MCP server providing this tool may be unresponsive, crashed, or not running."

No partial file is created during the hang (verified via `list_directory` / `get_file_info` — file absent or unchanged, no stale timestamp).

### What did you expect to happen?

`write_file` should either succeed within a reasonable time, or fail fast with a clear, actionable error (e.g. "server busy," "connection reset," a JSON-RPC error) rather than silently hanging for the entire client-side timeout window with zero diagnostic signal in between.

### Steps to reproduce

1. Connect the filesystem MCP server with `write_file` access to a local directory.
2. From a Claude conversation, call `write_file` to write a markdown file (~9–14 KB, standard prose + tables + Unicode characters) to a path in the allowed directory.
3. Observe: the call hangs; after ~4 minutes, the client returns:
> "No result received from the Claude Desktop app after waiting 4 minutes. The local MCP server providing this tool may be unresponsive, crashed, or not running."
4. Verify via `list_directory`/`get_file_info` that the file was **not** written (no partial write, no stale timestamp).
5. Retry the exact same `write_file` call (identical path, identical content, no changes) — succeeds immediately.
6. This sequence (hang → timeout message → instant success on retry) recurred at least twice more in the same session, on different files, at different times.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

filesystem

### Error messages or logs

```shell

```

### Additional context

I isolated several variables across retries against the same allowed directory, none of which correlated with the hang:

SELinux: disabled entirely; `ausearch -m avc` and `journalctl -t setroubleshoot` both returned no matches for the relevant time window. Ruled out as a permissions/policy block.
Payload size: a ~10 KB pure-ASCII payload and a ~14 KB Markdown payload (headers, tables, bullets) both wrote instantly in isolation. Hangs occurred on payloads in the same 9–14 KB range that also sometimes succeeded — size alone doesn't predict it.
Content type: plain ASCII, dense Unicode (em dashes, arrows, multiplication signs, curly quotes), and full Markdown syntax all wrote successfully in isolation tests at comparable sizes.
File extension: both `.txt` and `.md` targets wrote successfully in isolation; not extension-specific.
Path: hangs and successes both occurred against the exact same target path, ruling out a path-specific permission or resolution issue.

The only consistent pattern across every occurrence: hang → 4-minute timeout → identical retry succeeds immediately. This points to something transient in the local Claude Desktop ↔ MCP server bridge (a stdio pipe stall, an event-loop block in the Node server process, or brief resource contention) rather than a deterministic block tied to any property of the request.
No error/warning/stderr was visible in the conversation UI during the hang beyond the eventual timeout message. Happy to attach `mcp-server-filesystem*.log` excerpts from around a hang timestamp if a maintainer confirms where to look — didn't want to guess at log paths without confirmation given they vary by OS.

[mcp-server-filesystem.log](https://github.com/user-attachments/files/29859351/mcp-server-filesystem.log)