[Bug]: Desktop stuck on "Connecting to WSL" — getDistroIp picks unreachable Docker bridge IP instead of eth0 #5211

Summary

Desktop WSL backend hangs on "Connecting to WSL..." forever. getDistroIpImpl (apps/desktop/src/wsl/DesktopWslEnvironment.ts:691) assumes the first IPv4 in hostname -I output is always the reachable eth0 address. When Docker has created bridge networks in the distro, those sort first and are never reachable from Windows — so the app polls a dead address forever.

Environment

• T3 Code (Alpha) 0.0.31, Windows desktop
• WSL2 Ubuntu, networkingMode=mirrored
• Docker running inside the distro with active bridge networks

Repro

1. WSL2 + mirrored networking + any docker compose project running (creates a bridge network).
2. Enable WSL backend (wslBackendEnabled/wslOnly: true) and restart T3 Code.
3. Stuck on "Connecting to WSL..." indefinitely; restarting doesn't help, same bad IP gets picked every time.

Root cause

// apps/desktop/src/wsl/DesktopWslEnvironment.ts:691
const candidate = raw.split(/\s+/).find((part) => IPV4_PATTERN.test(part));

hostname -I returned (example): 172.22.0.1 172.19.0.1 172.17.0.1 192.168.1.219 — the first three are Docker bridge IPs (internal to the WSL VM, never reachable from Windows in any networking mode); the last is the real mirrored eth0 IP, confirmed reachable. The code takes the first match, so it grabs a Docker bridge address whenever one exists.

Confirmed the backend itself was healthy the whole time (listening on 0.0.0.0:3773, curl 127.0.0.1:3773/.well-known/t3/environment → 200 from both WSL and Windows) — this is purely an address-resolution bug, distinct from #3611.

docker network prune doesn't fix it long-term — it just makes the code pick the next Docker bridge IP in the list instead.

Suggested fix

• Prefer 127.0.0.1 for the readiness check under mirrored networking (already works), or
• Resolve the actual default-route interface inside WSL (ip route show default) instead of trusting hostname -I ordering.
• At minimum, log the full candidate list and which one was chosen.

Workaround

None without tradeoffs — any Docker bridge network breaks this, and disabling wslBackendEnabled defeats the feature.