# Docker Isolation in Desktop Commander: Secure Container Architecture and Host Directory Mounting

> Explore Docker isolation in Desktop Commander using namespace isolation and read-only filesystem. Securely access host directories via bind-mount for enhanced container architecture.

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

---

**Desktop Commander sandboxes every user session inside a Docker container with namespace isolation and read-only filesystem protections, while mounting the host home directory via bind-mount to enable secure file access.**

Desktop Commander, an open-source MCP server available at `wonderwhy-er/DesktopCommanderMCP`, implements robust **Docker isolation** to ensure code execution cannot affect the host system. The architecture combines Linux namespaces with controlled **host directory mounting** capabilities to balance security with usability, as defined in the project's container configuration files.

## Container Isolation Architecture

Desktop Commander's security model relies on Docker's namespace features to create a restricted execution environment. Each session launches as a separate container instance built from the **`Dockerfile`** located in the repository root, with explicit limitations on system access.

### Process and Namespace Isolation

The container configuration implements **PID namespace isolation**, ensuring that processes running inside the container cannot view or interact with host system processes. According to the repository's container configuration, the application also enforces **network namespace isolation**, exposing only the necessary port (`localhost:8080`) while restricting access to the host's network stack.

### Security Hardening Measures

Beyond namespace isolation, the `Dockerfile` configures the container with a **read-only root filesystem**, preventing modifications to system binaries and configuration files. The container executes as a non-root user (`node`), eliminating privileged operations that could compromise the host system.

## Host Directory Mounting Capabilities

While the filesystem is isolated, Desktop Commander requires access to user files for editing and management. The solution uses Docker bind-mounts to selectively expose host directories.

### Linux Installation and Volume Binding

The **[`install-docker.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh)** script in the repository root automates container initialization with the host home directory mounted inside the container. The script executes a Docker run command with the `-v "$HOME:$HOME"` flag, which maps the host's home directory to an identical path inside the container:

```bash
docker run \
  --rm \
  --name desktop-commander \
  -p 8080:8080 \
  -v "$HOME:$HOME" \
  -e "HOME=$HOME" \
  desktop-commander:latest

```

The `-e "HOME=$HOME"` parameter propagates the environment variable, ensuring that shell references to `~` resolve to the mounted host directory rather than the container's default home.

### Windows PowerShell Installation

For Windows environments, the **`install-docker.ps1`** script performs equivalent configuration using PowerShell syntax. It mounts the user profile directory via `-v "${env:USERPROFILE}:${env:USERPROFILE}"`, enabling Windows users to access their documents and project folders from within the containerized application.

### Custom Mount Configurations

Users can override the default mount behavior by specifying custom paths when invoking the Docker command directly. To expose a specific project directory rather than the entire home folder:

```bash
docker run --rm -p 8080:8080 \
  -v "/path/to/project:/workspace" \
  -e "HOME=/workspace" \
  desktop-commander:latest

```

This configuration mounts `/path/to/project` to `/workspace` inside the container and sets the `HOME` environment variable accordingly, restricting file access to only the designated directory.

## Security Controls and Blocked Commands

Desktop Commander implements additional safeguards through command filtering. The **`rules/desktop-commander-default.mdc`** file defines a blocked-commands list that prevents execution of destructive operations such as `rm -rf /` inside the container. This security layer complements the Docker isolation by preventing accidental or malicious filesystem operations even within the mounted directories.

## Summary

Desktop Commander's Docker implementation provides a secure execution environment through multiple isolation layers:

- **Namespace isolation** separates process trees and network stacks between container and host
- **Read-only root filesystem** prevents modification of container system files as configured in `Dockerfile`
- **Non-root execution** runs the application as the `node` user to limit privilege escalation
- **Bind-mount restrictions** limit host file access to user-specified directories via [`install-docker.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh) and `install-docker.ps1`
- **Command blocking** filters dangerous operations via security rules in `rules/desktop-commander-default.mdc`

## Frequently Asked Questions

### How does Desktop Commander prevent container processes from accessing the host system?

Desktop Commander utilizes Docker's **PID namespace isolation** and **network namespace isolation** to ensure containerized processes operate in an isolated environment. The container cannot view host processes or access the host network stack beyond the explicitly exposed port 8080, as configured in the container runtime parameters defined in [`install-docker.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh).

### What is the default host directory exposed to Desktop Commander containers?

By default, the installation scripts mount the user's home directory into the container using the `-v "$HOME:$HOME"` flag on Linux or `-v "${env:USERPROFILE}:${env:USERPROFILE}"` on Windows. This bind-mount makes the entire home directory available at the identical path inside the container while the rest of the host filesystem remains inaccessible.

### Why does Desktop Commander run containers with a read-only root filesystem?

The **read-only root filesystem** prevents the containerized application from modifying system binaries, installing unauthorized software, or altering container configuration files. This security measure, defined in the `Dockerfile`, ensures that even if the application is compromised, the attacker cannot persist changes to the container environment or escalate privileges through system file manipulation.

### Can I restrict Desktop Commander to access only a specific project folder?

Yes. Instead of using the default installation scripts, you can launch the Docker container with a custom volume mount pointing to a specific directory: `-v "/path/to/project:/workspace"` with the corresponding environment variable `-e "HOME=/workspace"`. This configuration restricts the application to accessing only the mounted project folder rather than the entire home directory.