Can't attach Cursor to Docker Container

Describe the Bug

Via the “Remote - SSH Plugin” and “Dev Containers” Plugin published by Anysphere, I tried to attach my Cursor to a Docker container that I am running on a remote machine. Attaching the shell is no problem but attaching Cursor itself somehow does not work.

This is the output i am getting:

2025-06-07 14:17:41.074 [info] Event is:  null
2025-06-07 14:17:41.074 [info] Remote authority is:  ssh-remote+7b22686f73744e616d65223a226879647261227d
2025-06-07 14:17:41.074 [info] Getting remote exec server for authority: ssh-remote+7b22686f73744e616d65223a226879647261227d
2025-06-07 14:17:41.074 [info] Checking docker version
2025-06-07 14:17:41.229 [info] [docker info][stderr]: ERROR: Cannot connect to the Docker daemon at unix:///sybig/home/amm/.docker/run/docker.sock. Is the docker daemon running?
2025-06-07 14:17:41.230 [info] [docker info][stderr]: errors pretty printing info
2025-06-07 14:17:41.271 [error] Error running 'docker info' [docker info] Command failed with exit code 1: stdout: Client:
 Version:    24.0.7
 Context:    rootless
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.21.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.33.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:

If i manually run docker info on the machine i am connected to, it works. If i attach my shell it works.
I have the exact same workflow, same config files, same docker images/build process in VScode and it works flawlessly. However there we use the plugins Remote - SSH and Dev Contaienrs directly from Microsoft, which I sadly cannot install to Cursor. I don’t get what the error is and sadly Cursor becomes unusable for me then, because I need to work with the remote hardware.

Maybe someone has an idea, because I have none.

Steps to Reproduce

Install the Remote - SSH and the Dev Containers Plugins from Anysphere and try to attach to a running docker image on a remote server.

Expected Behavior

Cursor should attach to the remote container and then you can work with a GUI on your files and code.

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.0.0 (user setup)
VSCode Version: 1.96.2
Commit: 53b99ce608cba35127ae3a050c1738a959750860
Date: 2025-06-04T19:44:25.253Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100

Does this stop you from using Cursor

Yes - Cursor is unusable

Hi @mmb-bioinf, thank you for the detailed report. From the logs, it looks like Cursor has trouble connecting to the docker socket.

A few questions:

  • Can you confirm that the docker socket path is correct and that it is user accessible (you might need to add yourself to the docker group). It looks like it’s trying to use a user installation of rootless docker – is this intended?
  • Could you also share the output when you run docker info inside a terminal outside of cursor?
  • What is your remote environment? (Os, architecture)?

Hi, thank you for the quick response, here are my answers for your questions:

  • I don’t really know if the path is correct. I start the docker daemon via systemctl --user start docker and docker info delivers output, so I assume the docker daemon is running. It indeed should be a non-root user instance of docker, which is intended because I don’t have root access, its a GPU cluster only a few people use. I navigated to the path ~/.docker/run/ but there is not a single file in it, so no docker.sock file as well. VSCode manages the same task without problems though, which makes me think it has nothing to do with the docker installation on the cluster itself being faulty.

  • Running docker info in a separate terminal (not in cursor) delivers the same results. This is the output:

Client:
 Version:    24.0.7
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.21.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.33.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 4
  Running: 1
  Paused: 0
  Stopped: 3
 Images: 23
 Server Version: 24.0.7
 Storage Driver: fuse-overlayfs
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: nvidia runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 091922f03c2762540fd057fba91260237ff86acb
 runc version: v1.1.9-0-gccaecfc
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  rootless
  cgroupns
 Kernel Version: 6.1.0-31-amd64
 Operating System: Debian GNU/Linux 12 (bookworm)
 OSType: linux
 Architecture: x86_64
 CPUs: 256
 Total Memory: 1008GiB
 Name: hydra
 ID: 8a0ea6e4-dcf3-4bd2-b04f-006c28654b02
 Docker Root Dir: /scratch/docker_amm
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

WARNING: No cpuset support
WARNING: No io.weight support
WARNING: No io.weight (per device) support
WARNING: No io.max (rbps) support
WARNING: No io.max (wbps) support
WARNING: No io.max (riops) support
WARNING: No io.max (wiops) support
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
  • The remote environment is the following: Debian 12 x86_64 6.1.0-31.amd64.

  • Additional Information: I do one SSH ‘hop’ to connect to finally ssh to this cluster. In the actual workplace, i can just ssh via one step and Cursor worked well with attaching to the exact same container there last week iirc. So it might have to do something with the SSH config or just a newer version of Cursor and Plugins. Here is my config file for the SSH ‘hop’:

Host hydra
    HostName hydra
    User amm
    ProxyCommand ssh -p 2525 [email protected] -W %h:%p
  • I just tried doing the same on a fresh install of Cursor on Fedora 40 on a second system (also with this ssh hop). I got following error:

(Sorry for the image, cant copy/paste in there, it says “couldnt execute command ,file or dir is missing” in German. I remember something similar popping up on my Windows machine aswell, but I couldn’t reproduce it. It sounds to me that I have to install some kind of cursor-server components first? If it is so, how do I do it properly?

Hi @mmb-bioinf,

Hmm – it looks like the DOCKER_HOST that Cursor is using is incorrect. Is this variable, or DOCKER_PROFILE, being set inside a ~/.bashrc / ~/.bash_login / ~/.bash_profile / ~/.profile file?

Inside a terminal on your remote system (where the docker info worked successfully), could you run docker context inspect and share the output? That should show the path to the Docker socket (under Endpoints → docker → host).

Then, inside ~/.bash_profile, ~/.bash_login, or ~/.profile, can you then set DOCKER_HOST= to the path returned by the above command? Cursor will source these files on the remote, as it uses a login shell.

Regarding the 2nd error with the fresh install: yes, it looks like the server failed to install correctly. Could you double check that you’re using both the Anysphere Remote SSH and Anysphere Remote Containers plugins? Mixing and matching (e.g. VSCode Remote SSH and Anysphere Remote Containers, or visa-versa) isn’t supported.

  • In my ~/.bashrc I have three redundant lines of export DOCKER_HOST=unix:///run/user/2725/docker.sock.

  • docker context inspect delivers following result:

[
    {
        "Name": "default",
        "Metadata": {},
        "Endpoints": {
            "docker": {
                "Host": "unix:///run/user/2725/docker.sock",
                "SkipTLSVerify": false
            }
        },
        "TLSMaterial": {},
        "Storage": {
            "MetadataPath": "\u003cIN MEMORY\u003e",
            "TLSPath": "\u003cIN MEMORY\u003e"
        }
    }
]
  • The paths from both commands match. However they don’t match with original one (but may be translatable to it? )

  • You are right, somehow the Dev Containers Plugin from Microsoft was installed. Removed it and went with the one from Anysphere. Now i end up with the original error from my first bug report (at least its consistent).

Could you try adding the export DOCKER_HOST=unix:///run/user/2725/docker.sock to your ~/.bash_profile? I don’t think our extension is sourcing the ~/.bashrc (since we use a login shell).

I edited ~./bash_profile to this:

# ~/.bash_profile: executed by bash(1) for login shells.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/login.defs
umask 002

# include .bashrc if it exists
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
    PATH=~/bin:"${PATH}"
fi

# adding DOCKER_HOST manually for Cursor IDE Fix
export DOCKER_HOST=unix:///run/user/2725/docker.sock

It didn’t change the problem though. I also commented out the if case for including bashrc, didn’t change it either.