WSL: hung wsl.exe launches accumulate with no timeout, backoff, or surfaced error when a distro's interop channel is dead

Pre-submit checks

• Searched open Warp bugs — no duplicate found.
• Searched the known issues page — not listed.

Describe the bug

When a WSL distro's distro-wide interop channel stops being serviced, every wsl.exe that Warp launches against that distro blocks indefinitely. Warp surfaces nothing — the tab just sits there — and Warp keeps spawning more launches behind it, without backoff and without ever timing the earlier ones out in a way the user can see.

The underlying WSL fault is microsoft/WSL#41592: the Interop thread inside the distro's /init aborts on an unhandled Broken pipe and is never respawned, but its listening socket (/run/WSL/2_interop, with 1_interop symlinked to it) stays open. Connections are therefore still accepted and simply never answered, so callers block rather than getting an error. That part is not Warp's bug — the handling of it is.

Measured on my machine ~2h10m after the WSL-side crash, with Warp still open:

• 25 hung wsl.exe processes with warp.exe as their direct parent, every one of them the same tab-launch command:

  wsl --distribution Debian --shell-type standard --exec /usr/bin/zsh -c "exec -a -zsh '/usr/bin/zsh' -g --no-rcs"
  

• Additional hung launches from the per-tab git poller:

  wsl --distribution Debian --cd /home/rtack/dev/<repo> --exec zsh -f -c "PATH=... git --no-optional-locks branch --no-color"
  

• ~45 wsl.exe processes alive at any one moment. Grouping them by start time gave bursts of 30, 8 and 8 within a few seconds of each other, and the entire set had turned over — different PIDs, different start timestamps — between two samples about 30 seconds apart. So they are being timed out and respawned continuously.
• No error was displayed in any tab. The only user-visible symptom is that new tabs never finish opening, which reads as a Warp problem rather than a WSL one.

Sessions that already existed kept working perfectly throughout, because each has its own /run/WSL/<pid>_interop socket and its own Relay process. Only new launches are affected.

To reproduce

The precondition is a WSL distro whose distro-wide interop channel is dead. I hit it spontaneously; microsoft/WSL#41592 documents a way to induce it, which I have not run myself:

1. Make the distro's first root session slow to reach [email protected] (e.g. systemd boot taking longer than boot.initTimeout).
2. From PowerShell: $j = Start-Job { wsl -d <distro> -u root -e true }; Wait-Job $j -Timeout 3; Stop-Job $j
3. The distro's init aborts. Confirm with wslinfo --networking-mode from an existing session — it will not return.

Then, in Warp:

1. Open a new tab on that distro. It hangs with no error, indefinitely.
2. Leave Warp open for a few minutes and count wsl.exe processes — e.g. Get-Process wsl | Group-Object { $_.StartTime.ToString('HH:mm:ss') }. They accumulate and churn.

Any state in which wsl --distribution <distro> --exec ... blocks rather than failing should reproduce the Warp-side behaviour; the specific WSL bug above is just the way I got there.

Expected behavior

1. A bounded timeout on a tab launch, with the failure surfaced in the tab. Something like "Could not start a shell in Debian — WSL did not respond" is enough. Right now the tab is indistinguishable from one that is merely slow, and there is no signal anywhere in the UI that dozens of launches are failing.
2. Backoff on the per-tab git poller when a launch against that distro is already outstanding. Re-issuing git branch through a fresh wsl.exe every cycle, per tab, while the previous ones are still hung, is what turns one dead channel into ~45 stuck processes.

A "this distro is not responding" state that stops further launches until one succeeds would cover both.

Measurement details

wslinfo --networking-mode from a still-working session in the same distro did not return within a 30s bound (exit 124, full 30s elapsed) — so these launches are genuinely blocking, not just slow.

Parent attribution, in case it is useful:

ParentPid  : 21916
ParentName : warp.exe
Count      : 25
SampleCmd  : wsl --distribution Debian --shell-type standard --exec /usr/bin/zsh -c "exec -a -zsh '/usr/bin/zsh' -g --no-rcs"

Environment

• OS: Windows 10.0.26100.9448
• Warp: v0.2026.09.09.08.26.stable_02
• WSL: 2.7.13.0, kernel 6.18.33.2-microsoft-standard-WSL2, WSLg 1.0.73.2
• Distro: Debian, systemd=true
• Shell: zsh