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
- Windows desktop app → Settings → Connections
- WSL backend → pick a distro → choose Use only WSL
- Leave Network access OFF ("Limited to this machine")
- 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.
Summary
With WSL backend enabled and WSL only = ON, the app-managed backend listens on
0.0.0.0:3773even 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) bound127.0.0.1:3773correctly. 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 to0.0.0.0is definitively the app-managed backend, running out of~/.t3/wsl-runtime/….)Steps to reproduce
ss -tlnp | grep 3773Expected
127.0.0.1:3773, matching what the UI claims.Actual
and it answers on non-loopback addresses:
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
winget install T3Tools.T3Code, 2026-09-01t3@0.0.37(used for the contrasting systemd-service test)Note on scope
I have not verified whether the UI/API layer on
:3773authenticates./mcpcorrectly returns401without 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.