fix(desktop): keep the advertised LAN host in sync with the current network

[enisze]

Problem

Pairing a phone from the store build failed with:

Failed to fetch remote environment endpoint http://192.168.2.37:3773/.well-known/t3/environment (HttpClientError: Transport error)

The desktop resolves its LAN address once, during startup (configureFromSettings), and stores it in the exposure runtime state. Every later read — the Connections settings row, the pairing link, the QR code, the advertised-endpoint list — returned that stored string until the app relaunched.

In the reported case the desktop had been running for three days and had bootstrapped with endpointUrl: http://192.168.2.37:3773, while the machine had since moved to 192.168.1.21. The backend was bound to 0.0.0.0 and reachable at the new address the entire time; only the advertised host was stale, so the QR sent the phone to an IP nobody answers on.

Fix

Re-resolve the advertised host from the live interface list on every getState / getAdvertisedEndpoints call, reusing the existing resolveLanAdvertisedHost picker (so the T3CODE_DESKTOP_LAN_HOST override still wins).

• bindHost, localHttpUrl, and port are deliberately left untouched — picking up a new address never triggers a backend relaunch.
• A local-only run advertises nothing, including one that fell back to local-only for want of an address at boot: that run bound loopback only, so advertising an address that appeared later would point clients at a socket the process never listens on.

Tests

Two regression tests in DesktopServerExposure.test.ts:

• a machine that roams to another network mid-run — advertised host, endpoint URL, and endpoint list all follow it, while bind host and loopback URL stay put;
• a network-accessible request that fell back to local-only stays unadvertised when a LAN address shows up afterwards.

vp test run src/backend/DesktopServerExposure.test.ts → 11/11 pass, and the roaming test fails without the fix (Expected: "192.168.1.21" / Received: "192.168.2.37"). Lint and format clean.

🤖 Generated with Claude Code

[enisze]

Problem

Pairing a phone from the store build failed with:

Failed to fetch remote environment endpoint http://192.168.2.37:3773/.well-known/t3/environment (HttpClientError: Transport error)

The desktop resolves its LAN address once, during startup (configureFromSettings), and stores it in the exposure runtime state. Every later read — the Connections settings row, the pairing link, the QR code, the advertised-endpoint list — returned that stored string until the app relaunched.

In the reported case the desktop had been running for three days and had bootstrapped with endpointUrl: http://192.168.2.37:3773, while the machine had since moved to 192.168.1.21. The backend was bound to 0.0.0.0 and reachable at the new address the entire time; only the advertised host was stale, so the QR sent the phone to an IP nobody answers on.

Fix

Re-resolve the advertised host from the live interface list on every getState / getAdvertisedEndpoints call, reusing the existing resolveLanAdvertisedHost picker (so the T3CODE_DESKTOP_LAN_HOST override still wins).

• bindHost, localHttpUrl, and port are deliberately left untouched — picking up a new address never triggers a backend relaunch.
• A local-only run advertises nothing, including one that fell back to local-only for want of an address at boot: that run bound loopback only, so advertising an address that appeared later would point clients at a socket the process never listens on.

Tests

Two regression tests in DesktopServerExposure.test.ts:

• a machine that roams to another network mid-run — advertised host, endpoint URL, and endpoint list all follow it, while bind host and loopback URL stay put;
• a network-accessible request that fell back to local-only stays unadvertised when a LAN address shows up afterwards.

vp test run src/backend/DesktopServerExposure.test.ts → 11/11 pass, and the roaming test fails without the fix (Expected: "192.168.1.21" / Received: "192.168.2.37"). Lint and format clean.

🤖 Generated with Claude Code

[enisze]

Problem

Pairing a phone from the store build failed with:

Failed to fetch remote environment endpoint http://192.168.2.37:3773/.well-known/t3/environment (HttpClientError: Transport error)

The desktop resolves its LAN address once, during startup (configureFromSettings), and stores it in the exposure runtime state. Every later read — the Connections settings row, the pairing link, the QR code, the advertised-endpoint list — returned that stored string until the app relaunched.

In the reported case the desktop had been running for three days and had bootstrapped with endpointUrl: http://192.168.2.37:3773, while the machine had since moved to 192.168.1.21. The backend was bound to 0.0.0.0 and reachable at the new address the entire time; only the advertised host was stale, so the QR sent the phone to an IP nobody answers on.

Fix

Re-resolve the advertised host from the live interface list on every getState / getAdvertisedEndpoints call, reusing the existing resolveLanAdvertisedHost picker (so the T3CODE_DESKTOP_LAN_HOST override still wins).

• bindHost, localHttpUrl, and port are deliberately left untouched — picking up a new address never triggers a backend relaunch.
• A local-only run advertises nothing, including one that fell back to local-only for want of an address at boot: that run bound loopback only, so advertising an address that appeared later would point clients at a socket the process never listens on.

