Environment
- Desktop Commander 0.2.43, installed as a Claude Desktop extension (
isDXT: true per get_config)
- Claude Desktop on macOS (arm64), bundled Node 24.17.0, Electron 42.5.1
- Client:
claude-ai 0.1.0 (a chat session on claude.ai reaching the local server through the desktop app's remote MCP bridge)
What happens
In a single session, seconds apart:
get_config: responds in under a secondset_config_value (allowedDirectories): responds in under a secondread_file on a denied path: rejected in under a second, as expectedwrite_file (mode rewrite, 2 lines, local path inside allowedDirectories): no response at all. The client gives up at its 4 minute timeout.
Why I think the call never reaches the handler
Three observations from the same minute:
- The target file was never created. A stat immediately afterward returned ENOENT.
usageStats.toolCounts.write_file read 282 before the call and 282 after, while counters for the surrounding successful calls all incremented.~/Library/Logs/Claude/mcp-server-Desktop Commander.log has no tools/call entry for the request.
The server stays healthy: the next get_config answers instantly, so this is not a wedged process.
Since the handler is never entered, this may be a Claude Desktop bridge problem rather than a Desktop Commander one. Filing here first because you see far more claude-ai client traffic than I do. Glad to take it to Anthropic instead if that is your read.
History
Same symptom on 0.2.42 under an npx install (June 2026), also on local ~/GitHub paths, so it is not tied to DXT packaging or to cloud-synced paths. It has recurred across at least three sessions on two versions.
Workaround
start_process with a single non-nested heredoc writes reliably from the same remote session, including a 55 line file written moments after the hang above.
Happy to provide full logs or test a patched build.
Environment
isDXT: trueperget_config)claude-ai 0.1.0(a chat session on claude.ai reaching the local server through the desktop app's remote MCP bridge)What happens
In a single session, seconds apart:
get_config: responds in under a secondset_config_value(allowedDirectories): responds in under a secondread_fileon a denied path: rejected in under a second, as expectedwrite_file(mode rewrite, 2 lines, local path insideallowedDirectories): no response at all. The client gives up at its 4 minute timeout.Why I think the call never reaches the handler
Three observations from the same minute:
usageStats.toolCounts.write_fileread 282 before the call and 282 after, while counters for the surrounding successful calls all incremented.~/Library/Logs/Claude/mcp-server-Desktop Commander.loghas notools/callentry for the request.The server stays healthy: the next
get_configanswers instantly, so this is not a wedged process.Since the handler is never entered, this may be a Claude Desktop bridge problem rather than a Desktop Commander one. Filing here first because you see far more claude-ai client traffic than I do. Glad to take it to Anthropic instead if that is your read.
History
Same symptom on 0.2.42 under an npx install (June 2026), also on local
~/GitHubpaths, so it is not tied to DXT packaging or to cloud-synced paths. It has recurred across at least three sessions on two versions.Workaround
start_processwith a single non-nested heredoc writes reliably from the same remote session, including a 55 line file written moments after the hang above.Happy to provide full logs or test a patched build.