“Dev Containers: Open Folder in Container” is completely broken when running with docker in WSL (appears to be a bug someone at Cursor introduced in how you handle file paths when you detect Windows is running - you seem to convert linux paths to windows paths which is obviously incorrect).
This has been broken (by Cursor) for more than 2 months. Currently planning to downgrade our enterprise licenses as a result - we’re commiting to AI platforms for 2026 and this basic core bug is a showstopper.
It worked fine for approx 2 years up until Cursor did a forced upgrade in December 2025 - now broken on most Windows machines.
Error message (note there is no extra info, that’s another bug in Cursor: you are hiding the actual error messages):
“Failed to read devcontainer configuration”
Steps to Reproduce
Windows (10 or 11, happens on both) + WSL Ubuntu
Project located in /mnt/c/… anything = always broken
Project located in /… anything in the vhdx = broken on some Windows machines, not others
Open a project with a trivial devcontainer.json
Cursor fails, hides the actual errors:
2026-02-24 13:53:33.309 [info] Searching for devcontainer.json files
2026-02-24 13:53:33.347 [info] Found 1 devcontainer.json files: \mnt\c\projects\project1\devcontainers\insecure.devcontainer\devcontainer.json
2026-02-24 13:53:33.347 [info] Reading devcontainer config with command: read-configuration --workspace-folder /mnt/c/projects/project1/devcontainers/insecure --config /mnt/c/projects/project1/devcontainers/insecure/.devcontainer/devcontainer.json
2026-02-24 13:53:33.348 [error] Failed to read devcontainer config [wsl wslToWindows] Command failed with exit code 1: stdout:
2026-02-24 13:53:33.348 [error] Failed to reopen folder in container Failed to read devcontainer configuration
Hey, thanks for the detailed report and logs. I also see you already wrote about this in January. It’s really frustrating that it still isn’t fixed.
The logs make the issue clear: [wsl wslToWindows] Command failed with exit code 1 when trying to read the devcontainer config. Cursor is calling WSL path conversion incorrectly.
I’ve passed this on to the team.
A few questions that could help them debug faster:
When you say it breaks on some Windows machines but not others for projects in a WSL vhdx, is there any difference in how Cursor was installed (system setup vs user setup) or in the WSL distro versions on those machines?
Does this happen only with the Anysphere Dev Containers extension, or did you also try the Microsoft Dev Containers extension? This helps us tell if it’s our extension or the editor’s core WSL path handling.
Can you try opening Cursor directly from a WSL terminal with cursor . instead of launching it from Windows? I’m curious if that changes the path resolution behavior.
I know this isn’t a real fix, but it should help us pinpoint the regression. I’ll post here when I have an update.
So far as I can tell (I wasn’t present for all installs - but I did several of them myself when testing the problem)
WSL distros identical: current supported ubuntu (24.04)
Always default windows (I think that means: per user?)
Mix of letting Cursor auto-update, and also: manually uninstall completely and clean install
At least one: complete new install on new copy of Windows11 (just installed from scratch). NB: the complete new install FAILED to run containers when they were on /mnt/c/something, but then when I nuked + reinstalled on same machine and everything was mounted inside vhdx: SUCCEEDED. Same machine, same OS, same version of Cursor
Only tested Anysphere - the Microsoft one no longer available to install? This all started when Cursor forced us to switch to Anysphere extensions, removed MS from marketplace - or is there a workaround for that?
We only launch cursor that way - “cursor [folder]” (either . or a subfolder). Launching from windows traditionally hasn’t worked, it causes Cursor to be wedded to Windows instead of using WSL – honestly I don’t think any of us have even tried launching it directly from Windows recently (will try that!)
If you have any things to try as workarounds I will get them tested ASAP.
Also if there’s a way to get Cursor to output more useful data in the error messages, I’m happy to do anything to get better logs.
Thanks for the info, especially that it always breaks on /mnt/c/, and in VHDX it’s unstable (it only worked after the second install on the same machine). This confirms the issue is in the path conversion logic.
About the Microsoft Dev Containers extension, unfortunately the MS version isn’t supported in Cursor, and installing it via VSIX isn’t a good idea. It’ll work even worse. anysphere.remote-containers is the right extension, and the issue is in that one.
For more detailed logs:
Open View > Output
In the dropdown on the right, select “Dev Containers”
Try “Open Folder in Container” again
Send the full output from that channel, everything that shows up before and after the error
Another diagnostic test, can you run this from PowerShell (not from WSL):
wsl.exe wslpath -w /mnt/c
I’m curious if basic WSL path conversion works on machines where Cursor breaks.
Also please send wsl --version and the version of the anysphere.remote-containers extension (you can see it in the Extensions panel).
I passed your report with the logs and the details about different machines to the team, it helps with prioritizing. Let me know if you can collect this data.
Tried lots of tests of path functions - they all work fine everywhere except in Cursor. So e.g. output of your wslpath command is (as expected): C:\
wsl.exe has never had a ‘–version’ flag that I recall? MS docs currently don’t list one - they explicitly offer “–list –verbose” as the way to get “WSL version”, but all you get back is 1 or 2. All machines are running WSL2 of course (all machines updated to their latest Windows build - for Windows10 that’s 22H2 / 19045, for Windows11 that’s 25H2 / 26200).
Anysphere extension: tried 1.0.27 through 1.0.32, on multiple machines, with no effect.
Here’s the log you described - but I’m sure the actual API / tool calls give a lot more detail than a blank “stdout:” here, if so Cursor just isn’t passing it on (unhelpfully).
2026-02-24 13:53:30.029 [info] Checking for exec server for remote authority: wsl+Ubuntu
2026-02-24 13:53:30.029 [info] Using remote exec server for authority: wsl+Ubuntu
2026-02-24 13:53:30.029 [info] Found 1 devcontainer.json file(s), showing prompt
2026-02-24 13:53:30.204 [info] Copying devcontainer CLI from c:\Users\myuser.cursor\extensions\anysphere.remote-containers-1.0.32\dist@devcontainers to /tmp/devcontainer-cli-f4839e41-9413-429d-bb7f-325fe830ec53
2026-02-24 13:53:32.840 [info] User chose to reopen in container
2026-02-24 13:53:32.939 [info] Getting remote exec server for authority: wsl+Ubuntu
2026-02-24 13:53:32.941 [info] [docker info]: Running command: docker
2026-02-24 13:53:33.304 [info] [docker info][stderr]: WARNING: No blkio throttle.read_bps_device support
2026-02-24 13:53:33.304 [info] [docker info][stderr]: WARNING: No blkio throttle.write_bps_device support
2026-02-24 13:53:33.304 [info] [docker info][stderr]: WARNING: No blkio throttle.read_iops_device support
2026-02-24 13:53:33.304 [info] [docker info][stderr]: WARNING: No blkio throttle.write_iops_device support
2026-02-24 13:53:33.309 [info] [docker info]: Command completed with exit code 0
2026-02-24 13:53:33.309 [info] docker version: Client: Docker Engine - Community
Version: 27.2.1
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.16.2
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.29.2
Path: /usr/libexec/docker/cli-plugins/docker-compose
To be clear: Doing a fresh clone of the same project straight from github, directly into the vhdx (not touching windows filesystems at all), and running cursor from inside WSL … has exactly the same output (apart from the workspace-folder path being /srv/something instead of /mnt/c/something).
Or: creating a new folder inside vhdx, with a folder/project name never before used in VSCode or Cursor, adding a .devcontainer, and this ultra-simple devcontainer.json … (just in case it’s some corrupt cursor state that’s being persisted), gives the same failure:
Thanks for all the diagnostic info. This is super helpful, especially confirming that wslpath works fine outside Cursor and that the issue reproduces even on fresh projects inside the VHDX.
At this point it’s clear: the path conversion logic inside the Anysphere Dev Containers extension is broken, and it’s not your environment. The team has been flagged on this. I can’t give a timeline, but your report, especially testing on multiple machines and reproducing it after a fresh install, really helps us prioritize it.
A couple of notes:
About wsl --version. You’re right, that flag depends on the newer Store version of WSL. wsl --list --verbose is fine. I was just checking WSL2 vs WSL1, and you’ve confirmed WSL2 everywhere.
The blank stdout: in the error is particularly annoying. It means the devcontainer CLI is crashing before it can produce useful output. That matches the path conversion breaking early in the pipeline.
I don’t have any workarounds I can confidently suggest right now, unfortunately. If anything changes after an update, I’ll post here.
Hey @A_A6 , Tarun here from the extensions team.
I am trying to follow the thread but i am losing around, so i always default to action.
I tried reproducing on my windows test machine (win11) with wsl (ubuntu 24.04.3 LTS)
with the path /mnt/c/... worked fine – here’s the recording.
with ./ path on vhdx, again worked fine – here’s the recording of that
Works both by first opening wsl in cursor > open folder > reopen in container and wsl terminal > path to repo > cursor . > reopen in container.
I am on wsl version 1.0.13 and remote-container 1.0.32
Have a look at the recordings and lmk if i missed something along the way.
If its happening on most of your machines, then its a real issue and we are going to figure it out together
Here’s a few things i need you to do -
Try with our dev version of the remote container extension (attaching the vsix below)
lmk the versions of your wsl and remote-container extensions
Also, if you are under our enterprise license, we must have a shared slack.
Lmk if u do – share me your email or something and we can discuss there and sync if possible
