FIXED: why Cursor Devcontainers crash on startup, 100% reproducible

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

As per previous bug report - Devcontainers still 100% broken on latest cursor - suggestions? - #8 by A_A6

Steps to Reproduce

As per previous bug report - Devcontainers still 100% broken on latest cursor - suggestions? - #8 by A_A6

Operating System

Windows 10/11

Version Information

Latest latest

Additional Information

Cursor’s lame policy of closing reports to hide how many unfixed bugs there are prevents me replying to the original topic - Devcontainers still 100% broken on latest cursor - suggestions? - #8 by A_A6

I found:

  1. the root cause (it’s something Microsoft changed in an WSL update, and documented in the release notes)
  2. the exact bug in Cursor (as previously reported, but no-one at Cursor could be bothered to fix it)
  3. why it ‘works for some people’ (Cursor is hardcoded to do the wrong thing: MS has two valid addresses, MS DevContainers support both, but Cursor - being incorrectly written - crashes on one of them)

And now we have a permanent fix. No thanks at all to Cursor, who could have easily fixed this at source.

But to anyone else who runs into this - change your installed WSL sub-system version. As a side-effect: you will lose ALL DEV CONTAINERS in Cursor (because Cursor sucks).

Note “WSL 2” is not a version, you need to dig into your point-releases and ‘upgrade’ to the newer WSL for Cursor to start working again

Does this stop you from using Cursor

Yes - Cursor is unusable

9

Hey, thanks for the detailed troubleshooting. The breakdown with the two valid WSL UNC formats (\\wsl$\ vs \\wsl.localhost\) and tying it to the change in the WSL release notes is genuinely helpful. That’s the kind of info that helps narrow down the issue.

Confirmed, this is a known path conversion bug in the WSL Dev Containers flow, and it’s still open. Your workaround switching the installed WSL subsystem version works, but like you said it’s destructive since it wipes all dev containers. We don’t have a cleaner option to suggest right now. In some cases, projects inside the VHDX behave more reliably than ones on /mnt/c/....

A couple quick details we’d like to attach to the report: the exact Cursor version, and the WSL versions before and after the update where this reproduces.

One small request for next time, let’s keep the tone constructive. Your debugging is excellent and appreciated, but shots at the team don’t help and fall under the be excellent guidelines. We’ll keep digging into the root cause.