Run node-code-sandbox on Windows — Docker Volumes & claude_desktop_config

Practical, Windows-first configuration and troubleshooting for node-code-sandbox: claude_desktop_config.json setup, Docker Desktop file sharing, volume mounting, named pipes and Windows vs Linux path differences.

Quick summary (featured-snippet friendly)

If you want node-code-sandbox to run reliably on Windows: ensure Docker Desktop file sharing is enabled for the host folders, place your claude_desktop_config.json in a host folder and bind-mount it into the container, and use the correct Windows syntax or WSL2 paths for volume mounts. For Docker daemon access from inside containers, mount the Windows named pipe and set DOCKER_HOST to the npipe path. See commands and examples below.

If you prefer a one-click resource: the upstream documentation and an example build are hosted here: node-code-sandbox Windows configuration.

Preparing Windows and Docker Desktop

Before you bind-mount code and configs into a container, set up Docker Desktop on Windows correctly. Open Docker Desktop > Settings > Resources > File Sharing (or the equivalent in newer builds) and add the host drives or specific folders you will mount. Without that, Docker will refuse access or silently fail to mount volumes.

On Windows 10/11 with WSL2 backend, you have two common workflows: mount NTFS paths directly from PowerShell (C:\path\to\dir) or use WSL2-mounted paths (/mnt/c/path). For reliability with node-code-sandbox, choose one and stick to it. Mixing path styles can introduce permission issues when the container expects a Linux UID or file mode.

Make sure Docker Desktop is running with WSL2 integration enabled if you want seamless Linux-style behavior. If your environment uses Hyper-V or legacy backends, paths and bind mounts behave differently — you’ll need to adjust permissions and possibly use shared network paths.

Setting up claude_desktop_config.json

node-code-sandbox typically reads a JSON config file for desktop-specific settings. Create a minimal claude_desktop_config.json on your host, validate it with a JSON linter, and then mount it into the container’s expected config path, for example /srv/app/config/claude_desktop_config.json. Treat the file as code: version it, and prefer a read-only mount so the container can’t accidentally overwrite your local config.

Example minimal contents (adjust per project):

{
  "desktopMode": true,
  "workspacePath": "/srv/app/workspace",
  "features": { "autoSave": false }
}

Mounting the config into the container (PowerShell example):

docker run --name node-code-sandbox -v C:\projects\my-sandbox\config\claude_desktop_config.json:/srv/app/config/claude_desktop_config.json:ro -it node-code-sandbox:latest

Note: use :ro to make the file read-only inside the container. If you use Docker Compose, prefer the long syntax to avoid path escaping problems on Windows.

Docker volume mounting: Windows paths vs Linux paths

Bind-mounting host folders is where Windows vs Linux differences bite you most. In PowerShell use backslashes and escape them when necessary, or wrap the path in quotes. In WSL2 or Git Bash, use POSIX-style paths. Example comparison:

• PowerShell / CMD: -v C:\Users\you\project:/srv/app
• WSL2 / Bash: -v /mnt/c/Users/you/project:/srv/app

If node-code-sandbox expects executable bits or symlinks, prefer WSL2 mounts since native Windows mounts can lose Unix file mode semantics. Conversely, if you need to edit files with Windows editors and the container must reflect changes immediately, PowerShell-style mounts are simpler.

Compose example (Windows-friendly long syntax):

services:
  sandbox:
    image: node-code-sandbox:latest
    volumes:
      - type: bind
        source: C:\projects\my-sandbox
        target: /srv/app

Always check container user IDs. If files appear owned by root and your container writes fail, either run the container process as a non-root user or map permissions appropriately on startup.

Named pipes and Docker daemon access on Windows

Containers that need to control Docker on the host must reach the Docker daemon. On Linux this is the Unix socket (/var/run/docker.sock). On Windows, Docker exposes a named pipe at \\\\.\\pipe\\docker_engine. You can mount that pipe into containers to emulate socket access.

Example (PowerShell):

docker run -v \\.\pipe\docker_engine:\\.\pipe\docker_engine -e DOCKER_HOST=npipe:////./pipe/docker_engine -it node-code-sandbox

This mounts the host named pipe into the container and sets DOCKER_HOST so Docker clients inside the container know how to reach the daemon. Use this carefully: granting a container control of the host Docker daemon is powerful and risky from a security perspective.

