# How Docker Installation Provides Filesystem Isolation and Mount Options in Desktop Commander

> Learn how Docker installation provides filesystem isolation and mount options in Desktop Commander, creating sandboxed environments with persistent state and controlled host access.

- Repository: [Eduard Ruzga/DesktopCommanderMCP](https://github.com/wonderwhy-er/DesktopCommanderMCP)
- Tags: how-to-guide
- Published: 2026-08-03

---

**Docker installation in Desktop Commander creates a sandboxed container environment that completely isolates the application runtime from the host OS while using named volumes and selective bind mounts to maintain persistent state and controlled host filesystem access.**

Desktop Commander's Docker-based deployment is implemented in the `wonderwhy-er/DesktopCommanderMCP` repository. This approach ensures that all Node.js dependencies, system binaries, and package installations remain contained within the Docker environment, preventing any modification to the host's root filesystem. The isolation strategy relies on a minimal Alpine-based image and a sophisticated volume management system defined across two core files: `Dockerfile` and [`install-docker.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh).

## Filesystem Isolation Through Container Architecture

The foundation of Desktop Commander's isolation is a purpose-built Docker image that runs the entire application stack inside a private namespace.

### Dockerfile: Building the Isolated Runtime

In `Dockerfile` (lines 1–27), the build process establishes a clean separation from the host:

```dockerfile

# https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/Dockerfile

FROM node:lts-alpine
ENV MCP_CLIENT_DOCKER=true
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install --ignore-scripts
RUN npm rebuild @vscode/ripgrep
COPY . .
RUN npm run build
CMD ["node", "dist/index.js"]

```

**Key isolation mechanisms:**

- **`FROM node:lts-alpine`** — Uses a minimal 5 MB Alpine Linux base with Node.js pre-installed, eliminating any dependency on host OS libraries
- **`WORKDIR /usr/src/app`** — Establishes a private working directory invisible to the host filesystem
- **`ENV MCP_CLIENT_DOCKER=true`** — Signals to the application that it's running in containerized mode, enabling Docker-specific behaviors
- **Layered `COPY` and `RUN` commands** — All build operations occur inside container layers; the host only stores the final image

### Transient Container Execution

The [`install-docker.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh) script (line 48) appends `--rm` to every `docker run` invocation:

```bash
DOCKER_ARGS=("run" "-i" "--rm")

```

This flag ensures that **each command executes in a fresh container instance** that is automatically destroyed on exit. Any file system changes not persisted to named volumes are discarded, providing process-level isolation.

## Persistent Storage Through Named Volumes

To maintain state across container restarts without breaking isolation, Desktop Commander uses **four named Docker volumes** defined in the `ESSENTIAL_VOLUMES` array.

### Volume Creation in setup_persistent_volumes()

In [`install-docker.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh) (lines 19–24), the `setup_persistent_volumes()` function creates dedicated storage namespaces:

```bash

# https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh#L19-L24

ESSENTIAL_VOLUMES=(
    "dc-system:/usr"
    "dc-home:/root"
    "dc-workspace:/workspace"
    "dc-packages:/var"
)
for volume in "${ESSENTIAL_VOLUMES[@]}"; do
    volume_name=$(echo "$volume" | cut -d':' -f1)
    docker volume create "$volume_name" >/dev/null
done

```

| Volume Name | Container Mount | Purpose |
|-------------|---------------|---------|
| `dc-system` | `/usr` | System packages and installed binaries |
| `dc-home` | `/root` | User configuration, SSH keys, Git settings |
| `dc-workspace` | `/workspace` | Development projects and working files |
| `dc-packages` | `/var` | Package caches, logs, and temporary data |

These volumes are **Docker-managed storage** that persists on the host's Docker data directory—not in the host's root filesystem or user home. This design prevents "dependency pollution" where tools installed inside the container would otherwise leak into the host environment.

## Controlled Host Access Through Bind Mounts

Desktop Commander selectively exposes host directories through **bind mounts** that translate user-selected folders into the container's `/home` namespace.

### build_docker_args(): Mount Path Normalization

In [`install-docker.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh) (lines 48–64), the `build_docker_args()` function handles path translation:

```bash

# https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh#L48-L64

DOCKER_ARGS=("run" "-i" "--rm")

# attach essential volumes

for volume in "${ESSENTIAL_VOLUMES[@]}"; do
    DOCKER_ARGS+=("-v" "$volume")
done

# attach user-chosen folders

for folder in "${FOLDERS[@]}"; do
    if [[ "$folder" =~ ^/Users/[^/]+(/.+)$ ]]; then
        absolute_path="${BASH_REMATCH[1]}"
        DOCKER_ARGS+=("-v" "$folder:/home$absolute_path")
    elif [[ "$folder" =~ ^/home/[^/]+(/.+)$ ]]; then
        absolute_path="${BASH_REMATCH[1]}"
        DOCKER_ARGS+=("-v" "$folder:/home$absolute_path")
    else
        folder_name=$(basename "$folder")
        DOCKER_ARGS+=("-v" "$folder:/home/$folder_name")
    fi
done
DOCKER_ARGS+=("$DOCKER_IMAGE")

```

**Mount path translation logic:**

1. **macOS paths** (`/Users/<username>/...`) — Strips the `/Users/<username>` prefix and remaps to `/home/<remainder>`
2. **Linux paths** (`/home/<username>/...`) — Strips the `/home/<username>` prefix and remaps to `/home/<remainder>`
3. **Other paths** — Uses `basename` to create `/home/<folder_name>`

This normalization ensures a consistent `/home` structure inside the container regardless of the host OS, while the **bash regex patterns** explicitly constrain which host paths can be exposed.

## Complete Isolation vs. Access Trade-offs

Desktop Commander's Docker installation implements a **defense-in-depth** strategy for filesystem security:

- **Complete isolation** — Runtime, dependencies, and system modifications occur only in the `node:lts-alpine` image and named volumes
- **Explicit access** — Host filesystem exposure requires affirmative user selection during [`install-docker.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh) execution
- **Path sandboxing** — All bind mounts are routed through `/home`, preventing accidental exposure of sensitive host paths like `/etc`, `/usr`, or `/var`

The `MCP_CLIENT_DOCKER=true` environment variable enables the application to recognize its containerized context and adjust behavior accordingly—for example, by avoiding operations that would require host-level privileges.

## Summary

- **Isolation core** — `Dockerfile` builds a minimal `node:lts-alpine` image with a private `/usr/src/app` working directory
- **Named volumes** — `dc-system`, `dc-home`, `dc-workspace`, and `dc-packages` provide persistent, Docker-managed storage for configuration and packages
- **Bind mount controls** — `build_docker_args()` in [`install-docker.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh) normalizes user-selected folders into `/home` with regex-constrained path translation
- **Transient execution** — `--rm` flag ensures fresh containers per command, discarding uncommitted changes
- **Zero host pollution** — All package installations and system modifications remain in named volumes, never touching the host root filesystem

## Frequently Asked Questions

### What happens to data stored outside the four named volumes?

Data written outside `/usr`, `/root`, `/workspace`, `/var`, or bind-mounted `/home` paths is **lost when the container exits**. The `--rm` flag destroys the container instance, and only named volumes and bind mounts persist. Applications should be configured to write to `/workspace` or bind-mounted directories for durable storage.

### Can I add additional host folders after initial installation?

Yes. Re-run [`install-docker.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install-docker.sh) and specify new folders when prompted. The script regenerates the Docker run configuration in Claude's MCP settings, and the new bind mounts take effect on the next Desktop Commander invocation. Existing named volumes retain their data.

### Why does Desktop Commander use `/home` instead of the host's home path inside the container?

The `/home` normalization provides **cross-platform consistency**. macOS users with `/Users/alice/projects` and Linux users with `/home/alice/projects` both see their files at `/home/projects` inside the container. This simplifies documentation, debugging, and MCP configuration portability between operating systems.

### Is the Docker installation more secure than the standard install.sh method?

According to the Desktop Commander source code, **Docker installation provides stronger filesystem isolation**. The standard [`install.sh`](https://github.com/wonderwhy-er/DesktopCommanderMCP/blob/main/install.sh) runs natively with full host filesystem access and can modify system packages directly. The Docker approach constrains all runtime activity to the container namespace with explicit, user-controlled host directory exposure.