# Reported issues for Desktop Commander

Pod holds 24 of 181 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [Desktop Commander](/mcp/desktop-commander-2).

## Most discussed

### [feat] A way to remotely use DesktopCommander MCP on local net

Let's say I want to start an instance of DesktopCommander MCP on my local machine and then connect to it from my other local machine, how can I do that? The config below only allows to access on localhost itself which is not convenient in all use cases. Can we use `Streamable HTTP`? Couldn't find any clue in docs, sorry.

So along side of this,
```
{
  "mcpServers": {
    "desktop-commander": {
      "command": "npx",
      "args": ["-y", "@wonderwhy-er/desktop-commander@latest"]
    }
  }
}
```

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/617) · 2026-07-31 · open · external user · 18 comments

### ACPCodex binary path mismatch causes npx fallback, EPIPE and initSession timeout

Environment:

* Desktop Commander App: 1.8.3
* DesktopCommanderMCP package: 0.2.41
* Windows 11
* CoworkVMService running as LocalSystem

Problem:
Desktop Commander searches for `codex-acp.exe` at:

`app.asar.unpacked/dist-ts/node_modules/@zed-industries/...`

but the binary is actually installed at:

`app.asar.unpacked/node_modules/@zed-industries/...`

As a result:

* ACPCodex binary is reported as missing
* DC falls back to `npx`
* `npx` starts under `C:\Windows\SysWOW64`
* child process imme

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/475) · 2026-05-14 · closed · external user · 15 comments

### Desktop Commander MCP + Claude Desktop stopped working out of the blue - Any ideas?

Hello everyone,

I've been using Claude Desktop with Desktop Commander MCP with great success over the last few months, but this morning it simply stopped working. At first, I thought it was something wrong with Claude, but we've been troubleshooting it a bit and I think the issue is on my end somewhere.

The problem: Tool calls randomly fail to reach Desktop Commander. Some work, others just vanish - they never even appear in DC's MCP logs. When commands do arrive, DC responds in <100ms, so it'

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/326) · 2026-02-01 · closed · external user · 12 comments

### Claude Desktop extension submission follow-ups

Hello from Anthropic! Thanks for submitting this to our desktop extension registry; we're excited about your submission. We have a few follow-up requests.

Welcome feedback to understand which of these is feasible / acceptable within the desired functionality of this extension.

### Must Fix

- Add destructive operation annotations to all modifying tools
- Provide clear privacy policy explaining data collection
  - Because you collect usage data that you transmit to GA, we ought to provide some 

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/242) · 2025-09-16 · open · external user · 11 comments

### [Error] Failed to call tool get_file_info: TypeError: Cannot convert undefined or null to object

Hi, I'm having some issues with the latest version of Desktop-Commander when trying to read files from a directory. I've attached a screenshot.
Disabling or enabling the antivirus doesn't fix the issue. Running the program as administrator doesn't help either.

<img width="512" height="170" alt="Image" src="https://github.com/user-attachments/assets/74251659-b1a8-40ff-bfe0-65fff922c3b1" />

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/191) · 2025-07-23 · closed · external user · 28 comments

### Stuck while trying to read any dir inside /Users/myUser/a-dir in MacOS Sonoma

I added the MCP via NPX and the tools are correctly appearing in Claude Desktop. But When trying some as simple as a 

```
/DIR/PATH/
List and classify the files in the dir
```

Claude just hangs and after a while it aborts trying to execute another command named lis_directories_allowed or something like that.

