DesktopCommanderMCP

Upgrade **Remote Desktop Commander to 0.2.51 or later**. Version 0.2.51 guards oversized read_multiple_files responses so they do not exceed the MCP stdio buffer, and it fails an in-flight call immediately if the local Desktop Commander child process dies.

Root cause: in @modelcontextprotocol/sdk 1.30.0, StdioClientTransport uses a default **10 MiB read buffer** and closes the transport when a single message exceeds it. Multiple Base64-encoded images can easily cross this limit—for example, ~8.8 MB of source images produced ~11.8 MB of Base64 before JSON overhead.

Workaround for 0.2.47:
1. Read PNG/JPEG files individually or in smaller batches.
2. Keep the combined Base64 payload below 10 MiB; allowing for Base64 and JSON overhead, keep source images conservatively around **7 MB or less per request**.
3. If the client reports Not connected, restart Remote Desktop Commander.
4. Retry with fewer files per read_multiple_files call.

Upgrade the remote agent to Desktop Commander 0.2.51 or newer; the reconnection/connection-pool issue was fixed and confirmed in that release. Stop all existing remote agents, remove duplicate index.js remote/Node processes, then restart with:

npx @wonderwhy-er/desktop-commander@latest remote

To test the fixed release explicitly, use:

npx @wonderwhy-er/desktop-commander@0.2.51 remote

On version 0.2.47, restarting the agent only restores connectivity temporarily. If the error persists after upgrading, especially together with Cloudflare 525 SSL errors, check the network/SSL path and Desktop Commander service status because it may indicate a separate service-capacity or connectivity issue.

The welcome page is Desktop Commander's first-run onboarding and opens only once. To run without it, execute:

npx @wonderwhy-er/desktop-commander@latest setup --no-onboarding

You can also pass --no-onboarding when starting Desktop Commander, or set onboarding_injection: false in its configuration. This prevents the browser window and utm_source analytics request from being triggered during the MCP initialize handshake in headless, IDE, or CI environments.

The vulnerabilities are fixed by the merged production-dependency update, which reduces npm audit --omit=dev findings from 38 to 0. Upgrade to the release containing this fix once published:

npm install -g @wonderwhy-er/desktop-commander@latest

If launched through an MCP client configuration, use:

["-y", "@wonderwhy-er/desktop-commander@latest"]

Then restart the MCP server and verify with:

node --version
npm audit --omit=dev

Node.js **22.12 or newer** is required. Until you upgrade, disable or remove desktop-commander from ChatGPT/MCP configuration to avoid granting unrestricted system access.

Cause: Desktop Commander's read_file leaks the file handle whenever a read stops early at the line budget. readFromStartWithReadline breaks out of its readline loop and calls rl.close(), but readline.Interface.close() does NOT close the underlying fs.createReadStream, so the Node process holds the file open until the server exits. Windows then refuses atomic replace-by-rename (os.replace(), fs.rename(), File.Move(...,true), MoveFileEx with MOVEFILE_REPLACE_EXISTING) from any other process with WinError 5 / EPERM.

Trigger condition (confirmed on 0.2.46–0.2.52, regressed again in 0.3.0): the leak happens only when the read hits break instead of reading to EOF. Example: a 5-line file read with length=5 (or default 1000-line limit on a 1200-line file) leaks the handle; the same file read with length=6 does not. You can verify the lock holder with Windows Restart Manager (look for Desktop Commander's node.exe).

Workarounds:
1. Release existing locks: fully restart Desktop Commander / Claude Desktop (graceful shutdown releases all leaked handles; the file can then be moved/replaced normally).
2. Avoid triggering new leaks: when calling read_file, pass a length larger than the file's total line count so the stream reads to EOF and closes cleanly. Avoid partial reads of large files with the default 1000-line limit.
3. Code fix (for contributors): capture the input ReadStream at all four readline call sites, call stream.destroy() in a finally block, and await the stream's close event before returning; also handle error/abort events on both the input stream and the readline interface.