Everyone I have talked to in my immediate circle has been facing this problem and it feels impossible to solve. Other people have gotten close but no thread actually has solved this problem.
following the idea of mac->ssh into linux->starting a docker container (dev container).
our dev container needs the remote user to be “xxx-1001” instead of “xxx” when starting up. When I attach or “reopen in container” it will always open a workspace with “xxx.” when i sudo su xxx-1001 I can switch into the new user and do things (like save files), but that does not override the entire thing on cursor.
When on linux, the users can open a settings.json that allows them to specify “remoteUser” as xxx-1001 and everything works great. It seems to only be an issue for the mac users that are ssh-ing and using cursor on mac. Otherwise, this is fine on VS code
Steps to Reproduce
Create a docker image
create a .devcontainer/devcontainer.json
specify a "remoteUser’ that is different than the rootUser of the image
Operating System
MacOS
Linux
Current Cursor Version (Menu → About Cursor → Copy)
I was able to use “open folder in container” command using the remoteUser and the image that we are using, however we have commands required to start the image found in a script called
docker/dev/start.sh
regularly we use
docker/dev/into.sh
to enter the docker image.
what i found was that the “open folder in container” command starts a new container with a new ID and thus does not have any of the requirements for building/pushing/running. Is there a way that I can use “attach to running container” with this “remoteUser” or to configure “open folder in container” to run in the existing container?
The “Reopen in Container” and “Open Folder in Container” commands will respect the devcontainer.json file, including the remoteUser if present. We’ll also run the scripts specified in the devcontainer.json file – e.g. postCreateCommand, postStartCommand, postAttachCommand, and initializeCommand.
Depending on how the container is launched, we might not be able to detect a dev container that is started outside of Cursor. All the paths have to align for us to detect that a given container originated from a devcontainer.json, and isn’t a standalone Docker container.
The “Attach to running container” command does not support devcontainer.json – this is designed for standalone docker containers.
For your use case, I’d recommend modifying your devcontainer.json to automatically run the necessary scripts (e.g. via the Lifecycle Scripts), and then use the “Open Folder in Container” command. You might have to rebuild the container using Dev Containers: Rebuild Container command, since we won’t automatically rebuild containers upon changes to the devcontainer.json file.
Why can linux Cursor users edit their config file and specify a remoteUser for “attach to existing container” but its not possible for me to do this? I really just need to attach to the container given this remoteUser
It could be due to a difference in the docker daemon – we do not condition on platform when determining the remote user. For the attach to existing container command (assuming that we do not detect it is a dev container), then we’ll use the default user for the container.
I see that in the change logs for version 1.0.12 this was addressed. It mentioned support for passing RemoteUser and for attaching to existing container. can these be done together now?
Hi @Shantanu_Jhaveri, unfortunately not – the RemoteUser for attaching to containers (that are not from a devcontainer.json) would need to be set with an Attached Container Configuration File, which we do not currently support.
Hi @ravirahman, when do you plan to start supporting it? Because of this I have to strictly prevent Cursor Agent from running any commands and avoid using the Source Control plugin to keep file permissions sane.