SSH forwarding doesn't work with dev containers on Windows

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

SSH forwarding doesn’t work with dev containers on Windows.

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

Same devcontainer config in VSCode, using dev containers extension 0.447.0:

$ ssh -T [email protected]
Hi ...! You've successfully authenticated, but GitHub does not provide shell access.

Steps to Reproduce

  1. Have a working SSH key on Windows
  2. Ensure SSH Agent runs:
Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent
Get-Service ssh-agent
  1. Add ssh key to agent (ssh-add -l should list it):
ssh-add
ssh-add -l
  1. Open any workspace in a dev container and run ssh -T [email protected]

Expected Behavior

See logs above.

Operating System

Windows 10/11

Version Information

Version: 2.6.22 (system setup)
VSCode Version: 1.105.1
Commit: c6285feaba0ad62603f7c22e72f0a170dc8415a0
Date: 2026-03-27T15:59:31.561Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @AndyO! Thanks for reporting this!

Two quick questions:

  1. What version of the anysphere.remote-containers extension are you using?
  2. When you run ssh -T [email protected] inside the container, does it hang indefinitely or does the “Permission denied” error appear immediately?

This looks like it may be the same issue as SSH agent forwarding hangs in devcontainers on Windows (fs.readFileSync blocks on named pipe), where the SSH agent forwarder deadlocks when trying to read the Windows named pipe. If ssh -T hangs rather than returning immediately, that would confirm it’s the same root cause.

6
  1. 1.0.32
  2. Immediately. ssh-add-l also immediately shows “Could not open a connection to your authentication agent.”
7

Thanks @AndyO! That points to a slightly different issue, then. Could you try running these commands in the container and let me know the output of each?

echo $SSH_AUTH_SOCK
ls -la $SSH_AUTH_SOCK 2>&1
ssh-add -l 2>&1
8 
node ➜ /workspaces/neev-chat (dev) $ echo $SSH_AUTH_SOCK       

node ➜ /workspaces/neev-chat (dev) $ ssh-add -l 2>&1
Could not open a connection to your authentication agent.

ls -la ... would just list the workspace contents.

Since I know that getting rid of $SSH_AUTH_SOCK can be done, I should point out that I’m not doing that (Well, that would probably stop it from working in vscode too. And like I said, it works there.). This is my current container config:

{
  "image": "mcr.microsoft.com/devcontainers/javascript-node:24",

  "features": {
    "ghcr.io/devcontainers-extra/features/direnv:1": {},
    "ghcr.io/devcontainers/features/kubectl-helm-minikube:1": {},
    "ghcr.io/devcontainers-extra/features/pulumi:1": {}
  },

  "postCreateCommand": "git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions && git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting && sed -i 's/^plugins=(.*)/plugins=(git direnv kubectl zsh-autosuggestions zsh-syntax-highlighting)/' ~/.zshrc",

  "customizations": {
    "vscode": {
      "settings": {
        "terminal.integrated.defaultProfile.linux": "zsh"
      },
      "extensions": [
        "formulahendry.auto-rename-tag",
        "ms-playwright.playwright",
        "oxc.oxc-vscode",
        "rimuruchan.vscode-fix-checksums-next",
        "s-h-a-d-o-w.serenade",
        "s-h-a-d-o-w.theme-notepadplusplusremixed",
        "s-h-a-d-o-w.vscode-custom-css"
      ]
    }
  }
}
9

Thanks for checking @AndyO!

It’s a bit hard to debug since I don’t have a bare metal Windows machine around (and running Docker in Parallels is a nightmare).

One interesting thing to note is that we have record of a bug where oh-my-bash caused issues forwarding SSH_AUTH_SOCK. I see you have oh-my-zsh installed in the dev container. There could be something similar going on here.

Would be really interested to see if you stripped down the dev container (removing customizations, features, etc.) to just the image defined, and then checked whether SSH_AUTH_SOCK is set at all inside the container (echo $SSH_AUTH_SOCK).

I know it should work as smoothly as VSCode, but if it works with just the image, we can bisect which customization causes the problem. If it still doesn’t work, it’s back to the drawing board.

10

Cheap cloud server, billable by the minute/hour?
Or a Windows CI agent? Probably tougher to get that going. But you would then have a regression test.

That said, I’ll give your suggestion a shot. But I got sick today, so it might take a bit.