[Bug]: Cold WSL startup exceeds wslpath timeout and falls back to Windows backend #14348

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. On Windows 11, configure T3 Code 0.0.44 to use an Ubuntu WSL 2 backend in WSL-only mode.
2. Start T3 Code while the distro is stopped and its systemd startup takes more than 10 seconds. On this machine, a Windows-side wsl.exe -d Ubuntu --exec /usr/bin/wslpath -u <existing Windows path> completes successfully in about 12.2–12.6 seconds from a cold distro.
3. Observe repeated wslpath conversion failed preflight errors and the modal saying WSL backend is still unavailable; T3 Code falls back to the Windows backend for this launch.
4. Keep an Ubuntu process running, repeat the same conversion, and start T3 Code again. The conversion takes about 0.4 seconds; T3 Code starts the Linux backend successfully.

The affected Windows paths existed, and /mnt/c/Users/... was mounted inside Ubuntu. The direct wslpath command returned the correct /mnt/c/... path with exit code 0.

Expected behavior

Cold WSL startup should not be reported as a path conversion failure. T3 Code should allow a slow distro enough time to start, or surface a timeout-specific explanation and retry without losing the requested WSL backend for the launch.

Actual behavior

desktop.wsl.windowsToWslPath repeatedly takes about 10.4 seconds and yields wslpath conversion failed for ..., even though the same conversion succeeds if allowed about 12 seconds. After its retry window, T3 Code shows WSL backend is still unavailable and uses Windows. Prewarming Ubuntu makes the WSL backend start normally. After the successful launch, the Linux server listens on 0.0.0.0:3773, and /.well-known/t3/environment returns HTTP 200 from both WSL and Windows localhost.

Impact

Major degradation or frequent failure. A cold distro prevents the selected WSL-only backend from starting until Ubuntu is kept running manually.

Version or commit

T3 Code desktop 0.0.44

Environment

Windows 11 x64, build 26200.9550; WSL 2.9.12.0; default distro Ubuntu, WSL 2, systemd=true.

Logs or stack traces

desktop.wsl.preWarm: approximately 10.4 s
desktop.wsl.windowsToWslPath: approximately 10.4 s per attempt
desktop.backendConfiguration.wslPreflight:
  Could not stage the WSL runtime; launching from the mounted server tree instead.
  reason: wslpath conversion failed for <T3 install>\resources\wsl-runtime.tar.gz
desktop.backendInstance.scheduleRestartFiber:
  reason: wslpath conversion failed for <user profile>\.t3\userdata\wsl-server-tree\0.0.44

Direct Windows-side command with the distro cold:
  wsl.exe -d Ubuntu --exec /usr/bin/wslpath -u <same existing Windows path>
  exit=0; elapsed=12.2–12.6 s; output=/mnt/c/Users/.../0.0.44

Same command while an Ubuntu process keeps the distro running:
  exit=0; elapsed=0.4 s; same output

Ubuntu journal during cold starts:
  WSL (2 - init-systemd(Ubuntu)) ERROR: WaitForBootProcess:3594: /sbin/init failed to start within 10000ms

The current source defines WSLPATH_TIMEOUT = Duration.seconds(10) in DesktopWslEnvironment.ts. The error message does not distinguish command timeout from a real conversion failure.

Workaround

Start Ubuntu and keep a process running before launching T3 Code. Once T3 Code's Linux server starts, the extra process is no longer needed.

Related reports

• WSL backend never starts in a distro with automount disabled: wslpath conversion fails and the app silently falls back to Windows #8297 has the same error text, but its distro deliberately disables Windows-drive automount, so wslpath actually exits 1. Here automount works and the command exits 0 when given enough time.
• [Bug]: Unusable. WSL backend readiness timesout at 60s because the server bundle loads over /mnt/c (takin 80s to boot) and app stuck on "Connecting to WSL…" forever #4535 concerns the later HTTP readiness timeout after WSL preflight, not this path-conversion timeout.