When attempting to attach Cursor to a docker container (running Linux) using the CONTAINERS widget in the Activity bar, Cursor opens a new window but ultimately fails to attach with the final error being “Error resolving dev container authority Unexpected token ‘j’, “json” is not valid JSON”.
Steps to Reproduce
Attempt to attach Cursor to a docker container for remote development that requires a specific docker context. In this case is that I have a specific docker context that must be used to configure TLS, which I have selected from the DOCKER CONTEXTS section of the CONTAINERS widget.
Expected Behavior
Should attach to the docker container successfully, as VS Code does.
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
This had been working fine but has only just now become an issue. I don’t know what has changed to cause this because I had updated to my current version of Cursor days ago. I am using version 1.0.26 of Anysphere’s Dev Containers extension which was last updated on 2025-10-20. I can successfully attach to a docker container running on a WSL host, so I suspect the issue could be due to the fact that I need a specific docker context for attaching to the container which fails. Attaching with VS Code in the same way is successful.
I’ve discovered that attaching to a new container for the same container image works. I have tried removing the .cursor and .cursor-server directories from the old container, and also restarting the old container, none of which helped. So, the problem is more subtle than I first thought.
This is the final output from “Remote - Dev Containers” when this issue occurs:
2025-10-27 02:24:51.519 \[info\] Inspecting docker container 2755071a6b27 (fallback name: cb-trunk1_cbdev_1)
2025-10-27 02:24:51.519 \[info\] Spawned process 30904: ‘docker’ ‘inspect’ ‘2755071a6b27’
2025-10-27 02:24:51.519 \[info\] \[docker inspect\]: Running command: docker
2025-10-27 02:24:52.187 \[info\] \[docker inspect\]\[stderr\]: Error: No such object: 2755071a6b27
2025-10-27 02:24:52.193 \[error\] \[docker inspect\]: Running command: docker
2025-10-27 02:24:52.211 \[info\] Failed to find container by ID 2755071a6b27: \[docker inspect\] Command failed with exit code 1: stdout: [ ]
2025-10-27 02:24:52.211 \[info\] Attempting to find container by name: cb-trunk1_cbdev_1
2025-10-27 02:24:52.211 \[info\] Spawned process 37948: ‘docker’ ‘container’ ‘ls’ ‘–all’ ‘–format’ ‘json’
2025-10-27 02:24:52.211 \[info\] \[docker container\]: Running command: docker
2025-10-27 02:24:52.621 \[info\] \[docker container\]: Command completed with exit code 0
2025-10-27 02:24:52.624 \[error\] Error resolving dev container authority Unexpected token ‘j’, “json” is not valid JSON
So for some reason it initially looks for a container id that doesn’t exist, can’t find it, then resorts to looking for all containers with the intended output format from the command to be JSON. However, the usage of the --format option appears to be incorrect. Perhaps it should be something like:
docker -c vmgui_cb-trunk1 container ls --all --format “{{json .Names}}”
I would appreciate it if the Cursor team could either:
Provide a Dev Containers extension fix to correct the --format option when it follows the fallback path to find the container name.
Provide some guidance as to how to clear the cached (apparently) container id it is using to avoid it using the fallback path.
I have noticed that the CONTAINERS section of the CONTAINERS widget in the editor side panel does show the correct container id for the named container. It is only when attempting to attach Cursor it using Anyphere’s Dev Containers does it mention an invalid container id.
I would like to add that I finally got around to re-creating the container that Cursor fails to attach to - creating a new container and with a different container image but the same container name - and the issue persists. So it is some sort of container-name-to-id mapping being kept in Cursor or its Dev Containers extension.