Desktop Commander MCP: Setup, Remote Mode and Security Risks

The short answer

Desktop Commander is an MCP server that lets an AI client read and write your files and run terminal commands and long-lived processes on your computer, and its own security policy says its built-in limits are guardrails, not a sandbox. As of October 30, 2026 the npm latest version is 0.3.1, published October 22, 2026, under the MIT license. It runs locally inside MCP clients such as Claude Desktop, Cursor, Codex and Claude Code, or through a Remote Device that lets ChatGPT and Claude web call the same tools on your machine.

The practical advice is short. Treat the connected AI account as having a shell on your computer, because it does. Use allowedDirectories and the command blocklist to avoid accidents, and do not rely on them to stop a hostile prompt. Where the AI must not reach the rest of the machine, run Desktop Commander in Docker or a virtual machine, which is what SECURITY.md recommends. If all you need is file access, the official filesystem MCP server has a much smaller blast radius, and if you code in Claude Code you may not need Desktop Commander at all.

This guide is built from the project’s README, SECURITY.md, PRIVACY.md, the Remote MCP README, the product page, the GitHub releases and the npm registry entry, plus the filesystem server’s README and Claude Code’s permissions and sandbox documentation for the comparisons. We did not install or run Desktop Commander for this article, so everything here is documentation-based, and the claim table near the end marks what is vendor-stated. For readers building a wider toolset, see our top MCP servers list and best MCP servers for Claude Code, by job.

What access it grants

The README’s tool table is the clearest statement of scope. Desktop Commander exposes configuration tools (get_config, set_config_value), terminal tools (start_process, interact_with_process, read_process_output, force_terminate, list_sessions, list_processes, kill_process), filesystem tools (read_file, read_multiple_files, write_file, write_pdf, create_directory, list_directory, move_file, start_search and related search calls, get_file_info), a text editing tool (edit_block) and analytics tools (get_usage_stats, get_recent_tool_calls, give_feedback_to_desktop_commander). It also reads Excel, PDF and DOCX files, can fetch URLs through read_file, and can hold interactive sessions such as SSH, database consoles and development servers.

Two details matter for risk. First, the terminal tools are not limited to a project folder: a process started with start_process runs as your user, with your environment, your home directory, your SSH keys and your cloud credentials in reach unless the operating system stops it. Second, set_config_value is itself a tool, so the same client that the settings are meant to restrain can ask to change them. The README acknowledges this and tells users to change configuration in a separate chat from the one where they do real work, because the assistant may try to edit allowedDirectories when it hits a filesystem restriction.

Current version and release pace

The npm registry listed latest as 0.3.1, published at 07:54 UTC on October 22, 2026, with a separate alpha tag at 0.3.1-alpha.2. The GitHub release for v0.3.1 is dated October 22 as well. Version 0.3.0 followed on October 13, and the 0.2.x line before it had releases on September 29 (0.2.52) and September 17 (0.2.51), so the package ships roughly every one to three weeks. The npm metadata for 0.3.1 lists the MIT license, three command entries (setup, remove and desktop-commander), and 34 declared dependencies. Earlier research notes pointed to 0.2.38 from March 2026; that is no longer current.

Release notes show where the security-relevant edges have been. Version 0.3.0 includes fixes titled “an allowed directory reached through a symlink stays allowed” and “validatePath checks where a dangling link writes,” a telemetry change to “keep Error messages, redact whole paths,” a dependency security update, and a batch of Remote reconnection fixes. Version 0.3.1 adds the Desktop Commander version at Remote startup and timestamps on remote terminal output, and pins a PDF dependency. None of this proves anything about exploitability, but it fits the project’s own framing: path handling is an ongoing engineering surface, not a closed one.

One discrepancy is worth checking before you install. The npm metadata for 0.3.1 declares engines.node as 22.12.0 or newer, while the Remote MCP README says Node.js 18 or newer and the product page says 18.0.0 or newer. We did not test which is right, so run node --version first and prefer a current Node release.

Local setup, step by step

The README lists six install routes for Claude Desktop and a generic JSON entry for other clients. These are the ones most readers will use.

Claude Desktop

The recommended route is the setup command, which edits Claude Desktop’s configuration for you. Restart Claude afterwards.

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

To do the same by hand, add this entry to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\, Linux: ~/.config/Claude/):

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

Claude Code, Codex and other clients

The README gives one-line commands for two terminal agents. Remove --scope user from the Claude Code command to install for the current project only.

claude mcp add --scope user desktop-commander -- npx -y @wonderwhy-er/desktop-commander@latest
codex mcp add desktop-commander -- npx -y @wonderwhy-er/desktop-commander@latest

