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?