![Image](https://github.com/user-attachments/assets/a86d3abe-6828-4ba5-8548-b5de5702209b)

Here is the Claude Desktop Config

```json
{
  "globalShortcut": "Alt+Space",
  "mcpServers": {

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/39) · 2025-03-30 · open · external user · 12 comments

### Errors on startup on mac

When launching on my mac, get json parse errors and logs like this:

2025-03-20T13:41:55.908Z [desktop-commander] [error] Unexpected token 'W', "Watching /"... is not valid JSON {"context":"connection","stack":"SyntaxError: Unexpected token 'W', \"Watching /\"... is not valid JSON\n    at JSON.parse (<anonymous>)\n    at EPe (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.js:82:189)\n    at SPe.readMessage (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/11) · 2025-03-20 · closed · external user · 14 comments

### Can I config allowed paths?

Great Project!
I'm wondering how can I pass the allowed paths for desktop-commander? Maybe like `mcp/filesystem`?

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/7) · 2025-03-11 · closed · external user · 14 comments

## Most recent

### Improve OpenAI / ChatGPT compatibility

Treat OpenAI/ChatGPT as a first-class tested MCP client so runtime/schema changes don't regress it.

```text
client: openai-mcp
test: tool schemas, optional params, side effects/retries, tokenizer config
```

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/664) · 2026-08-27 · open · external user · 0 comments

### Scoped command permissions / per-directory command allowlist

Allow a blocked command only inside selected directories.

```json
{
  "commandScopes": {
    "Remove-Item": ["C:\\Users\\me\\work"]
  }
}
```

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/663) · 2026-08-27 · open · external user · 0 comments

### list_processes returns garbled output on Windows — command name always empty, CPU/Memory fields show wrong data

**Environment:** Windows 11, Desktop Commander v0.2.46 (installed as a Claude Desktop Extension), Claude Desktop 1.37937.3.0

**Description:**

On Windows, `list_processes` returns output like this for every single process, regardless of what's actually running:

```
PID: 4, Command: , CPU: Services, Memory: 0
PID: 972, Command: , CPU: Services, Memory: 0
PID: 1200, Command: , CPU: Console, Memory: 1
```

The command name is always empty, and the CPU/Memory columns contain garbage ("Services", "

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/662) · 2026-08-27 · open · external user · 1 comment

### [Remote MCP] Device is online and ping/list_devices work, but first start_process fails; persisted session forces re-auth

## Summary

Remote Desktop Commander 0.2.47 can be freshly paired and reaches `Channel subscribed` / `Device ready`. Remote meta calls such as `ping` and `list_devices` work, but the first real shell execution through `start_process` fails at the ChatGPT/Remote MCP tool layer even for a trivial command.

There is a second reproducible symptom: after stopping and restarting `desktop-commander remote`, the client logs `Found persisted session for device ...` but immediately starts a new device aut

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/661) · 2026-08-26 · open · external user · 0 comments

### Remote 0.2.47: broadcast_v1 intermittently drops individual tool calls while device remains online

## Summary

Remote Desktop Commander `0.2.47` intermittently drops individual remote tool calls when used from ChatGPT over `broadcast_v1`.

The important distinction from a normal command timeout is that the failed request never reaches the remote Desktop Commander process at all. Successful requests immediately before and after the failure are logged by the remote agent and complete in roughly 10 ms, while the missing request is completely absent from the agent journal.

The device remains onl

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/660) · 2026-08-26 · open · external user · 3 comments

### Remote 0.2.47: read_multiple_files with larger multi-image response closes MCP connection

## Summary

On Remote Desktop Commander `0.2.47` on Windows, `read_multiple_files` reproducibly closes the local MCP stdio connection when the combined image response becomes sufficiently large.

The individual PNG files are valid and can all be read separately. Smaller multi-image batches also work. Increasing the same batch from 4 images to 5 images reproducibly causes:

```text
MCP error -32000: Connection closed
```

After this happens, subsequent execution tools return:

```text
Not connect

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/658) · 2026-08-26 · open · external user · 1 comment

### Windows: plugin launch uses npx @latest, so it reinstalls on every start and never beats the 120s connect timeout

## Summary

The Claude Desktop **plugin** (`plugins/claude/.claude-plugin/plugin.json`) launches the server as:

```json
"mcpServers": {
  "desktop-commander": {
    "command": "npx",
    "args": ["-y", "@wonderwhy-er/desktop-commander@latest"]
  }
}
```

Because of `@latest`, npm re-resolves the version on **every** launch. As soon as the npx-cached copy is one release behind, npx reinstalls the whole dependency tree *before* the server can answer `initialize`. On my machine that install takes 

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/655) · 2026-08-25 · open · external user · 1 comment

### MCP spec conformance: 5 requirement(s) violated (via @hasmcp/mcp-spec-test) — spec 2025-11-25

Companion issue to the 2026-07-28 report filed separately (counts differ per revision, so filing individually rather than merging). When Desktop Commander MCP is tested against the 2025-11-25 revision, a version-less request and an unsupported-version handshake both get "server exited" instead of a response, and the official-SDK client can't complete initialize or list tools — 5 requirements violated, with 13 further checks unverifiable. As with the 2026-07-28 report, this may be a slow/flaky st

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/654) · 2026-08-24 · open · external user · 0 comments

### MCP spec conformance: 10 requirement(s) violated (via @hasmcp/mcp-spec-test) — spec 2026-07-28

When Desktop Commander MCP (via `npx -y @wonderwhy-er/desktop-commander@latest`) is tested against the 2026-07-28 MCP spec revision with `@hasmcp/mcp-spec-test`, the initial `server/discover` and version-less requests never get a response within the 10s timeout, and the connection is later reported closed. The package does install and run (the whole test took ~27s, well past typical MCP handshake latency), so this may be a slow first-run/cold-start rather than a hard crash, but it exceeds what a

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/653) · 2026-08-24 · open · external user · 0 comments

