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

Activity

1. 9jaGuy commented on Aug 11, 2026

   

   9jaGuy

   on Aug 11, 2026

   Author

   More actions

   Update: worked around this by disabling wslOnly (native-Windows backend connected reliably, no WSL bridge involved). Re-enabled wslBackendEnabled afterward and it's now also connecting fine in the parallel WSL+Windows ("mixed") backend mode — so whatever was stalling the WSL cold start on my end has since cleared.

   Separate observation worth flagging: while chasing this, I also hit cases where the WSL-hosted backend eventually did become reachable on 127.0.0.1 (confirmed via curl, and via /proc/<pid>/wchan showing it stuck in p9_client_rpc — WSL's /mnt/c/ filesystem bridge — rather than crashing), but past the 60s waitForHttpReady deadline. The desktop app never re-polled that already-spawned backend afterward and stayed on the connecting spinner until a manual restart. That's a second, independent gap from the IP-selection bug above: no retry/re-check against a backend that recovers after the readiness deadline.
2. 9jaGuy commented on Sep 22, 2026

   

   9jaGuy

   on Sep 22, 2026

   Author

   More actions

   Closing this out — resolved on my end (T3 now connects reliably in mixed WSL+Windows backend mode). Leaving the diagnosis above in case it's useful if this resurfaces for someone else; the underlying getDistroIp IP-selection issue wasn't fixed upstream, just no longer hitting it here.
3. 9jaGuy

   closed this as completedon Sep 22, 2026
4. dvadovsz commented on Nov 6, 2026

   

   dvadovsz

   on Nov 6, 2026

   More actions

   Still reproduces on T3 Code (Beta), server 0.1.7, Windows 11 arm64, with networkingMode=mirrored. Docker Engine runs natively in the distro. The #13738 thread says mirrored mode already forces loopback, but that did not happen here.

   wsl.exe -d Ubuntu -- sh -c "hostname -I" prints 172.17.0.1 (docker0, interface DOWN) first, then the real eth0 and eth2 addresses. T3 probes http://172.17.0.1:3774/.well-known/t3/environment and times out at 60 s, then 180 s. The backend listens on 0.0.0.0:3774, and http://127.0.0.1:3774/... returns 200 from Windows.

   Workaround until a fix lands: put a hostname wrapper in /usr/local/bin, which precedes /usr/bin in the PATH that wsl.exe ... sh -c uses. It prints loopback for hostname -I only:

   sudo install -m 755 /dev/stdin /usr/local/bin/hostname <<'EOS'
   #!/bin/sh
   if [ "$1" = "-I" ] && [ "$#" -eq 1 ]; then
     echo 127.0.0.1
     exit 0
   fi
   exec /usr/bin/hostname "$@"
   EOS

   Fully quit T3 Code, including the tray, and relaunch. The backend became ready right away. The mode must be 755: with sudo tee plus chmod +x under umask 027 the file ended up rwxr-x---, and the shell silently skipped it. Remove the file to undo it. Any script that relies on hostname -I will now see 127.0.0.1.

   The #5998 idea of probing 127.0.0.1 alongside the distro addresses would also fix this. Skipping docker0, br-* and veth* entries would fix the selection part.