Running node-code-sandbox container: combined example

A practical run command that wires up a project directory, the config file, and Docker named-pipe access looks like this in PowerShell:

docker run --name node-code-sandbox -it `
  -v C:\projects\my-sandbox:/srv/app `
  -v C:\projects\my-sandbox\config\claude_desktop_config.json:/srv/app/config/claude_desktop_config.json:ro `
  -v \\.\pipe\docker_engine:\\.\pipe\docker_engine `
  -e DOCKER_HOST=npipe:////./pipe/docker_engine `
  node-code-sandbox:latest

This command expects Docker Desktop to allow access to C:\projects\my-sandbox under File Sharing. Replace paths to match your workspace. If you prefer Docker Compose, translate the mounts into the compose file’s volumes section using bind/type entries to preserve clarity on Windows.

For WSL2 users, simply use the WSL path for the project folder: /mnt/c/projects/my-sandbox:/srv/app and omit the Windows named-pipe mount unless you specifically need the host daemon.

Troubleshooting, tips and common pitfalls

When mounts silently fail, manifest problems are usually one of these: Docker Desktop file sharing not granted, wrong path syntax, permission mismatch (UID/GID), or stale cached images. Always inspect container logs and check mount points with docker exec -it <container> ls -la /srv/app.

• Enable Docker Desktop file sharing for your drive and restart Docker.
• Check the container’s user and adjust file permissions or use the --user flag.
• Use read-only mounts for config files (append :ro) to avoid accidental overwrites.

If named-pipe access fails, confirm Docker Desktop exposes the named pipe and that no antivirus or policy blocks inter-process pipe mounts. Also, some container base images lack the tools to talk natively to a Windows Docker daemon — ensure the container has a compatible Docker client or use remote API alternatives.

Backlinks and references

Official example and extended documentation are available for review: node-code-sandbox Windows configuration (example). For step-by-step config templates, see the sample claude_desktop_config.json setup and a runnable demo for running node-code-sandbox container.

Expanded Semantic Core (grouped)

Use this keyword map for on-page optimization, internal linking, and anchor text strategy.

Primary queries

node-code-sandbox Windows configuration; claude_desktop_config.json setup; Docker volume mounting Windows; configuring node-code-sandbox Docker; Docker Desktop file sharing Windows; running node-code-sandbox container

Secondary queries

Docker paths Windows vs Linux; Docker named pipes Windows; mount Windows folder into container; bind mount Windows Docker; Windows Docker named pipe mount; DOCKER_HOST npipe

Clarifying / Intent-based phrases

how to mount volumes in Docker Windows; where to put claude_desktop_config.json; docker-compose windows volumes syntax; WSL2 mount examples; permission issues Windows Docker; read-only config mount

LSI / Synonyms

bind mount, volume mount, host path, container path, named pipe, npipe, Docker socket, Unix socket, WSL2 integration, file sharing settings

Voice-search and snippet-friendly phrases

“How do I mount a Windows folder into a Docker container?”, “Where to place claude_desktop_config.json?”, “How to let a container use my Windows Docker daemon?”

FAQ

How do I mount a Windows folder into the node-code-sandbox container?

Use a bind mount. In PowerShell: -v C:\path\to\project:/srv/app. In WSL2: -v /mnt/c/path/to/project:/srv/app. Ensure Docker Desktop file sharing allows the host folder, and consider :ro for config files to avoid accidental writes.

Where should I place claude_desktop_config.json and how do I mount it?

Place it on the host in your project config directory (e.g., C:\projects\my-sandbox\config\claude_desktop_config.json) and mount it into the container where the app expects it (e.g., /srv/app/config/claude_desktop_config.json:ro). Validate JSON and use read-only mounts if the container should not modify the file.

Can a container access the Windows Docker daemon via named pipes?

Yes. Mount the host named pipe \\\\.\\pipe\\docker_engine into the container and set DOCKER_HOST=npipe:////./pipe/docker_engine. Example: -v \\\\.\\pipe\\docker_engine:\\\\.\\pipe\\docker_engine -e DOCKER_HOST=npipe:////./pipe/docker_engine. Use with caution—it’s equivalent to granting the container control over the host Docker service.