[Bug]: WSL backend binds 0.0.0.0 while "Network access" is off and the UI says "Limited to this machine"

Summary

With WSL backend enabled and WSL only = ON, the app-managed backend listens on 0.0.0.0:3773 even though Network access is toggled off. The Connections panel states "Limited to this machine", which is not true of the actual bind.

What makes me think this is a bug rather than intended behaviour: on the same machine, a backend started via npx t3@latest service install (systemd user unit) bound 127.0.0.1:3773 correctly. Only the desktop-app-managed WSL backend binds all interfaces. (That systemd unit was stopped at the time of the checks below, so the process bound to 0.0.0.0 is definitively the app-managed backend, running out of ~/.t3/wsl-runtime/….)

Steps to reproduce

1. Windows desktop app → Settings → Connections
2. WSL backend → pick a distro → choose Use only WSL
3. Leave Network access OFF ("Limited to this machine")
4. In the WSL distro: ss -tlnp | grep 3773

Expected

127.0.0.1:3773, matching what the UI claims.

Actual

LISTEN 0 511 0.0.0.0:3773 0.0.0.0:* users:(("node",pid=...))

and it answers on non-loopback addresses:

curl -o /dev/null -w '%{http_code}' http://100.x.x.x:3773/   -> 200   # tailnet IP
curl -o /dev/null -w '%{http_code}' http://172.x.x.x:3773/   -> 200   # WSL eth0
curl -o /dev/null -w '%{http_code}' http://127.0.0.1:3773/   -> 200

Why this matters

"Limited to this machine" reads as a security property, and a user may reasonably rely on it when deciding whether to open a project containing sensitive material.

On a default WSL2 setup the exposure is narrower than it looks, since WSL's NAT address is not reachable from the LAN without a portproxy. But anyone running Tailscale inside WSL has the backend reachable from every device on their tailnet, with the toggle off and the UI saying otherwise. In my case the only thing preventing that was a restrictive tailnet ACL — containment came from the network, not from the app control that claims to provide it.

Environment

• Windows 11 + WSL2, Ubuntu 24.04
• Desktop app installed via winget install T3Tools.T3Code, 2026-09-01
• CLI t3@0.0.37 (used for the contrasting systemd-service test)
• WSL backend enabled, WSL only ON
• Network access off; T3 Connect off; Publish agent activity off

Note on scope

I have not verified whether the UI/API layer on :3773 authenticates. /mcp correctly returns 401 without the bearer token, but I did not test the rest of the surface. If the HTTP layer is fully authenticated then this is a "the UI states something untrue" bug rather than an exposure bug — either way, the toggle and the bind should agree.

Start at Windows Settings → Connections, tracing how the Network access toggle reaches the WSL backend listener on port 3773. Reproduce with ss -tlnp | grep 3773 and the listed curl checks, then verify that Network access OFF binds only to 127.0.0.1 and that the UI statement matches the reachable addresses.