Anyspheres Dev Container Extension: Use the Name Property of DevContainers + Allow to Switch Containers

[Polarising]

For Work I need to use DevContainers. As you now released your own version of DevContainers I tried to do the switch but there is one very simple but important usability feauture missing:

Showing the Names of the Containers by their “Name” Property instead of just showing the different Containers by the Path of their DevContainer file.

Example how it looks with your Extension, despite the different devcontainer files having the props needed to distinct them better, even worse in this case the paths are so long that I cannot even distinct them as the path cuts off before anything is different

Additionally DevContainers currently do not have a simple “Switch Container” command over Ctrl+Shift+P like Microsofts Extension does, which actually makes it unusable for my work

[ravirahman]

Hi @Polarising , thank you for sharing this issue – realizing how frustrating this can be. We’re working on an update to show the name in addition to the file path, and to add that “Switch Container” command. Will let you know when this is out!

[ravirahman]

Hi @Polarising – we just shipped version 1.0.7 of the remote containers extension that shows the container name (if present) in that selector, and also implements the “switch container” command.

[Polarising]

Thank you for the quick update!

The update is almost fully functional; however, I noticed a discrepancy compared to the behavior of Microsoft’s devcontainers.

In my setup, I have a folder containing a ./devcontainer directory, along with several subfolders related to different devcontainers. When switching to one of the devcontainer configurations, I end up in one of these subfolders. Since these subfolders do not individually contain their own ./devcontainer directory (the ./devcontainer folder is located one level up in the hierarchy), the Switch Container command no longer works as expected—it fails to locate the ./devcontainer folder.

This setup used to work seamlessly with VS Code, allowing me to switch between containers without issue. Now, I am required to reopen the original devcontainer and then manually open the others, which still doesn’t fully address my workflow needs.

Additionally, not sure if its an issue on my end, but the SSH-Key forwarding does not seem to work like in VSCode, as my same config that used to work with the previous Extensions now does not work anymore. Your Extensions docks also still reference the same docs as the original vscode Extension so I assume there currently is an Issue with that ?

Best regards,
Polarising

[ravirahman]

Hi @Polarising – just to clarify, do you have a .devcontainer or devcontainer folder? As per the spec, the folder needs to be called .devcontainer.

Nested files do show up for me when using “Switch Container”. We do require that the .devcontainer folder is mounted within the container.

.

Additionally, not sure if its an issue on my end, but the SSH-Key forwarding does not seem to work like in VSCode, as my same config that used to work with the previous Extensions now does not work anymore.

Thanks for raising this. What platform are you on, and are you using Docker over SSH, or are you running Docker locally?

[Polarising]

Hey @ravirahman,

Thank you once again for the fast response

First about my “problematic” devcontainer setup:

I have a complex development environment with a main docker-compose.yml file that defines multiple application services:

project-root/
├── .devcontainer/
│ ├── docker-compose.yml
│ ├── app-0/ # Individual devcontainer configs
│ ├── app-1/
│ ├── legacy-app-0/
│ ├── legacy-app-1/
│ └── [... more services referencing the compose.yml in their own `devcontainer.json`]
└── [application code directories...] (e.g. legacy-app-0, legacy-app-1, app-0)

The Issue

Each subdirectory in .devcontainer/ contains its own .devcontainer.json that typically references a specific service from the main docker-compose.yml using something like:

{
"dockerComposeFile": "../docker-compose.yml",
"service": "legacy-app-0",
"workspaceFolder": "/project-root/legacy-app-0"
}

The Problem I’m Experiencing