Tests

Two regression tests in DesktopServerExposure.test.ts:

• a machine that roams to another network mid-run — advertised host, endpoint URL, and endpoint list all follow it, while bind host and loopback URL stay put;
• a network-accessible request that fell back to local-only stays unadvertised when a LAN address shows up afterwards.

vp test run src/backend/DesktopServerExposure.test.ts → 11/11 pass, and the roaming test fails without the fix (Expected: "192.168.1.21" / Received: "192.168.2.37"). Lint and format clean.

🤖 Generated with Claude Code

[enisze]

Problem

Pairing a phone from the store build failed with:

Failed to fetch remote environment endpoint http://192.168.2.37:3773/.well-known/t3/environment (HttpClientError: Transport error)

The desktop resolves its LAN address once, during startup (configureFromSettings), and stores it in the exposure runtime state. Every later read — the Connections settings row, the pairing link, the QR code, the advertised-endpoint list — returned that stored string until the app relaunched.

In the reported case the desktop had been running for three days and had bootstrapped with endpointUrl: http://192.168.2.37:3773, while the machine had since moved to 192.168.1.21. The backend was bound to 0.0.0.0 and reachable at the new address the entire time; only the advertised host was stale, so the QR sent the phone to an IP nobody answers on.

Fix

Re-resolve the advertised host from the live interface list on every getState / getAdvertisedEndpoints call, reusing the existing resolveLanAdvertisedHost picker (so the T3CODE_DESKTOP_LAN_HOST override still wins).

• bindHost, localHttpUrl, and port are deliberately left untouched — picking up a new address never triggers a backend relaunch.
• A local-only run advertises nothing, including one that fell back to local-only for want of an address at boot: that run bound loopback only, so advertising an address that appeared later would point clients at a socket the process never listens on.

Tests

Two regression tests in DesktopServerExposure.test.ts:

• a machine that roams to another network mid-run — advertised host, endpoint URL, and endpoint list all follow it, while bind host and loopback URL stay put;
• a network-accessible request that fell back to local-only stays unadvertised when a LAN address shows up afterwards.

vp test run src/backend/DesktopServerExposure.test.ts → 11/11 pass, and the roaming test fails without the fix (Expected: "192.168.1.21" / Received: "192.168.2.37"). Lint and format clean.

🤖 Generated with Claude Code

[enisze]

Problem

Pairing a phone from the store build failed with:

Failed to fetch remote environment endpoint http://192.168.2.37:3773/.well-known/t3/environment (HttpClientError: Transport error)

The desktop resolves its LAN address once, during startup (configureFromSettings), and stores it in the exposure runtime state. Every later read — the Connections settings row, the pairing link, the QR code, the advertised-endpoint list — returned that stored string until the app relaunched.

In the reported case the desktop had been running for three days and had bootstrapped with endpointUrl: http://192.168.2.37:3773, while the machine had since moved to 192.168.1.21. The backend was bound to 0.0.0.0 and reachable at the new address the entire time; only the advertised host was stale, so the QR sent the phone to an IP nobody answers on.

Fix

Re-resolve the advertised host from the live interface list on every getState / getAdvertisedEndpoints call, reusing the existing resolveLanAdvertisedHost picker (so the T3CODE_DESKTOP_LAN_HOST override still wins).

• bindHost, localHttpUrl, and port are deliberately left untouched — picking up a new address never triggers a backend relaunch.
• A local-only run advertises nothing, including one that fell back to local-only for want of an address at boot: that run bound loopback only, so advertising an address that appeared later would point clients at a socket the process never listens on.

Tests

Two regression tests in DesktopServerExposure.test.ts:

• a machine that roams to another network mid-run — advertised host, endpoint URL, and endpoint list all follow it, while bind host and loopback URL stay put;
• a network-accessible request that fell back to local-only stays unadvertised when a LAN address shows up afterwards.

vp test run src/backend/DesktopServerExposure.test.ts → 11/11 pass, and the roaming test fails without the fix (Expected: "192.168.1.21" / Received: "192.168.2.37"). Lint and format clean.

🤖 Generated with Claude Code

[enisze]

Problem

Pairing a phone from the store build failed with:

Failed to fetch remote environment endpoint http://192.168.2.37:3773/.well-known/t3/environment (HttpClientError: Transport error)

The desktop resolves its LAN address once, during startup (configureFromSettings), and stores it in the exposure runtime state. Every later read — the Connections settings row, the pairing link, the QR code, the advertised-endpoint list — returned that stored string until the app relaunched.

