Cursor Dev Containers leak WSL Relay/vsock sessions until WSL connections fail

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Opening a project in a Cursor Dev Container on WSL2 leaks WSL Relay/vsock sessions.

Each Dev Container launch creates approximately 30–35 new Relay(/init) processes. These processes and their vsock connections remain after all Cursor windows are closed. Repeated launches accumulate hundreds of sockets in CLOSING state until WSL reports:

<3>WSL (…) ERROR: UtilAcceptVsock:273: accept4 failed 110

At that point, Cursor can no longer open Dev Containers reliably.

The same minimal Dev Container tested with VS Code does not produce sustained Relay growth, so this appears specific to Cursor’s Dev Containers integration.

Steps to Reproduce

  1. Use Windows with WSL2 Ubuntu and Docker Desktop.

  2. Create a minimal project containing:

    .devcontainer/devcontainer.json

    {
    “name”: “Minimal Test”,
    “image”: “ubuntu:24.04”
    }

  3. Close all Cursor windows.

  4. Record the initial Relay count in WSL:

    ps -eo comm= | grep -c ‘^Relay(’

  5. Record vsock states:

    sudo ss -Ha --vsock |
    awk ‘{n[$2]++} END {
    printf “closing=%d estab=%d listen=%d\n”,
    n[“CLOSING”]+0,
    n[“ESTAB”]+0,
    n[“LISTEN”]+0
    }’

  6. Open the project in Cursor using an empty profile with only the Dev Containers extension enabled.

  7. Select “Reopen in Container”.

  8. Wait approximately 60 seconds.

  9. Close every Cursor window and wait another 60 seconds.

  10. Run the same commands again.

Result: approximately 30–35 additional Relay processes remain, and the number of CLOSING vsock entries increases substantially.

Repeating the process eventually causes WSL error “UtilAcceptVsock:273: accept4 failed 110”.

Expected Behavior

Cursor should create only the WSL relay connections required for active Dev Container sessions.

When a Dev Container window is closed, its Relay processes and vsock connections should be released, and the counts should return close to their original baseline.

It should be possible to run multiple Cursor Dev Container windows without progressively exhausting WSL vsock resources.

Operating System

Windows 10/11

Version Information

Cursor:

Version: 3.12.17 (user setup)
VS Code Extension API: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Date: 2026-07-17T02:53:53.006Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

WSL2/Docker:

WSL distribution: Ubuntu
Docker Desktop: 4.82.0
Docker Engine: 29.6.1
WSL version: 2.7.10.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.6676
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8875

Additional Information

Observed during one exhausted session:

257 Relay processes
982 CLOSING vsock entries
617 ESTAB entries
269 LISTEN entries
1868 total vsock entries

Controlled comparison:

Cursor with minimal Dev Container:

  • Approximately 30–35 persistent Relay processes added per launch
  • More than 100 additional CLOSING sockets
  • Relays remain after Cursor is closed

VS Code with the same minimal Dev Container:

  • No sustained Relay growth
  • Relay count remained at or below baseline

Normal Cursor project without reopening in a Dev Container:

  • Only a few Relay processes were created
  • Count stabilized

Manually killing leaked Relay processes can reclaim sockets, but this is unsafe because some Relay processes are used by Docker Desktop. During testing, killing the wrong relays broke Docker’s WSL integration and required restarting Docker Desktop.

Restarting WSL clears the problem but terminates all running development processes, so it is not a practical workaround when several development environments are active.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. The repro steps, metrics, and the comparison with VS Code make it much easier to investigate.

From what we see on the forum, this looks like an isolated case, and we haven’t been able to reproduce it yet. I want to run your scenario on Windows with WSL2 and Docker Desktop to confirm a Relay vsock leak.

One missing detail: which version of the Dev Containers extension is installed anysphere.remote-containers? You can see it in the Extensions panel. Also, if you still have the full logs from the Dev Containers output channel while the sessions were building up, please share them. That would help a lot.

Once we can reproduce it on our side, we’ll file an internal report and I’ll reply in the thread. I can’t give an ETA yet.

6

Thanks. The installed version is:

anysphere.remote-containers 1.0.37

I reproduced the issue again with the minimal ubuntu:24.04 devcontainer and captured the Dev Containers output plus WSL vsock metrics.

During the run:

Relays: 138 → 178
CLOSING: 493 → 648
LISTEN: 143 → 183

See attached (sanitized) logs.

vsock-metrics-sanitized.log (6.1 KB)

cursor-devcontainers-1.0.37-sanitized.log (73.4 KB)

7

Thanks, the version and logs really help. I’ve confirmed you’re on anysphere.remote-containers 1.0.37, and I’ve got the Dev Containers output log and the vsock metrics. Re-running with Relays going 138 to 178 and CLOSING going 493 to 648 matches your original description well.

Next on our side, we’ll set up your scenario on a matching environment Windows plus WSL2 Ubuntu plus Docker Desktop, with a minimal ubuntu:24.04 devcontainer and try to reproduce Relay and vsock session buildup after closing windows. For now this looks like a one-off case, and we haven’t been able to reproduce it yet, so getting a repro is the priority.

One quick question. When you captured the baseline 138 relays and 493 closing, was that after a fresh wsl --shutdown, or on a system that had already been running for a while with containers open? I’m trying to understand if the counter grows from a clean start or on top of already accumulated state.

8

This was after running for a while, but I observed the same behavior on a fresh WSL and Docker Desktop (and even Windows) boot.

9

Hi, is there any update on this? Can I help in any way?

This is a serious problem for me and severely degrades my DX when using Cursor.

10

Hey, quick update: we still haven’t been able to reproduce this on our side. We’re setting up a matched environment (Windows + WSL2 Ubuntu + Docker Desktop with a minimal ubuntu:24.04 devcontainer) to catch Relay/vsock buildup after closing windows, that’s the current priority. Your logs and metrics helped a lot, we confirmed the counter growth from them. I can’t share an ETA yet.

What you can really help with, if it’s not too much trouble:

  • The exact number of windows or launches from a clean wsl --shutdown until accept4 failed 110 shows up (rough threshold by Relay/CLOSING count before it crashes).
  • Whether the leak reproduces on the most minimal setup: empty profile, only anysphere.remote-containers, no other extensions, and no Docker features in devcontainer.json (you basically tested this already, but I want to lock it in).
  • If you can, the output of wsl --version, and whether Docker Desktop has WSL integration enabled for this distro.

Once we have a repro, I’ll reply right in the thread.

11

Thank you for the reply.

  1. 7-8, cumulatively, including container rebuilds in the same workspace.

  2. Yes, it does.

  3. Same as above:

WSL version: 2.7.10.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.6676
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8875

Thank you.

12

Thanks, this is exactly what we needed. The threshold of about 7 to 8 launches after a clean wsl --shutdown, confirming the repro on a minimal setup empty profile with only anysphere.remote-containers and no Docker features, plus your WSL version, answers almost everything.

We’re now working on a matched environment Windows plus WSL2 Ubuntu plus Docker Desktop with a minimal ubuntu:24.04 devcontainer to catch the Relay vsock buildup after closing windows on our side. Your logs and metrics already let us confirm the counters are increasing, so getting a repro in our lab is the top priority.

I can’t give an ETA yet. As soon as we reproduce it and have an update, I’ll post it right here.

I get that this is seriously blocking, and there’s no safe workaround here. wsl --shutdown kills all dev processes, and manually killing Relay breaks Docker WSL integration. We’re on it. If you notice anything else, like whether the threshold depends on the number of forwarders or ports in the devcontainer, or on Docker features, please send it over. Any detail helps narrow down the repro.

13

Quick update on reproduction: we still can’t reproduce this on our side.

Since it reproduces reliably for you, the fastest way to move forward is to collect structured data from your machine. To avoid manual tracking, I attached a small repro kit zip that automates what we need. It includes a minimal devcontainer using ubuntu:24.04 with no features, plus three scripts: one PowerShell driver and two measurement scripts. The measurement scripts are read only ps and ss --vsock, and they run as root inside WSL because ss --vsock needs that. The driver script only opens and closes Cursor windows using an isolated profile at %LOCALAPPDATA%\CursorReproProfile so your real profile stays untouched, and it writes results into the kit folder.

  1. Unzip it to a Windows path, for example C:\repro\wsl-relay-leak-repro.
  2. Start clean: run wsl --shutdown, then start Docker Desktop and wait until it’s ready.
  3. Before running, unblock the downloaded zip right click the .zip then Properties then Unblock, or run Unblock-File on the extracted .ps1 files.
  4. In PowerShell run:
    cd C:\repro\wsl-relay-leak-repro\scripts
powershell -ExecutionPolicy Bypass -File .\run-repro.ps1 -Iterations 8
    On the first run it sets up the isolated profile with only anysphere.remote-containers installed, which matches your empty profile setup. It’s semi automatic. Each iteration you click Reopen in Container and press Enter once the container window is up. The script handles timing, window closing, and measurement. It records Relay count via ps, and vsock CLOSING, ESTAB, and LISTEN via ss --vsock, with snapshots taken before close and 60 s after close. It also runs a WSL health check each iteration and stops at the first failure. That helps pinpoint the exact launch where accept4 failed 110 starts.

When it’s done, please attach:

  • results\vsock-metrics.csv with the full growth curve
  • the results\dumps\ folder with per iteration Relay PID lists and raw ss --vsock output, so we can diff which Relay processes leak versus the ones that belong to Docker Desktop
  • the Dev Containers output channel log from this run, ideally for the failing iteration

No need to resend versions. We already have your wsl --version, extension version, and Cursor info from earlier posts. To clean up after, delete %LOCALAPPDATA%\CursorReproProfile and the kit folder. Running wsl --shutdown clears the leaked relays.

If you don’t want to run the script, the manual equivalent per iteration also works: ps -eo comm= | grep -c '^Relay(' and your earlier vsock one liner, and note the launch number where accept4 failed 110 first appears. The kit gives us the same data with less effort and no transcription mistakes.

Still no ETA, but this is the fastest way to make progress.

wsl-relay-leak-repro.zip (6.8 KB)

14

Hi,

When I run the scenario you asked me to implement:

  1. Unzip into C:\wsl-relay-leak-repro
  2. Open PowerShell
  3. Run run-repro.ps1
  4. Click “Reopen in container” when asked

This doesn’t seem to trigger the bug:

ts,label,relays,closing,estab,listen,total
2026-07-29T04:09:03Z,baseline,3,8,61,7,76
2026-07-29T04:11:04Z,iter1-open,3,2,61,7,70
2026-07-29T04:12:20Z,iter1-closed,3,2,61,7,70
2026-07-29T04:13:43Z,iter2-open,3,2,61,7,70
2026-07-29T04:14:58Z,iter2-closed,3,2,61,7,70
2026-07-29T04:16:29Z,iter3-open,3,2,61,7,70
2026-07-29T04:17:44Z,iter3-closed,4,2,67,8,77
2026-07-29T04:19:21Z,iter4-open,4,2,67,8,77
2026-07-29T04:20:37Z,iter4-closed,4,2,67,8,77
2026-07-29T04:22:15Z,iter5-open,4,2,67,8,77
2026-07-29T04:23:30Z,iter5-closed,4,2,67,8,77
2026-07-29T04:27:37Z,iter6-open,4,2,67,8,77
2026-07-29T04:28:52Z,iter6-closed,4,2,67,8,77
2026-07-29T04:31:23Z,iter7-open,4,2,67,8,77
2026-07-29T04:32:38Z,iter7-closed,4,2,67,8,77
2026-07-29T04:34:08Z,iter8-open,4,2,67,8,77
2026-07-29T04:35:24Z,iter8-closed,4,2,67,8,77

However, I have made a few other experiments:

A. Normal WSL workflow

  1. Unzip into WSL FS \wsl.localhost\Ubuntu\home\user\wsl-relay-leak-repro
  2. Open WSL Bash, navigate to ~/wsl-relay-leak-repro
  3. Create empty “test-devcontainers” profile
  4. Run cursor --profile "test-devcontainers" .
  5. Manually click “Reopen in container”

Then the bug happens and 20+ persistent vsocks are created.

This is my typical setup.

B. Open WSL folder through Windows

  1. Unzip into \wsl.localhost\Ubuntu\home\user\wsl-relay-leak-repro
  2. Open PowerShell
  3. Run cursor --profile "test-devcontainers" \wsl.localhost\Ubuntu\home\user\wsl-relay-leak-repro
  4. Manually click “Reopen in container”

The bug doesn’t happen.

I have no idea why, but it seems like that WSL2 > devcontainer triggers the bug, while Windows > devcontainer doesn’t, independently of where the project is actually mounted originally.

However, this is not a realistic alternative, because, among other things, the initialization scripts run code expecting a Linux host, not a Windows host.

15

This is really helpful. You basically found why we couldn’t reproduce it.

Here’s what your A and B experiments show: the trigger is the launch path, not where the project lives on disk.

  • Experiment A cursor --profile . from WSL bash, meaning WSL launch then Reopen in Container, nested authority dev-container+...@wsl+Ubuntu. Leak happens.
  • Experiment B and the repro kit run-repro.ps1 opens windows from the Windows side, or cursor \\wsl.localhost\... from PowerShell. No leak.

Our repro kit was launching Cursor from Windows, so your counters stayed stable. We were testing the wrong path. Now we’ll rerun the repro launched natively from WSL, like in your Experiment A.

One request to lock this down 100%: when you run scenario A, please send the log from the Dev Containers output channel for that session. Also, if you can see it, please share what authority the window shows. It should look like dev-container+...@wsl+Ubuntu. That’s enough to match your setup exactly.

This observation moved the repro forward a lot. I’ll post an update in the thread when we have one.

16

Sure:

Remote-Dev-Containers_PUBLIC_REDACTED.log (76.3 KB)

The authority is indeed wsl+Ubuntu.

18

Thanks, that clears everything up. The log confirms what’s happening end to end.

With the wsl+Ubuntu authority, every internal call during a container resolve goes through the WSL exec server, and each one starts a new wsl.exe login session. Your shell’s Identity added message makes each one easy to spot, about 34 in this single 40-second resolve. That matches the roughly 30 to 35 new Relay processes per launch you measured. The log also shows what keeps running after the window closes. There’s a detached shutdown monitor that polls Windows interop once per second, plus the SSH agent, GPG agent, and tunnel forwarders, with the tunnel starting a new subprocess per connection. That lines up with the CLOSING vsock buildup and the roughly 7 to 8 launch threshold.

It also explains why neither our setup nor your experiment B leaked. Launching from the Windows side doesn’t use that per-call WSL session path at all. We were both testing the wrong entry point until your experiment A isolated it.

You don’t need to do anything else. You’ve given us everything we need. I’m filing this internally with your data. I won’t suggest launching from Windows as a workaround since your init scripts expect a Linux host, so for now the only reset is running wsl --shutdown from time to time. I’ll post an update here as soon as we have progress.

19

Thank you.

I’m eagerly waiting for an update. Please let me know of any progress.

20

Hi,

The problem is still present. It requires me to stop everything I’m doing, close and reopen every single devcontainer many times per day. This is genuinely making Cursor unusable for me and I’m really close to cancelling my subscription due to this. Do you have any news to share? Were you able to repro?

Thanks.

21

Hey, thanks for not dropping the thread, and sorry for going quiet.

Good news. Thanks to your Experiment A, we finally reproduced it on our side. The key was the launch path. A native start from WSL authority dev-container+...@wsl+Ubuntu runs each internal resolve call through a separate wsl.exe login session, and the detached shutdown monitor and forwarders keep running after the window is closed. Starting from the Windows side does not use this path, so our first repro kit did not catch it. Your logs and metrics fully closed the gap.

This is definitely not something in your setup. It is behavior on our side, and we are tracking it. I will be honest, I cannot give an ETA yet. There is also no safe workaround. wsl --shutdown kills all dev processes, and manually killing Relay breaks Docker WSL integration, so the only partial reset is running wsl --shutdown from time to time. I get that with multiple active environments, this is not a real solution.

I understand that in its current state this really breaks your workday, and having to close and reopen containers many times a day is not OK. I am keeping an eye on the thread and will post an update here as soon as I have progress.