In Cursor v0.42.4, the newest VS Code Extension: “DevContainer” that it is allowing me to use is v0.327.0, which is >11 months old, missing loads of bug-fixes/features, compared to the latest pre-release: v0.390.0 or GA release: v0.388.0 (>10 versions newer), combined with VS Code v1.95.1.
The lack of being able to use some of the latest VS Code extensions is causing me quite a bit of friction. Can anything be done to improve this situation in Cursor?
Unfortunately, I’m facing the same issue. I wasn’t able to update it, so I performed a manual installation, but then every functionality of the extension stopped working. I can’t open the container or the config files…nothing
This is really blocking since the actual version 0.327 does have some issues, in my case :
So I hope the cursor team can see this and help us out.
Same kind of issues here. Please update to a version that’s <3 months old
Hey, our next update bumps the base version of VS Code that Cursor is based off, so I would assume the Dev Containers extension would get an upgrade with it (just a guess though!)
Thank you Dan! Great news.
That would indeed very likely be the case. What would be the expected timeline for this?
Our next update should start rolling out in the next few days, and should be available to every user by the end of next week at the latest (if we hit any bumps or bugs we need to fix first!)
Thank you! Indeed it’s finally working natively with Cursor 0.45+, as Dev Containers has been updated by bumping their VSCode fork version.
Looks like this has resurfaced. The extension is now at 0.417.0 which reports
Unable to install extension 'ms-vscode-remote.remote-containers' as it is not compatible with VS Code '1.96.2'
Is there another update of the base VSCode version incoming soon?
Hi @Shaun_Lowry, we have released our own Dev Containers extension. The latest version of the VSCode extension isn’t compatible with Cursor.
Unfortunately, this extension is missing functionality that is critical for us e.g. cloning a repo into a volume
+1 the Anysphere devcontainer extension is now stuck in a perpetual loop chasing the latest feature or bug fix from the dedicated MSFT devcontainer/remote-ssh team, ultimately delivering a poorer customer experience than just getting the current MSFT owned devcontainer extension fixed/working with Cursor moving forwards.
Hi @Shaun_Lowry and @mjnowen thank you for this feature request. It is on our roadmap to implement support for docker volumes and cloning remote repos. I expect this to be out in version 1.0.9 / 1.0.10 of the extension – I can’t commit to a timeline, but hopefully it’ll be out sometime this week.
Please let us know if there is any additional functionality we should prioritize.
The single biggest issue is stability. The internet is a wasteland of PTY host issues with Cursor.
Timeouts and Disconnections: Users have reported that after using features like Agent or Ask, all open terminals in Cursor may lose connection or timeout, especially in development container environments. This may be due to aggressive cleanup routines or process management bugs that terminate PTY sessions prematurely5.
PTY Host Errors with Long Scripts: Running long or resource-intensive scripts (notably in R) can trigger “pty host” errors, particularly on macOS. This interrupts analytical workflows and forces users to break tasks into smaller chunks67.
Unresponsive PTY Host: When running multiple or large code blocks (e.g., loading/manipulating large dataframes in R), the PTY host can become unresponsive, especially on certain hardware or OS configurations7.
Orphaned Processes and High CPU Usage: On remote connections (e.g., SSH to a server), Cursor may leave behind orphaned bash processes tied to the PTY host, causing high CPU usage even after the editor is closed. This indicates issues with process cleanup and resource management4.
Any news on this? We’re currently pushing users back to VSCode/CoPilot to get around this
Also stuck on this issue. Is there even a workaround we could employ for the time being?
@timkooi and @Shaun_Lowry, we are aiming to have an update with Docker Volume support out next week.
Hello, do you have an update on this please? I believe cloning a repo into a volume is still missing.
I need Docker volume support for cache volumes. Any update?
I can’t get GPG signing work inside a dev container in Cursor, while the same container seems to setup GPG related things correctly when using in VS Code 
I managed to mostly solve it. I needed to install GPG >2.4 and pinentry-curses because the one that comes with Debian doesn’t appear to support keybox or something like that. It also sets the pin entry to curses in the config. It might work out of the box in Cursor just like it does in VS Code if you use one of the recent Ubuntu images since those come with 2.4.X pre-installed.
If, when running gpg --list-keys (or other gpg operations) on the container you get a message about a lock such as,
gpg: Note: database_open 134217901 waiting for lock (held by 6520)
then run
rm ~/.gnupg/public-keys.d/pubring.db.lock.
Do that again in case it happens again. Probably shouldn’t as long as you don’t run more than one container or access the keyring from more than one system. I tried copying the kbx files instead of mounting them, but I didn’t manage to make it work.
When you’re running the container for the first time, committing directly from Cursor VCS panel won’t work. To solve, commit from the integrated terminal and enter your passphrase there. Then you should be able to commit from the editor and from the terminal.
This looks like an unpleasant workaround with possible security considerations as I’m not very well versed in how GPG works (is it safe to mount the whole .gnupg dir?), so use at your own risk. I hope you’ll find it useful until the Cursor team manages to bring their Dev Container extension up to par with the VSC extension.
Here’s my .devcontainer file that should install the fresher version of GPG from the testing Debian package repository, mount the .gnupg directory and write the settings to use curses and allow loopback for pin entry, so all you’d need to do is commit from the terminal to save your passphrase for your secret key and maybe delete the lock file.
// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/typescript-node
{
"name": "Node.js & TypeScript",
// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
"image": "mcr.microsoft.com/devcontainers/typescript-node",
"features": {
"ghcr.io/devcontainers/features/git-lfs:1": {
"autoPull": true,
"version": "latest"
},
"ghcr.io/devcontainers/features/github-cli:1": {
"installDirectlyFromGitHubRelease": true,
"version": "latest"
}
},
"runArgs": [
"--volume=${localEnv:HOME}/.gnupg:/home/node/.gnupg"
],
"postCreateCommand": [
"bash",
"-c",
"set -e && echo 'Installing GPG 2.4 and pinentry from Debian testing...' && echo 'deb http://deb.debian.org/debian testing main' | sudo tee /etc/apt/sources.list.d/testing.list > /dev/null && echo 'Package: gnupg gnupg2 gpg gpg-agent dirmngr keyboxd pinentry-curses\nPin: release a=testing\nPin-Priority: 500\n\nPackage: *\nPin: release a=stable\nPin-Priority: 900' | sudo tee /etc/apt/preferences.d/gnupg-testing > /dev/null && sudo apt update -qq && sudo apt install -t testing gnupg2 pinentry-curses -y -qq && echo 'pinentry-program /usr/bin/pinentry-curses' >> ~/.gnupg/gpg-agent.conf && echo 'allow-loopback-pinentry' >> ~/.gnupg/gpg-agent.conf && echo 'pinentry-mode loopback' >> ~/.gnupg/gpg.conf && echo 'GPG setup completed'"
]
}
Sorry if I posted in the wrong thread, but it was the only open and relevant one and I didn’t want to create a new topic.