remote: device startup fails with -32603 "Unexpected end of JSON input" when a second DC instance writes config.json; online status is a false green

Summary

Running npx @wonderwhy-er/desktop-commander@latest remote on a machine that already runs a Desktop Commander MCP instance (served by Claude Desktop) fails at startup — intermittently, but reproducibly. Three related problems, all rooted in ~/.claude-server-commander/config.json being shared between instances and written non-atomically.

Environment: Windows 11, node v24.14.0, DC 0.2.50 via npx remote running alongside DC 0.2.46 served by Claude Desktop.

1. Startup is fatal when config.json is read mid-write

Starting MCP Device...
 - Connecting to Local Desktop Commander MCP using: ...\dist\index.js
 - Failed to connect to Desktop Commander MCP: McpError: MCP error -32603: Unexpected end of JSON input
 - Device startup failed: MCP error -32603: Unexpected end of JSON input
Shutting down device...

Observed on 2 of 3 launches. config.json is valid at rest (verified with a JSON parse), but it is rewritten on every tool call to update usageStats, and that write is not atomic — I watched the file change from 1828 B to 1341 B while both instances were live. A concurrent reader gets a truncated buffer.

Natural experiment: the two launches made while the other DC instance was actively serving tool calls failed as above; the single launch made during a quiet window came up and has been serving commands since. This was not a designed experiment — I could not get a clean repro window — so treat it as strong correlation, not proof.

Suggested fix: write config.json atomically (temp file + rename), and make readConfigFromDisk retry or tolerate a partial read instead of throwing.

2. Non-fatal flood of the same error

When the device does start, it logs, continuously and by the hundreds of lines:

Failed to reload config: SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at ConfigManager.readConfigFromDisk (.../dist/config-manager.js:167:29)
    at async ConfigManager.reloadConfigFromDisk (.../dist/config-manager.js:279:28)

Same root cause; it drowns every other log line.

3. list_devices reports status: "online" for a device that cannot receive commands

On the first successful registration, the transport capability failed to register:

[DEBUG] Failed to update transport capability: TypeError: fetch failed

The process still printed Device ready, and list_devices returned status: "online" with a current last_seen. But every tool call came back with:

This Desktop Commander device has no live connection and cannot receive commands right now.

Only the metadata tools the server answers itself (who_am_i, list_devices) worked. After restarting the process, capabilities gained transport_broadcast_v1: true and commands began executing normally.

Suggested fix: do not mark the device online until the transport capability is registered, or expose that state in list_devices so a caller can distinguish "registered" from "reachable". As it stands, status: "online" is a false green — the one signal a caller has to decide whether the device is usable does not track usability.