Hey — thanks for the positive response on the original version of this issue! I've trimmed it down to the key findings. Appreciate that you're planning to address some of these.
TL;DR
Desktop Commander has solid security-awareness (blocklist, allowedDirectories, SECURITY.md). The main gap is that the agent can modify its own safety controls at runtime via set_config_value.
Top Findings
1. Agent can disable its own safety controls (CRITICAL)
set_config_value lets the agent modify blockedCommands, allowedDirectories, and defaultShell at runtime. A prompt injection can instruct the agent to clear the blocklist, then execute anything. The tool description warns against using it in the same chat as commands — but that's a natural-language suggestion the LLM can ignore.
2. Shell execution with bypassable blocklist (HIGH)
The command blocklist is more thorough than most MCP servers (handles $(), backticks, subshells, chained operators). But as your SECURITY.md honestly notes, shell syntax is effectively unbounded — alias bypass, encoding tricks, and env sudo patterns still work.
3. allowedDirectories doesn't apply to shell commands (HIGH)
Filesystem tools respect the directory restrictions, but start_process can cat /etc/passwd regardless. The restriction only gates the filesystem tool handlers, not what shell commands can access.
4. kill_process not scoped to managed sessions (HIGH)
kill_process can terminate any system PID, not just processes spawned by Desktop Commander.
Suggestions
- Remove security-critical keys from
set_config_value — or require an out-of-band confirmation for changes to blockedCommands/allowedDirectories
- Apply directory restrictions to shell commands where feasible
- Scope
kill_process to processes Desktop Commander spawned
- Default
allowedDirectories to non-empty — empty array means "allow everything"
Great project. The transparency in SECURITY.md about the limitations is refreshing — most MCP servers don't acknowledge these risks at all.
Found using AgentWard — open-source permission control plane for AI agents.
Hey — thanks for the positive response on the original version of this issue! I've trimmed it down to the key findings. Appreciate that you're planning to address some of these.
TL;DR
Desktop Commander has solid security-awareness (blocklist, allowedDirectories, SECURITY.md). The main gap is that the agent can modify its own safety controls at runtime via
set_config_value.Top Findings
1. Agent can disable its own safety controls (CRITICAL)
set_config_valuelets the agent modifyblockedCommands,allowedDirectories, anddefaultShellat runtime. A prompt injection can instruct the agent to clear the blocklist, then execute anything. The tool description warns against using it in the same chat as commands — but that's a natural-language suggestion the LLM can ignore.2. Shell execution with bypassable blocklist (HIGH)
The command blocklist is more thorough than most MCP servers (handles
$(), backticks, subshells, chained operators). But as your SECURITY.md honestly notes, shell syntax is effectively unbounded — alias bypass, encoding tricks, andenv sudopatterns still work.3.
allowedDirectoriesdoesn't apply to shell commands (HIGH)Filesystem tools respect the directory restrictions, but
start_processcancat /etc/passwdregardless. The restriction only gates the filesystem tool handlers, not what shell commands can access.4.
kill_processnot scoped to managed sessions (HIGH)kill_processcan terminate any system PID, not just processes spawned by Desktop Commander.Suggestions
set_config_value— or require an out-of-band confirmation for changes to blockedCommands/allowedDirectorieskill_processto processes Desktop Commander spawnedallowedDirectoriesto non-empty — empty array means "allow everything"Great project. The transparency in SECURITY.md about the limitations is refreshing — most MCP servers don't acknowledge these risks at all.
Found using AgentWard — open-source permission control plane for AI agents.