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

Activity

1. labeebbappu commented on Oct 10, 2026

   

   labeebbappu

   on Oct 10, 2026

   More actions

   Same mismatch on native macOS — no WSL involved

   This reproduces on a plain macOS desktop install, which I think widens the scope beyond the WSL-managed backend. The contrast you drew (app-managed WSL backend binds 0.0.0.0, systemd-installed backend binds 127.0.0.1) suggested WSL was the trigger; on macOS there is no WSL backend at all and the bind is still 0.0.0.0 with Network access displaying off / "Limited to this machine".

   Environment

   • macOS 15 (Darwin 25.6.0), Apple Silicon Mac mini
   • T3 Code (Nightly).app 0.0.46-nightly.20261010.2908
   • Desktop-app-managed backend (no t3 service install — t3 service status reports not installed)
   • T3 Connect off, Publish agent activity off, WSL not applicable

   Observed

   Settings → Connections shows Network access — Limited to this machine. Meanwhile:

   $ lsof -nP -iTCP:3773 -sTCP:LISTEN
   COMMAND    PID   USER   FD   TYPE  NODE NAME
   T3\x20Cod 7301 dev007   25u  IPv4  TCP *:3773 (LISTEN)
   
   $ curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3773/api/t3-connect/health
   200
   $ curl -s -o /dev/null -w '%{http_code}\n' http://192.168.1.x:3773/api/t3-connect/health   # LAN
   200
   $ curl -s -o /dev/null -w '%{http_code}\n' http://100.x.x.x:3773/api/t3-connect/health     # tailnet
   200
   

   Unlike WSL's NAT address, the macOS LAN address is directly reachable from every device on the local network, so there is no incidental containment here.

   Not a CLI override

   The backend was started by the desktop app with no host flag:

   $ ps -o args= -p 7301
   /Applications/T3 Code (Nightly).app/Contents/MacOS/T3 Code (Nightly) \
     --require .../dist-electron/compileCache.cjs \
     .../apps/server/dist/bin.mjs --bootstrap-fd 3
   

   ~/.t3/userdata/server-runtime.json:

   {"version":1,"pid":7301,"host":"0.0.0.0","port":3773,"origin":"http://127.0.0.1:3773","startedAt":"2026-10-10T06:17:10.659Z"}

   Note host and origin already disagree inside this one file.

   Where the two values diverge

   ~/.t3/userdata/desktop-settings.json contains:

   {"serverExposureMode":"network-accessible", ...}

   I never touched the Network access toggle on this machine. The file was last written 2026-09-28; the persisted mode has been network-accessible since, and the UI has shown "Limited to this machine" throughout.

   Reading the shipped app.asar, desktop bootstrap does:

   if (settings.serverExposureMode !== environment.defaultDesktopSettings.serverExposureMode)
     yield* logBootstrapInfo("bootstrap restoring persisted server exposure mode", { mode: settings.serverExposureMode });
   
   const serverExposureState = yield* serverExposure.configureFromSettings({ port: backendPort });
   const backendConfig = yield* serverExposure.backendConfig;
   
   if (serverExposureState.endpointUrl)
     yield* logBootstrapInfo("bootstrap enabled network access", { endpointUrl: serverExposureState.endpointUrl });
   else if (settings.serverExposureMode === "network-accessible" && serverExposureState.mode === "local-only")
     yield* logBootstrapWarning("bootstrap fell back to local-only because no advertised network host was available");

   That last branch is exactly the state this machine is in: persisted mode is network-accessible, but the resolved serverExposureState.mode is local-only. My reading — offered as a hypothesis, not a verified claim — is that the advertised endpoint falls back to local-only (so the UI renders "Limited to this machine"), while the bind host still comes from configureFromSettings on the persisted network-accessible value, leaving the socket on 0.0.0.0. If that is right, the UI is reporting serverExposureState.mode while the listener follows the persisted setting, and the two can disagree on any platform — WSL is incidental.

   I could not confirm this from logs: server.trace.ndjson rotates at 10 MB and on this machine covers only the last ~3 hours, so the 06:17Z bootstrap lines are long gone. Someone who can reproduce with a fresh log should look for bootstrap fell back to local-only because no advertised network host was available.

   A plausible trigger for "no advertised network host" at boot is Tailscale not yet being up when the app launches, which may make this adjacent to #17362.

   Same scope caveat as the original report

   Like you, I have not audited whether the full surface on :3773 authenticates. Either way the toggle, the persisted setting, and the actual bind should agree, and "Limited to this machine" should not be shown while the port answers on the LAN.

   Possibly related

   t3 connect status prints Publish agent activity: enabled while the Settings UI shows that toggle off — another CLI/UI disagreement in the same panel, which may share the "CLI reads persisted value, UI reads runtime state" shape. Happy to split that out if it is unrelated.