Cursor, Windsurf, VS Code with GitHub Copilot, Cline, Roo Code, Trae, Kiro, JetBrains AI Assistant, Gemini CLI, Augment Code and Qwen Code are each covered with the same JSON entry or a client-specific command in the README.

Pin the version if you care about supply chain

Every route above uses @latest, and the README sells that as a feature: the server updates itself whenever the client restarts. For a tool with shell access, that also means each restart can pull new code. Our recommendation, not the project’s, is to replace @latest with the exact version you reviewed, for example @0.3.1, and to update deliberately. The README gives the uninstall command as npx @wonderwhy-er/desktop-commander@latest remove, which also backs up the Claude config before editing it.

Docker, the isolated route

Option 6 in the README runs the server in a container, with an installer script for macOS, Linux and Windows PowerShell. The manual configuration uses the image mcp/desktop-commander:latest, and folders are exposed to it with -v mounts:

{
  "mcpServers": {
    "desktop-commander-in-docker": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-v", "/Users/username/Projects:/mnt/Projects",
        "mcp/desktop-commander:latest"
      ]
    }
  }
}

The README says this gives “complete isolation” and “zero risk to your computer,” which is a vendor claim worth reading carefully. Isolation covers the host outside the container. It does not cover whatever you mount in: a read-write mount of your home folder gives the AI your home folder. Mount only the project directory, and consider adding a read-only flag where the AI only needs to read, a pattern the filesystem server’s README documents for its own Docker image.

What the config options do

The README documents six settings, readable with get_config and writable with set_config_value. The product page also lists allowed directories, blocked commands and a custom shell as configurable.

The important row is the second. In the README’s words, allowedDirectories “currently only restricts filesystem operations, not terminal commands.” An assistant limited to /Users/you/projects for file tools can still run cat on a file elsewhere through a terminal process. SECURITY.md makes the same point in a table: allowed directories, the command blocklist and symlink traversal prevention each have “No” in the column asking whether they are a security boundary, and only Docker or VM isolation has “Yes.”

The README also lists best practices that are easy to skip: use specific paths instead of broad ones like /, verify with get_config after changes, and keep configuration changes in a dedicated chat. We would add one: write the actual list into the config before first use, rather than leaving defaults, and re-read it after any session in which the assistant hit a permissions error. The README says the configuration is saved to a config.json in the server’s working directory, while PRIVACY.md points to ~/.desktop-commander/config.json for the telemetry setting. We did not verify which path your install uses, so search for the file before relying on it.

Remote MCP for ChatGPT and Claude web

Local MCP only works in desktop clients that can launch a process. Remote MCP exists so web clients can reach the same tools. The product page markets it as a way to “connect one or more of your devices remotely” and to control a computer from a phone or any browser. It names ChatGPT, Claude web and Cursor as supported clients for the remote route, and Claude Desktop for the local route.

How it works

The Remote MCP README describes the path as: AI client, then the Desktop Commander Remote MCP service, then the Remote Device on your computer, then the local Desktop Commander server. The Remote Device is a local process that connects outward to the service. Commands execute locally under your user account, and the device only receives calls while it is running and connected.

Setup

1. Start the device on the computer you want to control: npx @wonderwhy-er/desktop-commander@latest remote. If Desktop Commander is installed globally, desktop-commander remote is the equivalent.
2. Complete the OAuth device-authorization flow. A browser opens to a verification page; confirm that the code shown there matches the one in your terminal, sign in, and authorize the device.
3. Open mcp.desktopcommander.app and follow the connection instructions for your AI client.
4. Leave the terminal running. Press Ctrl+C to take the machine offline.

Step two is worth doing deliberately. The device flow is designed so you compare the code on both sides, which is the protection against approving a pairing someone else started. The README lists prerequisites of Node.js 18 or newer, a Desktop Commander account and an AI client that can connect to the remote service.

Credentials, stopping and revoking

By default the authenticated session is saved to ~/.desktop-commander-device/device.json and reused on restart. On POSIX systems the file is created with mode 0600; on Windows the README says no custom owner-only ACL is set, so access follows normal profile permissions. These actions do different things, and the README is explicit that stopping is not revoking:

For a clean reset, revoke in the dashboard, run remote --logout, then pair again. Other flags are --no-persist-session (do not save or reuse credentials, so browser authorization is needed on every start), --disable-no-sleep and --debug. On macOS the device runs caffeinate by default so the machine stays awake and reachable, which is convenient and also means the host stays available longer than you might expect.

What changes in the risk picture

