Desktop Commander MCP: terminal control and diff editing for Claude, installed with one npx command

What Desktop Commander MCP solves, and for whom

Most MCP filesystem servers stop at reading and writing whole files. Desktop Commander MCP, published as @wonderwhy-er/desktop-commander, adds the layer that Claude Desktop otherwise lacks: running terminal commands, managing the processes those commands leave behind, and editing files through targeted replacements instead of full rewrites. The README describes it as built on top of the MCP Filesystem Server to provide additional search and replace file editing capabilities.

The intended user is someone who already has a host client subscription and wants the agent to work on a real machine: run a build, tail a log, inspect a CSV, edit a config file. The README frames the economics directly, saying it works while using host client subscriptions instead of API token costs. That is the practical pitch. You are not paying per tool call; you are extending a client you already pay for.

It is a general developer tool, not a narrow one. The feature list covers Excel, PDF and DOCX handling, in-memory execution of Python, Node.js and R, recursive directory listing, and process management. That breadth is the appeal and also the reason the safety section matters more than it would for a read-only server.

How the server is put together: stdio, ripgrep and surgical edits

The repository is a TypeScript project (package.json declares "type": "module" and engines.node >=18.0.0) that ships a compiled entry point at dist/index.js. The Dockerfile shows the runtime shape plainly: it copies package.json, runs npm install --ignore-scripts, then npm rebuild @vscode/ripgrep to fetch the search binary, copies the source, runs npm run build, and starts with node dist/index.js. There is no exposed port in that Dockerfile, so the default transport is stdio, driven by the client rather than by a network listener.

Search is not hand-rolled. The README attributes recursive code and text search to vscode-ripgrep, and the build step rebuilds that package because its binary downloads outside the normal install. File editing comes in two modes: surgical text replacements for small changes, and full file rewrites for major changes, with pattern-based replacements and multiple file support.

Two mechanisms are worth calling out because they shape how the agent behaves. First, command output is paginated: the README lists process output pagination with offset and length controls to prevent context overflow, and a negative offset for reading from the end of a file like Unix tail. Second, long-running commands are not killed at a fixed timeout. The README documents interactive process control, session management and background execution, so the agent can list and kill processes it started. The repository also carries a local tool-call history: calls and arguments are recorded on the machine, retrievable through get_recent_tool_calls, with size-based rotation to keep the files bounded.

Installing Desktop Commander MCP and running a first command

The README gives several installation paths for Claude Desktop. The shortest is the npx setup command, which requires Node.js and installs the server into your client configuration. The README notes that options 1, 2, 3, 4 and 6 have automatic updates, while option 5 requires manual updates, and that you should restart Claude if it is running.

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

After the setup script finishes, restart Claude. The README states that with the npx option the server automatically updates when you restart Claude, and that re-running the same setup command performs a manual update. A debug variant exists for attaching the Node.js inspector, and a flag to skip onboarding prompts:

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

The package also exposes a remove binary, so uninstalling does not require hand-editing JSON:

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

On macOS the README offers a shell installer that handles dependencies and configuration, including installing Node.js if it is missing:

curl -fsSL https://raw.githubusercontent.com/wonderwhy-er/DesktopCommanderMCP/refs/heads/main/install.sh | bash

For a first real use, ask the client to run something with observable output, such as listing a directory recursively or running a test command, then ask it to read the tail of a log file. The point of the negative offset and pagination controls is that you can retrieve the end of a large file without pulling the whole thing into context. If the client shows nothing after setup, the README's own ordering is the thing to check: the server must be configured in the client and the client restarted.

The safety model is a blocklist, not a sandbox

This is the part to read before installing. The README lists safety guardrails and immediately qualifies them: not a sandbox, see SECURITY.md. The three items named are symlink traversal prevention on file operations, a command blocklist for accidental execution, and Docker isolation for complete isolation. A blocklist stops known-bad strings. It does not stop a command that is merely destructive and unfamiliar, and it does not constrain what a process does once it is running.

The README is explicit that the Docker path is the one offering complete isolation, and the repository ships install-docker.sh, install-docker.ps1 and a Dockerfile for it. If your threat model includes prompt injection from a file the agent reads, the local stdio install is the wrong configuration. That is not a flaw in the project so much as a boundary the maintainers state themselves.

Two smaller constraints are worth knowing. The postinstall script in package.json runs track-installation.js, so installing the package contacts a tracking endpoint unless scripts are ignored; the Dockerfile deliberately uses npm install --ignore-scripts. And the local tool-call history means tool arguments are written to disk on the machine running the server. If commands contain secrets, that history is a place they can land.

Desktop Commander MCP versus the plain filesystem server

The natural comparison is the MCP Filesystem Server this project builds on. That server reads, writes and lists files, and its scope ends there. Desktop Commander MCP keeps those operations and adds terminal execution, process listing and killing, session management for long-running commands, in-memory code execution, and the search-and-replace editing layer. The difference in practice is that a filesystem server can rewrite a file but cannot run the test that tells you the rewrite was correct.

A second comparison the search data keeps raising is Desktop Commander MCP versus Claude Code. The distinction visible in the README is architectural rather than feature-by-feature: Desktop Commander is an MCP server plugged into a host client such as Claude Desktop, so it inherits that client's subscription and works inside its chat interface. Claude Code is its own terminal agent. The README's own framing supports this reading: the project positions itself as extending a client you already use, and separately offers a Desktop Commander App (described as beta, for macOS and Windows) for people who want a dedicated interface with model choice and live file previews.

The trade-off is real. A client-hosted server gives you the UI, the subscription and the file preview panel for free. It also means your capabilities are bounded by what the client exposes, and you are running an agent with shell access inside a chat window, which is a different risk posture from a purpose-built CLI with its own permission prompts.

Maintenance, releases and what the MIT licence leaves to you

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v0.2.50 on 2026-09-09, v0.2.48 on 2026-09-02, and v0.2.44 on 2026-07-09. The package version in package.json matches the latest release tag, which suggests the release process keeps the manifest in step; the repository includes a sync-version script and bump targets for that purpose.

Upgrade cost is low on the recommended paths. Because the npx install auto-updates when Claude restarts, you do not schedule upgrades; you restart the client. The README warns that one of the six installation options requires manual updates, so if you chose that path your upgrade story is different. The Docker path rebuilds from the Dockerfile and is a separate maintenance stream.

Licensing is MIT, declared in both LICENSE and package.json. That permits commercial use and modification. It also means no warranty, and this is a tool that executes shell commands on your machine, so the practical implication is that the safety burden sits with you rather than with the licence terms. Nothing here is legal advice; if you redistribute a modified build, read the MIT text yourself.

Editorial conclusion

Adopt Desktop Commander MCP if you already run Claude Desktop or another MCP client and want terminal execution plus surgical file edits without paying per-token API costs for the tool layer; the npx setup path is one command and updates on restart. Do not adopt it if you need a sandbox: the README links SECURITY.md and says the guardrails are a blocklist and symlink checks, not isolation, so untrusted prompts plus an open terminal is the wrong combination. Before rollout, verify on your own machine that `npx @wonderwhy-er/desktop-commander@latest setup` writes the config your client reads, and read SECURITY.md for the command blocklist and the Docker isolation option.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wonderwhy-er/DesktopCommanderMCP on GitHub