I’m trying to use dev containers, but it looks like it depends on the container ID in order ot work properly.
So if I connect to some container, for example, bla with id 1234, and then i will recreate this container it stop working and there is no visible configuration that can be changed if I want to continue using the dev container.
Faced this issue on mac and ubuntu 22
Any additional info that can help to fix/debug this will be provided upon request
Is it intentional, or a bug?
Steps to Reproduce
cmd + shift +p (mac)
Dev container attach to the running container
Choose a container name from the list
Opens a new window without any issue, installs server-side stuff for VScode
Recreate the container and preserve the same name, outputs with these errors
[info] Inspecting docker container 23663616bb78
2025-07-03 15:33:09.184 [info] Spawned process 78934: 'docker' 'inspect' '23663616bb78'
2025-07-03 15:33:10.387 [error] Error resolving dev container authority Failed to start Dev Container: container is not running: 23663616bb78
2025-07-03 15:33:10.419 [error] forwarderProcess stderr: forwarder error: Too many retries in 30 seconds, assuming container is actually dead
2025-07-03 15:33:10.419 [info] forwarderProcess stdout: forwarder: Stopping forwarding for port 61214
forwarder: Forwarder exiting
2025-07-03 15:33:10.422 [info] Forwarder process exited with status 0, disposing of local tunnel
2025-07-03 15:33:10.422 [info] [tcpForward][(remote) 127.0.0.1:61214 -> (local) 127.0.0.1:61214] Disposing of local tunnel
2025-07-03 15:33:10.422 [info] Stopping forwarder process
Looks like it still tries to use the old container ID, instead of the name that was used to connect
If need anything else, let me know
Expected Behavior
recreation of container can use new container ID, the name remains the same
Operating System
MacOS
Current Cursor Version (Menu → About Cursor → Copy)
Hi @Reuven, are you using a devcontainer.json file? If not (i.e. you are attaching to an already-running container), then we identify the container by ID. When you rebuild the container, you’ll need to reconnect to the new container through the Remote Explorer or Containers views, as the ID would have changed.
If you’re using a devcontainer.json, then this should not be happening, as we identify those containers by the workspace folder and the path to the devcontainer.json. Could you share the full logs from the “Remote - Dev Containers” output so we can take a closer look? Thanks!
Hi @ravirahman I don’t want that cursor will manage containers, that’s why I’m attaching to a running container. The same behaviour works as expected on VS Code IDE.
After recreation of the attached container, in VS Code, it asks to reload the window, and after it reinstalls all relevant stuff in the newly created container. I just reconnected to a fresh instance, and that’s all. Should this behaviour also exist in Cursor IDE?
our containers are quite complicated and the rest of the developers on our team also use the vscode system you mentioned. We also have this issue with “attaching to existing containers” when using remoteUsers. I would think this is something that cursor should support out of the box.
Same issue here, even when I have a devcontainer.json file. If the container is not running Cursor does not connect or start it, usually. I can manually start it with docker/podman run and then restart Cursor to get it connected.
However, if I manually start the container, and Cursor has connected to it, it seems I can stop Cursor, which stops the container, and the next time I open Cursor it can start the container and connect without the error.
I don’t have this behavior on VSCode, it always starts the container, rebuilds the container, etc. when needed. If I need to rebuild a devcontainer I end up having to start VSCode to build it, and then once its running move back to Cursor to use it.