Local MCP exposes your shell to one app on your machine. Remote MCP exposes it to every web AI account you connect, through a third-party relay. Both SECURITY.md and the Remote README state the model plainly: the connected AI client and the account driving it are assumed trusted, and Desktop Commander does not try to tell a real user request from prompt injection or from a compromised AI account. Our reading is that a stolen ChatGPT or Claude session, or a malicious page the assistant is asked to summarize, becomes a shell on the paired machine for as long as the device is online. SECURITY.md’s mitigations are modest and sensible: turn on MFA for connected AI accounts, connect only clients you trust and remove unused ones, scope work to project directories, and review generated commands when the context warrants it.

The documentation does not say whether the Remote Device can be run inside Docker or a virtual machine, so we cannot promise that route works. The general advice in SECURITY.md applies: for workloads where the AI must not reach the rest of the machine, use a virtual machine, dev container or separate workstation, and pair that environment instead of your daily laptop. For a related look at remote access to coding agents, see Claude Code Remote Control: setup, limits and fixes and OpenAI secure MCP tunnels.

Logs, telemetry and retention

Three different data flows are easy to confuse, and the project documents each.

Two points follow. The local argument log is a plain-text record of what the AI asked your computer to do, which is useful for audits and a liability if it contains a token you pasted into a command. Treat ~/.claude-server-commander/ as sensitive, exclude it from backups you share, and clear rotated files yourself. And the remote retention statement covers terminal rows specifically; the README does not give a retention period for file-read results routed through the service, so assume file contents you read through Remote MCP pass through it.

Telemetry is opt-out. PRIVACY.md, last updated December 11, 2025, lists the collected fields, says it does not collect file paths, file contents, command arguments, usernames or IP addresses (Google Analytics receives IP addresses over HTTPS and anonymizes them before storage), and gives two ways to disable it: ask the assistant, or set "telemetryEnabled": false in the config and restart. Per the 0.3.0 release notes, a telemetry fix kept error messages while redacting whole paths, which suggests path leakage through error text was a real problem at some point. Disabling telemetry does not touch the local logs.

Versus the filesystem MCP server and Claude Code

Desktop Commander’s README says it is built on top of the official MCP Filesystem Server and adds search, edit and terminal capabilities. Comparing the two, and comparing both with Claude Code’s own tools, clarifies what you are adding when you install it.

Against the filesystem server

The official server is the right baseline for read and write access to a fixed set of folders. Its README says the server may touch only its allowed directories, which you pass as arguments, and that it needs at least one. It also documents a limit that is a useful reminder for any path-based guard: checks are path-based, so a file inside an allowed directory that is hard-linked from elsewhere can be changed through the allowed name. It documents mounting directories read-only in Docker. The comparison that matters is capability: the filesystem server has no command-execution tool in what we read, so a prompt injection against it can read and rewrite files in the allowed folders but cannot, through that server, start a program. With Desktop Commander it can.

Against Claude Code

Claude Code ships Bash, Read, Edit and Write tools, evaluates permission rules in the order deny, ask, allow, and prompts for Bash, file edits and MCP tools in manual mode. Its sandbox is off by default and, when enabled, wraps shell commands and their children with operating-system enforcement for files and network. The part that matters here is in the sandbox documentation: the sandbox covers shell commands only, and local MCP servers, hooks and other helper processes run outside it with your full access. So Desktop Commander added to Claude Code is not inside Claude Code’s sandbox, and it gives the model a second shell path next to the sandboxed Bash tool. The same documentation warns that Bash deny rules match the command text, so Bash(rm *) does not stop /bin/rm or bash -c; the project’s own blocklist has the same structural weakness, which is why OS-level isolation is the answer in both cases.

If you keep Desktop Commander in Claude Code, you can narrow it with permission rules. MCP tool names take the form mcp__server__tool, so for a server added as desktop-commander a user-settings deny list could look like this (rule syntax per Claude Code’s permissions page; verify the tool names in /mcp for your version):

{
  "permissions": {
    "deny": [
      "mcp__desktop-commander__start_process",
      "mcp__desktop-commander__interact_with_process",
      "mcp__desktop-commander__kill_process",
      "mcp__desktop-commander__force_terminate",
      "mcp__desktop-commander__set_config_value"
    ]
  }
}

That leaves the file and search tools and removes the terminal and the self-configuration tool. Claude Code’s docs note that MCP rules containing parentheses are skipped, so write whole tool names or a server wildcard. At that point you have a heavier filesystem server, and for plain file access the official one is simpler. For safer agent configuration in a different tool, see Antigravity dangerous commands and file safety.

Threat model

Four scenarios cover most of the realistic exposure. They follow from the project’s documentation; the ranking is ours.