2. labeebbappu commented on Oct 10, 2026

   

   labeebbappu

   on Oct 10, 2026

   More actions

   Correction to my previous comment — my proposed mechanism was wrong

   Retracting the hypothesis in my comment above. The observations stand; the explanation does not. I read further into app.asar and the divergence I proposed is not possible in this code path.

   Why the hypothesis fails

   I suggested the UI mode could fall back to local-only while the bind host stayed on the persisted network-accessible. It cannot: both values are produced by the same object, in the same branch.

   const resolveDesktopServerExposure = (input) => {
     if (input.mode === "local-only") return {
       mode: input.mode,
       bindHost: DESKTOP_LOOPBACK_HOST,   // <- loopback, always, in this branch
       localHttpUrl, localWsUrl, endpointUrl: null, advertisedHost: null
     };
     const advertisedHost = resolveLanAdvertisedHost(input.networkInterfaces, input.advertisedHostOverride);
     return {
       mode: input.mode,
       bindHost: DESKTOP_LAN_BIND_HOST,
       endpointUrl: advertisedHost ? `http://${advertisedHost}:${input.port}` : null,
       advertisedHost
     };
   };

   mode: "local-only" always implies bindHost: DESKTOP_LOOPBACK_HOST. Downstream, getState (toContractState) and backendConfig (toBackendConfig) both read the same stateRef, so the UI mode and the listener's bind host cannot disagree by this route.

   What the resolver actually does on this machine

   const unavailable =
     input.requestedMode === "network-accessible"
     && requestedExposure.endpointUrl === null
     && !Object.values(input.networkInterfaces).some((addresses) =>
          addresses?.some((a) => !a.internal && a.family === "IPv4" && isTailscaleIpv4Address(a.address)));

   The downgrade to local-only requires no usable LAN IPv4 and no Tailscale IPv4. This Mac has both a LAN address (192.168.1.x) and a Tailscale address (100.x.x.x). resolveLanAdvertisedHost skips Tailscale addresses but accepts 192.168.1.x, so endpointUrl is non-null, unavailable is false, and the resolved state should be network-accessible with endpointUrl: http://192.168.1.x:3773.

   So the 0.0.0.0 bind is correct for the persisted setting. My earlier framing had it backwards.

   What I think the actual defect is here

   The listener is right; the Settings panel is wrong. It shows Network access — "Limited to this machine" while the resolved exposure state is network-accessible with a live advertised endpoint.

   One candidate, offered as a lead rather than a conclusion: the service seeds its state with

   const stateRef = yield* make$88(initialRuntimeState());

   and initialRuntimeState() is built from DEFAULT_DESKTOP_SETTINGS.serverExposureMode (local-only) with port: 0. If the panel renders that seed instead of the state written by configureFromSettings, it would show exactly "Limited to this machine" regardless of the real bind. I have not confirmed this; the bootstrap lines that would show it had already rotated out of server.trace.ndjson.

   This may not belong on this issue

   Given the above, my case is probably not the same root cause as the original report:

   • [Bug]: WSL backend binds 0.0.0.0 while "Network access" is off and the UI says "Limited to this machine" #9056 as filed: Network access off, backend nevertheless bound to 0.0.0.0 — the listener exceeds the setting.
   • My case: Network access persisted on, backend correctly bound to 0.0.0.0, UI falsely reports "Limited to this machine" — the display contradicts the setting and the socket.

   The user-visible hazard is identical, and "Limited to this machine" is untrue in both, which is why I posted here. But the fixes are likely in different places. Happy to move mine to its own issue if a maintainer prefers that — say the word and I will, and I'll link it back here.

   Apologies for the noise of a wrong mechanism; I would rather correct it in place than leave it standing.