[Bug]: Windows + WSL backend startup readiness timeout, then EADDRINUSE :3773 after relaunch #26200

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

Observed sequence on 2026-10-28 (UTC+7); reproducibility outside this run has not been established.

1. Start T3 Code nightly on Windows and enable the WSL backend (Ubuntu-24.04).
2. Wait for startup. In the observed run, the recovery window appeared while the WSL server had already logged that it was listening on port 3773.
3. After it eventually connects, toggle the "WSL only" setting off and back on, triggering settings relaunches. In this run these occurred at 06:20:58 and 06:21:10.
4. Observe subsequent startup attempts failing with EADDRINUSE on port 3773 until approximately 06:23:14.

Expected behavior

The Windows app should detect the WSL backend once its readiness endpoint is reachable. If startup fails, the recovery window should show available server output.

Stopping/relaunching should wait for the managed WSL server process to exit and release its port, or terminate the leftover process before launching its replacement.

Actual behavior

Two symptoms occurred in the same WSL backend lifecycle:

Initial startup (06:16–06:18): The WSL server logged Listening on http://0.0.0.0:3773 about 25 seconds after spawn. waitForHttpReady against http://127.0.0.1:3773/.well-known/t3/environment timed out twice (60 seconds each), then succeeded on the third attempt, roughly two minutes after launch. The recovery window said "The server wrote no output" even though the server had printed its listening message; that output reached the log after the timeout. A listening socket alone does not establish that the readiness endpoint was reachable from Windows.

Settings relaunch (06:21–06:23): After wslOnly was toggled false and then true, backendInstance.stop returned Success in about 340 ms. The previous WSL server reportedly continued holding 0.0.0.0:3773 for roughly two more minutes. Replacement starts failed with listen EADDRINUSE: address already in use 0.0.0.0:3773 (exit code 1) until 06:23:14, after which startup worked.

This suggests a WSL shutdown/port-release race and a separate readiness/output-reporting problem; the underlying causes are not confirmed.

Impact

Major degradation or frequent failure

Version or commit

0.1.4-nightly.20261027.3783

Environment

Windows desktop app (win32 x64); WSL Ubuntu-24.04. Incident: 2026-10-28, 06:16–06:23 UTC+7.

Logs or stack traces

Relevant messages from the supplied diagnostic summary (full log files are not attached):

Listening on http://0.0.0.0:3773
waitForHttpReady: http://127.0.0.1:3773/.well-known/t3/environment (60s timeout, twice)
backendInstance.stop: Success (~340ms)
listen EADDRINUSE: address already in use 0.0.0.0:3773

Source log names: desktop.trace.ndjson and server-child.log, 2026-10-28 06:16–06:23 (UTC+7).

Screenshots, recordings, or supporting files

No response

Workaround

Waiting approximately one to two minutes allowed startup to succeed after the port conflict cleared.