Desktop Commander MCP: terminal control and file editing for Claude, with a blocklist instead of a sandbox
This is MCP server for Claude that gives it terminal control, file system search and diff file editing capabilities
At a glance
- What is it?
- wonderwhy-er/DesktopCommanderMCP is a TypeScript MCP server that gives an AI client a terminal, file search and diff-style editing. This article covers how it installs, what it can touch, and where its safety claims stop.
- Who is it for?
- Use it if you want one MCP server that lets Claude run long terminal sessions and edit files on your own machine, and you accept that the blocklist is only a guard against accidents. Put it in Docker or on a disposable machine before pointing it at anything you cannot restore, and pin the version if you do not want npx to move it for you.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 13, 2026, and from our analysis. They are not legal advice.
Star history
- wonderwhy-er/DesktopCommanderMCP10,305 ★ · +760
| Repository | 2026-09-11 | 2026-11-13 |
|---|---|---|
| wonderwhy-er/DesktopCommanderMCP | 9.5k | 10.3k |
760 Stars in the last 63 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
It extends the reference filesystem server instead of replacing it
Desktop Commander MCP is described as an MCP server for Claude that gives it terminal control, file system search and diff file editing. It is built on top of the MCP Filesystem Server from the modelcontextprotocol/servers repository, and the extra pieces are search and replace style editing plus process control. The package is published on npm as @wonderwhy-er/desktop-commander, written in TypeScript, and licensed under MIT. The author field in package.json reads Eduards Ruzga.
The pitch in the README is that you work with code and text, run processes and automate tasks while using the subscription of the host client instead of paying API token costs. That means the intelligence and the bill live in whichever client you connect, and this server only supplies the tools. The last push to the repository was on 2 November 2026, and the recent releases are v0.3.1 on 22 October, v0.3.0 on 13 October and v0.2.52 on 29 September, so the project is moving quickly and the version you installed last month may differ from what npx fetches today.
Auto-updating install routes change the version without asking you
For Claude Desktop the README lists six install options, and it states that options 1, 2, 3, 4 and 6 update automatically while option 5 needs manual updates. The first route is the npx one:
npx @wonderwhy-er/desktop-commander@latest setupBecause the command pins @latest, it picks up the newest published build every time Claude restarts. A manual update is the same setup command run again, and removal is `npx @wonderwhy-er/desktop-commander@latest remove`. The setup command takes `--debug`, which enables the Node.js inspector, and `--no-onboarding`, which turns off the prompts shown to new users. The debug variant is:
npx @wonderwhy-er/desktop-commander@latest setup --debugThe macOS bash installer is a one-line pipe into bash:
curl -fsSL https://raw.githubusercontent.com/wonderwhy-er/DesktopCommanderMCP/refs/heads/main/install.sh | bashIt installs Node.js when it is missing, and it follows the main branch of the repository. The cost of every auto-updating route is the same: a tool that can run shell commands on your machine can change its own behaviour between two sessions. If you need a reviewed, fixed version, the manual route is the one that gives it to you. Smithery is the third route, which hands you a key from smithery.ai after you pick Claude Desktop, and the fourth is editing claude_desktop_config.json by hand.
Where the manual config file lives on each operating system
Option 4 asks you to add a desktop-commander entry under mcpServers in claude_desktop_config.json, with npx as the command. The README gives the path per platform: on Mac it is ~/Library/Application Support/Claude/claude_desktop_config.json, on Windows it is %APPDATA%\Claude\claude_desktop_config.json, and on Linux it is ~/.config/Claude/claude_desktop_config.json.
That list is the direct answer to whether the server works on Windows: the config path for Windows is documented, the repository ships an install-docker.ps1 next to install-docker.sh, and the remote device launchers are described as running on macOS, Linux or Windows. The bash installer, by contrast, is labelled as the macOS route, so a Windows user is steered toward npx, Smithery or Docker. Either way, the server still has to be started by an MCP client, so installing it does nothing until Claude is restarted.
Node.js 22.12.0 or newer, and an install hook that runs on npm install
package.json sets engines to node >=22.12.0 and marks the package as an ES module. Three binaries are exposed: desktop-commander points at dist/index.js, setup at dist/setup-claude-server.js and remove at dist/uninstall-claude-server.js. An older Node.js will not satisfy the engines field, so the npx routes that need Node.js are the ones most likely to fail on a machine you have not touched in a while. The Docker route avoids that, since the Docker image starts from node:lts-alpine and the host needs no Node.js of its own.
The postinstall script runs two steps in order: node dist/track-installation.js and then node dist/npm-scripts/verify-ripgrep.js, with a fallback of node -e "process.exit(0)" so a failure in that chain does not abort the install. The first step is an installation tracker, and the repository carries a PRIVACY.md, which is where you should read what is recorded before deploying this on a work machine. The second step checks the ripgrep binary that the recursive search depends on.
The guardrails are a command blocklist and symlink checks, not a sandbox
The safety list in the README is short and carefully worded: symlink traversal prevention on file operations, a command blocklist for accidental execution, and Docker isolation for complete isolation. The heading above it says plainly that these guardrails are not a sandbox and points to SECURITY.md.
The consequence is concrete. A blocklist stops a model from typing a known destructive command by mistake, but it does not stop a determined or confused sequence of allowed commands, and the server runs with the permissions of your user account. Anything your account can read, write or delete is within reach of the model. The only isolation the project itself offers is the Docker route, whose Dockerfile sets MCP_CLIENT_DOCKER=true, installs dependencies with npm install --ignore-scripts, rebuilds @vscode/ripgrep so the binary is downloaded, runs npm run build and starts with node dist/index.js. Inside a container the server only sees what you mount into it, which also means it cannot see your real project folders until you do.
Long-running commands are handed back as sessions you can poll
Most of the terminal feature set exists because a chat model cannot sit and wait. Commands stream their output, have a timeout, can run in the background, and belong to a session so that a later call can read more output or send input. The README gives SSH sessions, databases and development servers as examples of processes you can keep talking to, and it lists in-memory code execution for Python, Node.js and R so you can analyse a CSV, JSON or Excel file without saving a script first. Process management lets you list processes and kill them.
Output is paginated with offset and length controls, because a chatty build log would otherwise flood the model's context. File reading follows the same idea: a negative offset reads from the end of a file, like Unix tail, and recursive directory listing takes a configurable depth with protection for very large folders. The limit to keep in mind is that all of this is bounded by what the client shows the model. A process that prints megabytes will be read in slices, and anything the model does not request is never seen.
Excel, PDF and DOCX are read and written inside the server
Beyond plain text, the file tools handle Excel files (.xlsx, .xls and .xlsm), PDFs and Word documents. For Excel you can read, write, edit and search content without external tools. For PDFs the server extracts text, creates new PDFs from markdown and modifies existing ones. For DOCX it reads, creates, edits and searches documents, using surgical XML editing and markdown-to-DOCX conversion.
Code editing has two modes: surgical text replacements for small changes, and full file rewrites for major ones, with pattern-based replacements and support for multiple files. The File Preview UI is the visual layer on top, with rendered markdown, inline images, expandable content, a built-in markdown editor and an Open in folder shortcut. The README names Claude Desktop as the place that preview appears, so users of other clients should expect the underlying tools to work without that panel.
Tool call history stays on the machine, in files that rotate
Desktop Commander records tool calls and their arguments locally on the machine running it. The get_recent_tool_calls tool returns recent history with bounded output previews, and size-based rotation and trimming keep the active history files from growing without limit. That is useful as an audit trail after a long session, since you can see which commands the model ran and in what order.
Two limits apply. The history lives on the same machine as the server, so it is only as trustworthy as that machine, and a command that deletes files in your home directory could in principle reach the logs if they sit there too. And because the files are trimmed by size, an old session can disappear from the record. If you need a durable audit trail, copy the history out before it rotates.
Configuration is separate and changes at runtime: there are tools to get and set values and to update several settings at once, and the README says changes apply without restarting the server.
Remote MCP and the plugin folders reach beyond Claude Desktop
The top of the README points ChatGPT, Claude web and other remote clients to Remote MCP at mcp.desktopcommander.app, and to the Remote device launchers in scripts/remote, which install Node.js when it is missing and run Desktop Commander Remote on your machine. The package.json scripts device:install, device:start and device:start:dev run the remote device code from src/remote-device with tsx.
The repository root also contains .cursor-plugin, .claude-plugin, gemini-extension.json, plugins, skills and rules directories, plus server.json and smithery.yaml. Their presence shows that the project is packaged for several clients, but the Claude Desktop options are the ones with step-by-step instructions, so a Cursor or VS Code user should expect to rely on the client's own MCP configuration pointing at the same npx command rather than a dedicated installer.
Editorial conclusion
Use it if you want one MCP server that lets Claude run long terminal sessions and edit files on your own machine, and you accept that the blocklist is only a guard against accidents. Put it in Docker or on a disposable machine before pointing it at anything you cannot restore, and pin the version if you do not want npx to move it for you.
Frequently asked questions
What is Desktop Commander MCP?
It is an MCP server for Claude that gives the model terminal control, file system search and diff file editing. It is built on top of the MCP Filesystem Server and published as @wonderwhy-er/desktop-commander under the MIT license.
How do I use Desktop Commander MCP?
For Claude Desktop, run npx @wonderwhy-er/desktop-commander@latest setup in a terminal and restart Claude. Other routes are the macOS bash installer, Smithery, a manual claude_desktop_config.json entry and Docker.
Does Desktop Commander MCP work on Windows?
The Claude Desktop config path for Windows is %APPDATA%\Claude\claude_desktop_config.json, and the repository includes install-docker.ps1 and remote launchers for macOS, Linux and Windows. The bash installer is the macOS route.
What is the pricing for Claude Desktop MCP when using Desktop Commander?
Desktop Commander itself is MIT licensed, and the README says it works through your host client subscription instead of API token costs. What Claude Desktop costs is set by Anthropic, not by this repository.
What is Claude Desktop Commander?
It is the common name for Desktop Commander MCP, a server that lets Claude run terminal commands, manage processes, search files and edit them with surgical replacements or full rewrites.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/wonderwhy-er-desktopcommandermcp)Star history chart for your README
[](https://hysenlabs.com/projects/wonderwhy-er-desktopcommandermcp)Was this useful?