Desktop Commander MCP

Desktop Commander runs with the full authority of the logged-in user and narrows nothing by default: the allowed-folders list ships empty, which the code treats as the whole filesystem, and every shell it starts inherits the server's complete environment, including any API keys or tokens in it. Worse, the model itself can widen its own permissions: the set_config_value tool lets it rewrite the allowed-folders list and the blocked-command list, and the config file lives in the home directory that its own file tools can edit. A hijacked session therefore reaches everything the user can, across every service whose credentials sit in the home directory or environment.

As a tool server, Desktop Commander leaves approval to the host, and gives it reasonable signals: every listed tool carries readOnly/destructive hints, and the shell, write, move, kill and config tools are all marked destructive. It offers no dry-run or preview for destructive operations and no server-enforced read-only mode. If a host approves the wrong shell command, nothing in the server can undo it: commands run directly on the machine, and edits and deletes have no checkpoints.

The main tool is a raw shell, filtered only by a list of blocked command names that the project's own security policy says can be circumvented. File tools do resolve symlinks and check paths against an allowed-folders list, but that list ships empty, which allows everything, and the shell ignores it anyway. URL reads accept any address, including internal ones, interactive shell input is never checked, and the model can choose any program as the 'shell'. The model can also clear both the blocklist and the folder list itself with set_config_value.

By default, shell commands and model-written Node.js run directly on the user's machine as the user, with the full environment and network; there is no sandbox at all. The project's own security policy says the folder list and blocklist are not boundaries and recommends Docker for isolation. The Docker install it ships runs the whole server inside a stock container with only the folders you pick mounted, which is a real but basic boundary (root inside the container, unrestricted network). Because Docker is opt-in, it scores at most half credit.

Nothing limits what a hijacked session can do. The server fetches any URL and reads any file, returns that content as plain text with no provenance or untrusted marking, and offers no read-only or no-egress mode. It also mixes its own instructions into results: tool descriptions carry imperative directives, and tool outputs can have '[SYSTEM INSTRUCTION]' blocks appended (feedback and onboarding prompts switched on by remotely fetched feature flags). Content an attacker plants in a web page or file can therefore steer the model to read secrets and send them out through the shell or a URL fetch, or to delete data, with no server-side check.

Desktop Commander does not auto-load project instruction files, but two things persist across sessions. First, its security settings (blocked commands, allowed folders, shell) live in a config file in the home directory that the model can change with set_config_value or its own file tools, and a file watcher applies edits immediately; a one-time injection can therefore permanently loosen the server. Second, every tool call's arguments and output (up to 4 KB) are saved and can be read back into later chats with get_recent_tool_calls, without marking which parts came from untrusted sources.

The server has no plugin or extension system, but it does fetch and run third-party code on its own: at startup, if no Chrome is found, it downloads the current 'stable' Chrome build from Google's distribution and later runs it to render PDFs, with no version pin, no integrity check in this code and no consent prompt. Through its shell the model can also install and run any npm or pip package with the user's full access. Nothing confines what such code can reach.

The server holds no keys of its own in the default mode, but it does nothing to keep secrets out of reach or out of its records. Shells inherit the whole environment, so any API key in it is one 'env' command away. Every tool call's arguments, and outputs up to 4 KB, are written in plain text to two files in the home directory with no redaction, so a secret the model reads ends up on disk. Telemetry to the vendor is on by default; it strips path-like fields and sends tool and command names rather than file contents.

Every tool call is recorded twice in the user's home directory: a plain-text log of tool names and full arguments, and a structured JSON-lines history with arguments, results and timing. There is no record of who asked (local or remote caller is only sent to telemetry), and both files sit where the model's own file and shell tools can edit or delete them. The history is written in batches once a second, the argument log is written without waiting, and failures are silent, so the last actions before a crash can be lost.

Some operations have server-side bounds: URL reads time out after 30 seconds, process output is capped at 50 MB per session, and directory listings cap nested entries. But the command timeout only stops the server waiting; the process keeps running in the background with no time limit, and the model chooses the timeout itself. Force-terminate signals only the direct child, not its process tree, and nothing cleans up running processes when the server exits.