### Remote channel repeatedly goes offline with "IncreaseConnectionPool" after socket 1006 disconnects

## Summary

Remote Desktop Commander repeatedly becomes unreachable even though the Ubuntu machine and the `desktop-commander remote` process continue running normally.

The device may temporarily appear as `online`, but the remote channel itself is not usable. Restarting the remote agent restores connectivity temporarily, but the same failure can return after several minutes.

The most notable error is:

```text
IncreaseConnectionPool: Please increase your connection pool size
```

This error a

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/652) · 2026-08-24 · open · external user · 2 comments

### Server startup takes 8-12s; 71% is module resolution (1,044 internalModuleStat calls)

## Summary

Cold start of the MCP server takes 8.4 to 12.2 seconds before it can answer an `initialize` request. CPU profiling shows roughly 71% of that is Node resolving and reading modules from disk, not doing any work.

This matters because MCP clients spawn their own instance per session. On a client with a ~10s startup timeout the handshake intermittently loses the race and the server is reported as failing to start.

## Environment

- desktop-commander 0.2.46 (Desktop Extension build)
- No

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/650) · 2026-08-22 · open · external user · 0 comments

### The OAuth authorization issue previously reported in #601 appears to have returned.

Steps to reproduce:
1)Open Desktop Commander in ChatGPT.
2)Start the authorization/connect flow.
3)Continue to the Desktop Commander OAuth authorization page.
4)Authorization fails immediately with:
{ "error": "server_error", "error_description": "Failed to process authorization request: Failed to create OAuth session"}.

Prior to the current failure, Desktop Commander had been randomly losing authorization roughly every 10–15 hours. Re-authorization would temporarily restore access. This may be

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/646) · 2026-08-21 · closed · external user · 2 comments

### Slow/inconsistent initialize response causes Cowork/Code shared-pool timeout

<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Desktop Commander MCP — Slow/Inconsistent <code>initialize</code> Handshake Causing Cowork/Code Timeout</h1>
<h2>Summary</h2>
<p>Desktop Commander (installed via Claude Desktop's Extensions/.dxt system) intermittently takes 45–60+ seconds to respond to the MCP <code>initialize</code> request on startup, instead of the ~5 seconds seen on a clean launch. When the delay exceeds Cowork/Code's shared-pool startup timeout (~55–60s), the se

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/645) · 2026-08-21 · open · external user · 2 comments

### Linux/systemd: start_process background jobs die when Desktop Commander restarts

## Summary

On Linux, when the Desktop Commander remote device runs as a systemd service,
commands launched through `start_process` normally remain in the service's
cgroup. A service stop or restart therefore terminates those commands and their
descendants under systemd's control-group kill semantics.

That cleanup policy is a safe default for controller-owned work. The surprising
part is the user-facing contract: Desktop Commander advertises timeout and
"background execution" for long-running c

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/644) · 2026-08-20 · open · external user · 0 comments

### start_search docs misstate filename and literalSearch matching semantics

## Summary

`start_search` currently publishes a pattern-matching contract that implies `literalSearch=false` means regex matching generally. That is not true for all search modes.

Verified independently on current `main` / v0.2.47 (`9bd8422`).

## Reproduction

With files:

- `target-alpha.txt`
- `target-beta.txt`
- `target-gamma.log`
- `notes.txt`

File-name searches behave as follows:

- `searchType="files", pattern="target-.*\\.txt$", literalSearch=false` -> 0 results
- `searchType="files",

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/641) · 2026-08-19 · open · external user · 0 comments

### Cold-start initialize takes 24 to 26 s while a sibling extension on the same host, same runtime, same instant answers in 1.7 to 3.8 s (v0.2.46, Claude Desktop, Windows 11)

<html>
<body>
<!--StartFragment--><h2 dir="ltr">Summary</h2>

<p dir="ltr">Desktop Commander's <code>initialize</code> handshake takes 24 to 26 s on a cold start. Two
other MCP extensions on the same machine, spawned by the same Claude Desktop
process within milliseconds of it, complete theirs in 1.7 to 10.4 s. The closest
comparator, which shares Desktop Commander's runtime and its startup path
exactly, answers in 1.7 and 3.8 s.</p>

<p dir="ltr">This is not a machine-wide stall and not endpoin

[Read the thread](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/635) · 2026-08-19 · open · external user · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/wonderwhy-er/DesktopCommanderMCP/issues).