SSH Forwarding broken in new Dev Containers extension

[Noland]

Describe the Bug

Bug Summary

When using devcontainers in Cursor IDE on Linux, SSH agent forwarding does not work as expected. Even though my host SSH agent has identities loaded and I specify the correct agent socket to mount in my .devcontainer.json, SSH keys are not available inside the container terminal.

---

Details

• Host:
  $SSH_AUTH_SOCK points to a standard Unix socket with loaded keys, verified with ssh-add -l.

• .devcontainer.json includes:

  "mounts": [
    "type=bind,source=${env:SSH_AUTH_SOCK},target=/ssh-agent"
  ],
  "remoteEnv": {
    "SSH_AUTH_SOCK": "/ssh-agent"
  }
  

• Inside the container:

  • The /ssh-agent socket exists and is a socket file.
  • Running export SSH_AUTH_SOCK=/ssh-agent && ssh-add -l shows “The agent has no identities”.
  • By default, $SSH_AUTH_SOCK is set to something like /tmp/cursor-remote-ssh-xxxx.sock, which is a symlink to another socket, but neither this proxy nor the mounted /ssh-agent provide access to my host’s SSH keys.

• Comparison:
  The same configuration works as expected in upstream VS Code with Remote - Containers.

---

What seems to be going wrong

• Cursor creates and assigns its own SSH_AUTH_SOCK relay/proxy inside the container (/tmp/cursor-remote-ssh-...) rather than using the mounted /ssh-agent as defined in the devcontainer config.
• Neither the Cursor relay nor the explicitly mounted /ssh-agent provide access to the identities in my host’s actual ssh-agent—the agent appears empty inside the container terminal.
• This suggests that agent socket forwarding or handling is not compatible with the standard VS Code Remote - Containers approach, and neither the user-specified mount nor Cursor’s relay is passing through the host’s loaded keys.

---

Request

• Please investigate and improve SSH agent forwarding in devcontainers so that:
  1. The mounts and remoteEnv configuration in .devcontainer.json are honored.
  2. The internal agent socket provides access to the host’s actual loaded SSH identities.
  3. SSH-based Git and other tools inside the container terminal have the same transparent access to host agent keys as in standard VS Code.

Steps to Reproduce

Install Anysphere dev containers and try to get SSH forwarding to work.

Expected Behavior

Works like VS Code

Operating System

Linux

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.3.5
VSCode Version: 1.99.3
Commit: 9f33c2e793460d00cf95c06d957e1d1b8135fad0
Date: 2025-07-30T00:32:27.448Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Linux x64 6.8.0-71-generic

Does this stop you from using Cursor

No - Cursor works, but with this issue

[Noland]

The problem seems to be more specific to domain aliases in ~/.ssh/config. They resolve correctly on the host but fail to resolve within the dev container.

[Maxence_Boutet]

Same/similar issue on my end. Works perfectly fine in vanilla VS Code. Only difference with OP is that I don’t mount the SSH_AUTH_SOCK from my host and I usually let VS Code handle forwarding the agent inside the dev container automatically.

[fcFn]

Could broken gpg agent forwarding also be related? The same repo in VS Code signs commits alright for me while in Cursor it cannot find the secret key.