SSH forwarding doesn’t work with dev containers

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Same as described here: SSH forwarding doesn't work with dev containers on Windows

But I’ve since moved to Linux and am experiencing the same problem, with a minor difference. When running the commands @Colin requested, I’m getting a different result:

echo $SSH_AUTH_SOCK
ls -la $SSH_AUTH_SOCK 2>&1
ssh-add -l 2>&1

/tmp/cursor-remote-ssh-54ac9a7d-49c0-4564-9d4e-5be4943f2c54.sock
lrwxrwxrwx 1 root root 64 Jun 25 17:39 /tmp/cursor-remote-ssh-54ac9a7d-49c0-4564-9d4e-5be4943f2c54.sock -> /tmp/cursor-remote-ssh-fbc04176-8468-49cd-8960-df4d985bda90.sock
The agent has no identities.

Steps to Reproduce

  1. Have a working github SSH setup that you know works in Cursor.
  2. Use any dev container and run ssh -T [email protected].

Expected Behavior

SSH connection to github should be successful.

Operating System

Linux

Version Information

Version: 3.8.24
VS Code Extension API: 1.105.1
Commit: cf80f4b937f3b9c48070d7085129a838ce7876a0
Date: 2026-06-24T06:55:08.142Z
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: Linux x64 6.17.0-35-generic

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the details and for moving the report over from the Windows thread. This is a known issue with SSH agent forwarding in dev containers. The symptom is exactly what you’re seeing: the proxy socket /tmp/cursor-remote-ssh-*.sock comes up and responds, but the identities don’t make it into the container. We’re tracking this on our side, but there’s no ETA for a fix yet.

To confirm it’s the forwarding and not that your keys aren’t loaded locally, run this on the local host, not inside the container:

ssh-add -l

If you see identities there, but inside the container you get “The agent has no identities”, that’s this bug.

Since you’re on Linux right now, as a workaround you can try binding the host agent socket directly via devcontainer.json:

"remoteEnv": {
  "SSH_AUTH_SOCK": "${localEnv:SSH_AUTH_SOCK}"
},
"mounts": [
  "source=${localEnv:SSH_AUTH_SOCK},target=${localEnv:SSH_AUTH_SOCK},type=bind"
]

This won’t cover every setup. For example, it may not work with 1Password or some third party agents, but for the standard ssh-agent on macOS and Linux it usually helps.

Important: this won’t work on Windows. There SSH_AUTH_SOCK is a named pipe \\.\pipe\openssh-ssh-agent, and you can’t bind-mount that into a Linux container. So if you switch back to a Windows host, this workaround won’t work there.

Let me know how it goes, and please share the output of ssh-add -l from your local host.

6

This one was my bad. I forgot that there’s this whole setup routine to go through: Sharing Git credentials with your container

(That guide is flawed but I got everything to work eventually.)