WSL2 becomes unstable for IDE workloads (VS Code Remote reconnect loop) when running Cairo/StarkNet tooling – root cause unclear

[RogerZoe]

Environment

WSL version:        2.6.3.0
Kernel version:     6.6.87.2-1
WSLg version:       1.0.71
MSRDC version:      1.2.6353
Direct3D version:  1.611.1-81528511
DXCore version:    10.0.26100.1
Windows version:   10.0.26220.7653

• Distro: Ubuntu (WSL2)
• IDE: VS Code (latest stable)
• Extension: Remote – WSL
• Also tested: Cursor IDE (same behavior)
• Workload: Cairo / StarkNet development (Scarb, Rust-based tooling)

---

Problem Description

WSL2 intermittently enters a state where IDEs using the WSL server fail to connect reliably.

When opening VS Code (or Cursor) with WSL integration enabled:

• VS Code repeatedly shows “Reconnecting to WSL…”
• Sometimes reports “VS Code Server closed unexpectedly”
• IDE becomes unusable for development
• Restarting VS Code does not fix the issue
• Rebooting Windows does not consistently fix the issue
• wsl itself is accessible from Command Prompt

This happens specifically during Cairo/StarkNet development, which involves:

• Scarb builds
• Cairo language server
• Rust toolchain
• Heavy filesystem and process activity

---

Observed Behavior

• WSL terminal works normally
• IDE-based workflows fail
• High CPU usage / fan activity observed
• Cursor IDE exhibits the same behavior (not VS Code–specific)
• Ubuntu inside a VirtualBox VM works without issues on the same machine

This suggests the issue is not IDE-specific and not hardware-related.

---

Why This Is Hard to Debug

• Error messages point to IDE failure rather than WSL state
• No clear indication that the Linux environment is unhealthy
• Common troubleshooting steps (restart WSL, reinstall Remote extension) do not resolve the issue
• Documentation does not mention this failure mode

As a user, it is unclear:

• whether this is a kernel issue
• a distro lifecycle issue
• a WSL update incompatibility
• or a known limitation under heavy workloads

---

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[RogerZoe]

WslLogs-2026-02-09_12-08-17.zip

[github-actions]

Diagnostic information

.wslconfig found
Detected appx version: 2.6.3.0