Dev Containers: "Clone Repository in Container Volume" always fails on Windows — ~/.ssh bind-mounted with 0777, OpenSSH rejects config/keys

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Dev Containers: Clone Repository in Container Volume (and the Named Volume variant) in the Dev
Containers extension (anysphere.remote-containers) can never succeed on a Windows host when cloning
over SSH.

The extension clones by spawning a helper container and bind-mounting the host’s .ssh directory
directly (from the “Remote - Dev Containers” output panel):

docker run --rm -v <volume>:/workspace -v C:\Users\<user>\.gitconfig:/root/.gitconfig:ro -v
C:\Users\<user>\.ssh:/root/.ssh:ro -e GIT_TERMINAL_PROMPT=0 alpine/git clone
ssh://[email protected]:2222/org/repo.git /workspace/repo

On Windows, bind mounts appear inside Linux containers with mode 0777. OpenSSH hard-fails on a
world-writable config file and silently ignores world-readable private keys, so the clone aborts:

Cloning into '/workspace/repo'...
Bad owner or permissions on /root/.ssh/config
fatal: Could not read from remote repository.

The failure happens even when ~/.ssh/config is an empty file (ssh checks permissions before
reading). Deleting the config file doesn’t help either: authentication then fails because the 0777
private keys are refused as well. So any Windows user with a standard ~/.ssh directory hits this.

This is related to, but distinct from, SSH forwarding doesn’t work with dev containers on Windows: that
one is about agent forwarding inside a running container; this one is the clone bootstrap helper
container, which doesn’t use the agent at all.

Suggested fix — any of these would work:

  1. In the helper container, copy the ssh material to a container-local path and chmod 600 it
    before running git (e.g. wrap the clone in sh -c "cp ... && chmod 600 ... && git clone ..."), or
  2. Use ssh-agent forwarding (Windows OpenSSH agent named pipe) like
    ms-vscode-remote.remote-containers does, or
  3. At minimum, detect the situation and show an actionable error instead of the raw git failure.

Workaround for anyone else hitting this: manually clone into the volume the extension already
created (copy the key inside the container so it can be chmod’ed), then re-run the command and pick
“Reuse existing files” when prompted:

docker run --rm -v <volume>:/workspace -v C:\Users\<user>\.ssh:/host-ssh:ro --entrypoint sh
alpine/git -c "cp /host-ssh/id_ed25519 /k && chmod 600 /k && GIT_SSH_COMMAND='ssh -i /k -F none -o
StrictHostKeyChecking=accept-new' git clone ssh://[email protected]:2222/org/repo.git
/workspace/repo"

If the dev container runs as a non-root user, also chown -R 1000:1000 the volume afterwards.

Steps to Reproduce

  1. On a Windows host with Docker Desktop, have a standard ~/.ssh directory (a config file — even
    an empty one — and/or private keys).
  2. In Cursor, open the command palette and run Dev Containers: Clone Repository in Container
    Volume    .
  3. Enter an SSH repository URL, e.g. ssh://[email protected]:2222/org/repo.git.
  4. The volume is created, then the clone step fails with Bad owner or permissions on /root/.ssh/config (or Permission denied (publickey) if no config file exists).

Expected Behavior

The repository is cloned into the volume and the dev container is built — as happens with
ms-vscode-remote.remote-containers on the same machine, which uses ssh-agent forwarding for this
flow instead of bind-mounting ~/.ssh.

Operating System

Windows 10/11

Version Information

Version: 3.9.8 (system setup)
VS Code Extension API: 1.105.1
Commit: 4aa8ff1b7877ed7bd01bcba308698f71a6735380
Date: 2026-06-25T01:39:30.490Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. You don’t often see this level of breakdown with logs, the exact Docker command, and a ready workaround. It really helps.

Yep, this is a real client-side bug in the Dev Containers extension. The clone helper bind-mounts ~/.ssh, and on Windows Docker Desktop the mounts end up with mode 0777, so OpenSSH rejects the config file and keys. You’re also right to separate this from agent forwarding into an already running container, that’s a different code path.

I logged it internally as a separate issue. I can’t share an ETA for a fix yet, but I’ll post an update in the thread as soon as I have one.

Your workaround (manually cloning into a volume with chmod 600, then choosing “Reuse existing files”) is valid. As alternatives, you can clone the repo locally and open it via “Reopen in Container”, or use an HTTPS + token URL instead of SSH. Both options avoid the ~/.ssh bind-mount.