When I open a container which in turn opens in one of the project-root subdirectories, Cursor doesn’t detect or properly use the .devcontainer configuration which now may reside in it`s parent repository, VSCode somehow used to work and remember the location of the .devcontainer folder (which now resides in its parent directory). If I have a service that also is present in the project-root it obviously finds it, but if the container opens in the application code directory it is unable to.

---

To the SSH-Key config

I am using Windows 11 with Docker installed locally, leveraging the WSL2 engine. Most of my Git repositories are cloned into WSL, opened there with Cursor, and then reopened in their specific devcontainers. I’ve noticed that, for some devcontainers, the SSH keys are successfully transferred because the SSH agent is detected. However, for the problematic setup I described, the SSH keys are not being passed, and the agent cannot be found.

→ After further testing and rebuilding the containers (without cache) where SSH key passing previously worked, I discovered that SSH key passing using SSH_AUTH_SOCK fails for all containers opened via Cursor. This happens despite my WSL terminal confirming that SSH_AUTH_SOCK is correctly set. I also followed the process for SSH key passing in PowerShell as a precaution, but that did not resolve the issue either.

[Polarising]

Another critical discrepancy I noticed is that, in VSCode DevContainers, the initialization command script for each container is executed in the Terminal tab. This allows me, as the user, to provide additional input if needed during the setup process. However, in Cursor, the script output is only displayed in the Output tab, which prevents me from interacting with the container during initialization. As a result, I am unable to open containers that require user interaction during their setup.

VScode:

Cursor:

[Polarising]

Sorry to bother, but any updates or any extra information needed ? @ravirahman

[ravirahman]

Hi @Polarising, appreciate the patience and apologies for the delay in getting back to you.

Re: The switch container command not finding the sub-files – we do require that the .devcontainer folder to be mounted within the container. Supporting files outside is not something that is currently on the roadmap

Re: SSH Key forwarding, this should be supported. Can you share the “Remote - Dev Container” logs so we can take a closer look? It’s likely that we are not detecting the SSH_AUTH_SOCK variable,

Re: Interactive initialization scripts, we are looking at what it would take to support this. In the meantime, I would recommend to make them non-interactive, or manually run them once inside the container.

[aeresov]

I can confirm, SSH foorwarding does not work.

Here is “Remote - Dev Container” logs from my machine.
Remote - Dev Containers.txt (251.3 KB)

[aeresov]

Also, setting container environment variables through devcontainer’s “remoteEnv” property does not work too.

[shauer]

Event setting them manually via "runArgs": [ "--env FOO=bar" ] does not seem to work.

[tl-jacob]

@ravirahman can also confirm that SSH agent forwarding is not working. Do you have any updates on a fix?

[colachg]

Same here—it took me two days to debug. The ssh-agent socket would time out and stop working, and the only way to fix it was to reload the window or restart the container.
The vscode/cursor process does not use the environment variables set in remoteEnv, as mentioned above.

[colachg]

My workaround is to disable the SSH agent forwarding feature in Dev Containers, mount the host’s SSH agent socket into the container, and set the remoteEnv SSH_AUTH_SOCK variable to point to it.

[ravirahman]

Hi all,

@colachg and @tl-jacob – we are looking into why the SSH_AUTH_SOCK times out / doesn’t auto reconnect. I’ve seen that I need to open a new terminal after a reconnection for the (new) socket to work, as the path may change and old terminals reference the old path.

@aeresov – from your logs, we didn’t detect the SSH_AUTH_SOCK variable in your environment. I see you’re connecting from a WSL environment. We are working on a fix for this.

[colachg]

@ravirahman Yes, reloading the IDE window will also work for the Git extension. I hope you’ll consider using the Git extension as well—I especially like the AI-generated commit messages available through the Git UI.

[tl-jacob]

@ravirahman for me SSH_AUTH_SOCK isn’t even properly setup in the container.

#in dev container

$ ssh-add -l
Could not open a connection to your authentication agent.

It was automatically setup with the VSCode dev containers extension. Do you happen to have a timeline for either:
A) A fix for the anysphere extension
B) When we can search for and install the VSCode dev containers extension again

[ravirahman]

@aeresov – could you upgrade to version 1.0.5 of the Anysphere WSL extension? We had a bug in earlier versions where it wouldn’t source the .bashrc / .bash_profile, and thus not detect the SSH_AUTH_SOCK being exposed by a startup script.

@colachg – could you upgrade to version 1.0.12 of the Anysphere Remote Containers? We have adjusted how the socket is mounted to make it more stable. This version of the extension also respects remoteEnv.

@tl-jacob – could you share the logs from the “Remote - Dev Containers” output window so we can take a closer look at why the socket isn’t being mounted in the first place? In a terminal outside of the dev container, could you run echo $SSH_AUTH_SOCK and ssh-add -L to verify that the ssh agent is configured?

[Wet_Rain]

@ravirahman issue persists even though I am on latest version 1.0.12 of Anysphere Dev Containers on OSX host.

Note that the same settings work perfectly with VSCode’s original Dev Containers extension, so I don’t think it is a host configuration issue.

echo $SSH_AUTH_SOCK and ssh-all -L is correctly configured on host but agent connection only works for the first 30s after a container is started, thereafter, it gets broken and I get the error:

root@docker-desktop:/workspaces# ssh-add -l
Error connecting to agent: Connection refused

From the logs, it was working at this point:

2025-07-11 11:00:33.723 [error] [ssh_auth_socket][/tmp/cursor-remote-ssh-c3d70f69-ea2b-429d-83eb-82e4e7a7fd55.sock] forwarder process stderr: Connection established

Then, it closed the connection on its own without re-connection and subsequent ssh-add -l no longer works:

2025-07-11 11:00:47.560 [info] [ssh_auth_socket][/tmp/cursor-remote-ssh-c3d70f69-ea2b-429d-83eb-82e4e7a7fd55.sock] SSH host stream ended
2025-07-11 11:00:47.562 [error] [ssh_auth_socket][/tmp/cursor-remote-ssh-c3d70f69-ea2b-429d-83eb-82e4e7a7fd55.sock] connection done
2025-07-11 11:00:52.087 [error] [ssh_auth_socket][/tmp/cursor-remote-ssh-c3d70f69-ea2b-429d-83eb-82e4e7a7fd55.sock] forwarder process stderr: Connection established

2025-07-11 11:00:52.090 [error] [ssh_auth_socket][/tmp/cursor-remote-ssh-c3d70f69-ea2b-429d-83eb-82e4e7a7fd55.sock] forwarder process stderr: Remote stdin close

2025-07-11 11:00:52.122 [info] [ssh_auth_socket][/tmp/cursor-remote-ssh-c3d70f69-ea2b-429d-83eb-82e4e7a7fd55.sock] forwarder process stdout ended