# DesktopCommanderMCP allowedDirectories Security Best Practices: Configuration Guide and Guard-Rail Limitations

> Learn DesktopCommanderMCP security best practices for allowedDirectories. Configure narrow absolute paths, avoid empty arrays, and leverage isolation for robust protection. Read the guide now.

- Repository: [Eduard Ruzga/DesktopCommanderMCP](https://github.com/wonderwhy-er/DesktopCommanderMCP)
- Tags: best-practices
- Published: 2026-07-18

---

**The recommended security practice for `allowedDirectories` is to treat it as a filesystem guard-rail rather than a sandbox—always specify narrow, absolute paths, never leave the array empty, verify settings with `get_config({})`, and combine with Docker or VM isolation for production environments.**

DesktopCommanderMCP is a Model Context Protocol (MCP) server that exposes filesystem and terminal operations to AI clients. The `allowedDirectories` configuration option in [`config.json`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/config.json) determines which filesystem paths the server may access during read, write, and move operations, but it does not restrict shell commands. Understanding the distinction between these access controls is essential for securing your host system.

## Understanding the Scope of allowedDirectories

The `allowedDirectories` array functions as a path whitelist for filesystem-specific API calls. However, it provides no protection against command substitution or direct shell access.

### Filesystem vs. Terminal Command Access

According to the source code analysis of [`README.md`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/README.md) (lines 16-25), `allowedDirectories` limits **file-system** calls to listed folders but **does not** restrict terminal commands. A shell executed via DesktopCommanderMCP can still reach any path on the host, including those outside the allowed directories. This architectural limitation means `allowedDirectories` prevents accidental file modifications but cannot stop malicious path traversal through shell commands.

## Five Essential Security Practices for allowedDirectories

### 1. Never Configure an Empty Array

An empty array (`[]`) disables the restriction entirely, granting unrestricted filesystem access. As documented in [`README.md`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/README.md) (lines 74-75), you should **never leave the list empty**. Always populate `allowedDirectories` with at least one absolute path, even during initial testing.

### 2. Specify Absolute, Project-Specific Paths

Restrict access to the narrowest possible scope. The documentation in [`README.md`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/README.md) (lines 76-77) recommends using specific absolute paths such as `/Users/me/project` rather than broad locations like `/` or the entire home folder. This minimizes the blast radius if the AI client generates unintended file operations.

### 3. Implement OS-Level Container Isolation

For production scenarios or high-risk workloads, `allowedDirectories` alone is insufficient. The [`SECURITY.md`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/SECURITY.md) file (lines 26-33) recommends running DesktopCommanderMCP inside Docker or a virtual machine, mounting only the whitelisted directories as volumes. This provides true sandboxing, whereas `allowedDirectories` only protects filesystem APIs.

### 4. Verify Configuration via get_config({})

After modifying `allowedDirectories`, always confirm the change persists in [`config.json`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/config.json). According to [`README.md`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/README.md) (lines 78-79), you should call `get_config({})` to verify that the correct paths are stored and active. The configuration service loads these values at runtime from [`src/index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/index.ts), the entry point where the RPCs are exposed.

### 5. Recognize the Guard-Rail Limitations

Treat `allowedDirectories` as a safety mechanism against accidental edits, not a security boundary against malicious intent. Combine this configuration with a trustworthy AI client, multi-factor authentication (MFA), and regular audits of granted permissions.

## Configuring allowedDirectories Programmatically

The server exposes `get_config` and `set_config_value` RPCs to manage the `allowedDirectories` array programmatically.

Retrieve the current configuration to inspect existing paths:

```javascript
const config = await get_config({});
console.log('Current allowedDirectories:', config.allowedDirectories);

```

Update the restriction to a specific project directory:

```javascript
await set_config_value({
  key: "allowedDirectories",
  value: ["/Users/yourname/projects/my-awesome-app"]
});

// Verify the change
const updated = await get_config({});
console.log('Updated allowedDirectories:', updated.allowedDirectories);

```

Execute the same operations from the CLI using the built-in MCP client:

```bash
node dist/index.js --run "get_config({})"
node dist/index.js --run "set_config_value({key:'allowedDirectories',value:['/Users/yourname/projects/my-awesome-app']})"
node dist/index.js --run "get_config({})"

```

## Isolating DesktopCommanderMCP with Docker

For environments requiring strict isolation, deploy the server in a container with limited volume mounts. This approach implements defense-in-depth beyond the `allowedDirectories` guard-rail.

Create a [`docker-compose.yml`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/docker-compose.yml) that mounts only the required directory:

```yaml
services:
  desktop-commander:
    image: mcp/desktop-commander:latest
    volumes:
      - /Users/yourname/projects/my-awesome-app:/mnt/workspace:ro

```

In this configuration, even if `allowedDirectories` is misconfigured or bypassed via shell commands, the container filesystem boundary prevents access to the host system outside the mounted volume.

## Summary

- **Never use an empty array** for `allowedDirectories`—it disables all filesystem restrictions.
- **Prefer narrow, absolute paths** over broad directories to limit accidental exposure.
- **Verify all changes** by calling `get_config({})` to ensure [`config.json`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/config.json) reflects your intent.
- **Combine with Docker or VM isolation** for production security, as `allowedDirectories` does not protect against shell commands.
- **Understand the guard-rail nature** of this setting—it prevents mistakes, not attacks.

## Frequently Asked Questions

### Does allowedDirectories restrict terminal commands?

No. The `allowedDirectories` configuration only limits filesystem API calls (read, write, move) executed directly by the server. Terminal commands issued through DesktopCommanderMCP execute in a shell that can access any path on the host system, regardless of the `allowedDirectories` setting. For command restriction, you must implement OS-level isolation such as Docker or chroot jails.

### What happens if I set allowedDirectories to an empty array?

Setting `allowedDirectories` to `[]` removes all filesystem path restrictions, granting the AI client unrestricted read and write access to the entire host filesystem through the server's file operations. The [`README.md`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/README.md) explicitly warns against this configuration in lines 74-75.

### How do I verify my allowedDirectories configuration is active?

Call the `get_config({})` RPC method to retrieve the current configuration object and inspect the `allowedDirectories` array. This reads directly from the [`config.json`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/config.json) file loaded at runtime in [`src/index.ts`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/src/index.ts). Always verify changes immediately after using `set_config_value` to ensure persistence.

### Is Docker isolation necessary for local development?

For local development with trusted AI clients and non-sensitive data, strict isolation may be optional. However, the [`SECURITY.md`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/SECURITY.md) documentation (lines 26-33) recommends Docker for any scenario where the AI client must not access the rest of the machine, including production deployments or when processing sensitive files. Treat `allowedDirectories` as a convenience guard-rail, not a security boundary.