When attaching to a remote container using Cursor (via Remote-SSH and Dev Containers), Cursor attempts to run docker info inside the container, rather than on the remote host. Since most containers do not include Docker or the Docker socket, this results in the error: spawn docker ENOENT This breaks the container development workflow, even though Docker is properly installed and working on the host system.
Steps to Reproduce
Open Cursor on your local machine.I am connecting from Windows to a TencentOS server via Remote-SSH.
Use Remote-SSH to connect to a remote Linux server that has Docker installed on the host.
In the Remote Explorer sidebar, locate an already running Docker container on the remote host.
Use the “Attach to Container” action to connect to the container.
Cursor tries to execute docker info inside the container.
This results in the error:
spawn docker ENOENT
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Hi @user247, this error means we were unable to find docker on the remote machine. We do not try to run docker inside the container itself. When connecting via SSH, we do source the standard ~/.bashrc, ~/.bash_profile, or ~/.profile files.
Could you ensure that the correct folders are on the PATH so the docker command will resolve?
Seeing this same thing. Also making Cursor unusable. At least for me, I confirmed that it’s trying to run the docker command on my laptop, not the remote machine, or the container. Seems like maybe “using local” is the important bit here. I’ve tried removing .cursor-server on the remote, clicking reinstall server, reloading, etc.
Hi @vinhowe and @user247, would you be able to share a screencast for how you are connecting to the docker over ssh container? It looks like there is an issue with how the window is being opened, which is causing it to try to use docker on the local machine (and thus fail).
Hi，@Profile - ravirahman - Cursor - Community Forum I connect to the remote server using Remote SSH, and then, from the Remote Explorer, I select a container that I had previously started. However, when I click “Attach in Current Window,” I encounter an error.
Looks like a recent update to the extension fixed this specific issue. I had to patch in --no-same-owner to the tar command, so tar -xf cursor-server.tar.gz --no-same-owner --strip-components ... in ~/.cursor/extensions/anysphere.remote-containers-1.0.18/dist/main.js, or I’d see a slew of issues like this when Cursor tries to install the server:
2025-07-21 13:19:15.507 [info] [server install] stderr: tar: bin/helpers: Cannot change ownership to uid 0, gid 0: Operation not permitted
2025-07-21 13:19:15.513 [info] [server install] stderr: tar: bin/cursor-server: Cannot change ownership to uid 0, gid 0: Operation not permitted
2025-07-21 13:19:15.521 [info] [server install] stderr: tar: bin/remote-cli/cursor: Cannot change ownership to uid 0, gid 0: Operation not permitted
2025-07-21 13:19:15.525 [info] [server install] stderr: tar: bin/remote-cli: Cannot change ownership to uid 0, gid 0: Operation not permitted
2025-07-21 13:19:15.525 [info] [server install] stderr: tar: bin: Cannot change ownership to uid 0, gid 0: Operation not permitted
2025-07-21 13:19:16.769 [info] [server install] stderr: tar: node: Cannot change ownership to uid 0, gid 0: Operation not permitted
2025-07-21 13:19:16.769 [info] [server install] stderr: tar: product.json: Cannot change ownership to uid 0, gid 0: Operation not permitted
but after that change, it seems to work fine for me. I can connect to my remote setup and use it as I’d expect. I don’t know if this hints at a more general fix or something is weird with my own setup.