In the reported case the desktop had been running for three days and had bootstrapped with endpointUrl: http://192.168.2.37:3773, while the machine had since moved to 192.168.1.21. The backend was bound to 0.0.0.0 and reachable at the new address the entire time; only the advertised host was stale, so the QR sent the phone to an IP nobody answers on.

Fix

Re-resolve the advertised host from the live interface list on every getState / getAdvertisedEndpoints call, reusing the existing resolveLanAdvertisedHost picker (so the T3CODE_DESKTOP_LAN_HOST override still wins).

• bindHost, localHttpUrl, and port are deliberately left untouched — picking up a new address never triggers a backend relaunch.
• A local-only run advertises nothing, including one that fell back to local-only for want of an address at boot: that run bound loopback only, so advertising an address that appeared later would point clients at a socket the process never listens on.

Tests

Two regression tests in DesktopServerExposure.test.ts:

• a machine that roams to another network mid-run — advertised host, endpoint URL, and endpoint list all follow it, while bind host and loopback URL stay put;
• a network-accessible request that fell back to local-only stays unadvertised when a LAN address shows up afterwards.

vp test run src/backend/DesktopServerExposure.test.ts → 11/11 pass, and the roaming test fails without the fix (Expected: "192.168.1.21" / Received: "192.168.2.37"). Lint and format clean.

🤖 Generated with Claude Code

[enisze]

Problem

Pairing a phone from the store build failed with:

Failed to fetch remote environment endpoint http://192.168.2.37:3773/.well-known/t3/environment (HttpClientError: Transport error)

The desktop resolves its LAN address once, during startup (configureFromSettings), and stores it in the exposure runtime state. Every later read — the Connections settings row, the pairing link, the QR code, the advertised-endpoint list — returned that stored string until the app relaunched.

In the reported case the desktop had been running for three days and had bootstrapped with endpointUrl: http://192.168.2.37:3773, while the machine had since moved to 192.168.1.21. The backend was bound to 0.0.0.0 and reachable at the new address the entire time; only the advertised host was stale, so the QR sent the phone to an IP nobody answers on.

Fix

Re-resolve the advertised host from the live interface list on every getState / getAdvertisedEndpoints call, reusing the existing resolveLanAdvertisedHost picker (so the T3CODE_DESKTOP_LAN_HOST override still wins).

• bindHost, localHttpUrl, and port are deliberately left untouched — picking up a new address never triggers a backend relaunch.
• A local-only run advertises nothing, including one that fell back to local-only for want of an address at boot: that run bound loopback only, so advertising an address that appeared later would point clients at a socket the process never listens on.

Tests

Two regression tests in DesktopServerExposure.test.ts:

• a machine that roams to another network mid-run — advertised host, endpoint URL, and endpoint list all follow it, while bind host and loopback URL stay put;
• a network-accessible request that fell back to local-only stays unadvertised when a LAN address shows up afterwards.

vp test run src/backend/DesktopServerExposure.test.ts → 11/11 pass, and the roaming test fails without the fix (Expected: "192.168.1.21" / Received: "192.168.2.37"). Lint and format clean.

🤖 Generated with Claude Code

[enisze]

Problem

Pairing a phone from the store build failed with:

Failed to fetch remote environment endpoint http://192.168.2.37:3773/.well-known/t3/environment (HttpClientError: Transport error)

The desktop resolves its LAN address once, during startup (configureFromSettings), and stores it in the exposure runtime state. Every later read — the Connections settings row, the pairing link, the QR code, the advertised-endpoint list — returned that stored string until the app relaunched.

In the reported case the desktop had been running for three days and had bootstrapped with endpointUrl: http://192.168.2.37:3773, while the machine had since moved to 192.168.1.21. The backend was bound to 0.0.0.0 and reachable at the new address the entire time; only the advertised host was stale, so the QR sent the phone to an IP nobody answers on.

Fix

Re-resolve the advertised host from the live interface list on every getState / getAdvertisedEndpoints call, reusing the existing resolveLanAdvertisedHost picker (so the T3CODE_DESKTOP_LAN_HOST override still wins).

• bindHost, localHttpUrl, and port are deliberately left untouched — picking up a new address never triggers a backend relaunch.
• A local-only run advertises nothing, including one that fell back to local-only for want of an address at boot: that run bound loopback only, so advertising an address that appeared later would point clients at a socket the process never listens on.

Tests

Two regression tests in DesktopServerExposure.test.ts:

• a machine that roams to another network mid-run — advertised host, endpoint URL, and endpoint list all follow it, while bind host and loopback URL stay put;
• a network-accessible request that fell back to local-only stays unadvertised when a LAN address shows up afterwards.

vp test run src/backend/DesktopServerExposure.test.ts → 11/11 pass, and the roaming test fails without the fix (Expected: "192.168.1.21" / Received: "192.168.2.37"). Lint and format clean.

🤖 Generated with Claude Code