• Prompt injection through content the assistant reads. A web page, a repository file, an email or a PDF contains instructions, and the assistant follows them using Desktop Commander’s tools. SECURITY.md says the tool does not tell injection from a genuine request. The blast radius is whatever your user account can do.
• A compromised AI account or session. This matters most for Remote MCP, where a web account is the control plane for a paired computer. MFA on that account is the first line of defense.
• The assistant weakens its own limits. Because configuration is a tool, an assistant can widen allowedDirectories or shrink the blocklist, as the README warns. Deny that tool in the client, or change config only in a separate chat.
• Supply chain and auto-update. The @latest pattern runs whatever the registry serves at restart. The package has 34 declared dependencies in its latest metadata. Pin versions on machines that hold credentials.

Ordinary mistakes also count. The README’s own testimonials include the advice to stage and commit before letting the assistant change a codebase, and that is good practice whatever the guardrails are: use version control, work on a branch, and keep irreplaceable files outside the allowed folders.

A hardening checklist

1. Decide whether you need a shell at all. If the job is reading and editing files, use the filesystem MCP server or your agent’s built-in tools.
2. Choose the boundary first. For untrusted content or unattended runs, use the Docker install, a dev container or a virtual machine, and mount only the project directory. SECURITY.md lists Docker and VM isolation as the only controls that are security boundaries.
3. Set explicit allowedDirectories and verify them with get_config in a separate chat. Never leave the list empty.
4. Treat blockedCommands as a seatbelt. Add destructive commands you never want run by accident, and do not count on it against a determined prompt.
5. Use client-side approval. Keep manual approval on for terminal tools, and in Claude Code consider denying set_config_value and the process tools.
6. Pin the npm version on any machine with production credentials, and update after reading the release notes.
7. Keep secrets out of reach. Run under an account without cloud credentials and SSH keys, or use a dedicated machine.
8. For Remote MCP: enable MFA on the AI account, pair only machines you are willing to expose, press Ctrl+C when you are done, use --no-persist-session on shared machines, and revoke devices in the dashboard when retiring a computer, because --logout alone does not revoke.
9. Clean up logs. Review ~/.claude-server-commander/, delete rotated logs, and decide whether to disable telemetry.
10. Prepare for undo. Commit before sessions and keep backups of anything the assistant can write to.

Which setup for which job

Claim and evidence table

Limitations

• We did not install or run Desktop Commander, the Remote Device or any of the settings described. Every behavior is as documented on October 30, 2026, and the project ships often, so check the README before relying on a detail.
• We did not audit the source for how allowedDirectories, the blocklist or path validation are implemented, and we did not attempt a bypass. The bypass statements are the project’s own.
• We did not review the Remote MCP service’s infrastructure, the privacy terms for the hosted service beyond what the README says, or any pricing for Remote MCP. We found none stated in the pages we read.
• The config file location differs between the README and PRIVACY.md, and the Node version requirement differs between the npm metadata and the READMEs. Both are left unresolved.
• The README’s FAQ says the tool works with a Claude Pro subscription rather than API credits. We did not verify current plan terms for Claude, ChatGPT or any other host client.
• The Claude Code comparison uses Anthropic’s published docs for rule behavior, and the exact MCP tool names depend on the version you install.

Verdict

Desktop Commander does what it says, and the project is unusually direct about the cost. It is a privileged tool, its settings are advisory, and the one boundary it endorses is the one you build around it with Docker or a virtual machine. That honesty is useful, because it tells you where to put your effort: the settings reduce accidents, the isolation reduces damage.

Use it when you want a chat app to run real commands, handle spreadsheets and PDFs, or reach your own computer remotely, and when you accept that the connected AI account is trusted with that machine. Run it in a container for anything unattended, pair only machines you are willing to expose, pin the version, and read the local logs once. Skip it when a read-only or folder-limited server would do the job, and skip it on a computer that holds credentials you cannot afford to lose. If you are building a broader MCP toolset, compare it against the picks in our top MCP servers list, and read the Antigravity security guide for the same trade-offs in an agentic IDE.

FAQ

Sources

Sources checked October 30, 2026.

• Desktop Commander MCP README: install routes, tool table, configuration warnings, local logs, telemetry summary
• SECURITY.md: security model, control table, known limitations, reporting
• PRIVACY.md: telemetry fields, retention, opt-out
• Remote MCP README: device flow, credentials, revocation table, CLI flags, retention
• desktopcommander.app/mcp: product page for local and Remote MCP
• GitHub releases and npm registry entry: version, dates, engines, license
• Official filesystem MCP server README: allowed directories, tool list, Docker mounts
• Claude Code permissions, sandboxing and tools reference: rule order, MCP rule syntax, what the sandbox does not cover

Related reading: Top MCP servers, Best MCP servers for Claude Code, Claude Code Remote Control guide, OpenAI secure MCP tunnels and Antigravity security guide.