[Bug]: Desktop-linked environment never re-registers its port after restart; stale relay ingress when 3773 is taken

[PrinceJunkie]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. On the Windows desktop app, link the local environment to T3 Connect via the UI while the backend is on the default port 3773.
2. Make 3773 unavailable before the next start. Easy way on Windows with WSL networkingMode=mirrored: run t3 service install inside WSL (the service binds 127.0.0.1:3773, which is visible to Windows in mirrored mode). Any other listener on 3773 works too.
3. Restart the desktop app. It logs selected backend port via sequential scan with port: 3774.
4. Connect to this environment from another device through T3 Connect.

Expected behavior

After a restart the backend re-registers its current loopback origin with the relay, the same way CLI-linked servers do on startup (apps/server/src/server.ts, "T3 Connect desired link reconciled on startup"). Alternatively the desktop should keep using the port that was registered at link time and fail loudly if it cannot.

Actual behavior

The managed tunnel keeps the origin from link time. cloudflared /config on the Windows connector still shows "service":"http://127.0.0.1:3773" while the backend listens on 3774. Every relay request is forwarded to 3773; in my case that was the WSL t3 serve instance (a different environment id), which answers 401 (Invalid cloud health request). Connector metrics: cloudflared_tunnel_response_by_code{status_code="401"} 91, total_requests 92. Remote clients show:

T3 Connect · Reconnecting: Relay could not reach the environment endpoint (endpoint_request_failed).

The startup reconcile in server.ts is gated on CloudCliState.readCliDesiredCloudLink, which is only set by t3 connect link, so UI-linked desktop environments have no code path that updates the origin. The desktop also does not re-link on port change (apps/web/src/cloud/linkEnvironment.ts sends origin only at link time).

Related: #7458 (same symptom on the service update path), #6097 (desktop scanning past 3773 when a service is running).

Impact

Blocks work completely (remote access to the Windows environment is dead until the environment is unlinked and re-linked from the UI, or the port is pinned).

Version or commit

Desktop 0.0.42 (Windows), server 0.0.42. Verified against repo HEAD 52d08a1: apps/desktop/src/app/DesktopApp.ts:73-101 (scan), apps/server/src/server.ts:743-763 (CLI-only reconcile).

Environment

Windows 11 host, WSL2 Ubuntu with networkingMode=mirrored, t3 service install inside WSL. Remote client: macOS desktop 0.0.42.

Logs or stack traces

desktop.trace.ndjson:

"selected backend port via sequential scan" {"port":3774,"startPort":3773}

server.trace.ndjson (the server actually receiving the relay traffic):

environment.cloud.health Failure EnvironmentHttpUnauthorizedError: Invalid cloud health request.

Windows connector GET 127.0.0.1:20242/config:

{"hostname":"prod-….t3coderelay.com","service":"http://127.0.0.1:3773"}

Workaround

Set T3CODE_PORT=3773 as a user environment variable on Windows (the desktop honours it, DesktopConfig.ts:44) and move any other listener off 3773 (for the WSL service: systemd drop-in with Environment=T3CODE_PORT=3790, it re-registers on startup).

[juliusmarminge]

Triage

Confirmed. This is a real bug, not a duplicate of #7458 or #6097.

What happens

A desktop environment linked through the T3 Connect UI records the loopback origin only at link time. After a restart, the embedded backend can land on a different port (resolveDesktopBackendPort still scans from 3773 in apps/desktop/src/app/DesktopApp.ts). The managed Cloudflare tunnel is not updated.

Startup reconcile in apps/server/src/server.ts ("T3 Connect desired link reconciled on startup") is gated on CloudCliState.readCliDesiredCloudLink, which is set only by t3 connect link. UI/mobile linking (apps/web/src/cloud/linkEnvironment.ts) never sets that secret, and useCloudLinkController re-links only when managed-tunnel mode changes — not when the listen port changes.

That split is intentional today. releaseManagedTunnelOnShutdown in apps/server/src/cloud/http.ts says a web/mobile-installed link has no boot-time re-provision path and comes back by reapplying the stored connector token. The origin lives in Cloudflare ingress (ManagedEndpointProvider.provision → putConfiguration), so the connector keeps http://127.0.0.1:3773.

In this report, 3773 was a different environment (WSL t3 serve under networkingMode=mirrored). Health JWTs are audience-bound, so that process correctly returns 401 Invalid cloud health request. The relay then surfaces endpoint_request_failed. Connector /config showing "service":"http://127.0.0.1:3773" while the desktop backend is on 3774 matches this.

Verified against current HEAD (d6f291303); the cited paths from 52d08a14 are unchanged.

Related, not the same

• [Bug]: Service update leaves T3 Connect relay targeting stale origin port #7458 — same user-visible failure on the CLI/service path, where reconcile does run but the connector/origin can still be stale (runtimeConfigKey does not include origin).
• [Bug]: Desktop starts a second backend against the background service database #6097 / fix(desktop): refuse same-home port fallback #9003 — desktop scanning past 3773 and same-home split-brain. fix(desktop): refuse same-home port fallback #9003 would stop the silent hop to 3774, but if 3773 is another environment the Windows tunnel still points at the wrong listener.

Fix direction

Do not only set CLOUD_CLI_DESIRED_LINK_SECRET after a UI link. reconcileDesiredCloudLink requires a CLI token (cliTokenManager.getExisting) and will fail with “Run t3 connect link…” for UI-linked desktops.

Needed: a UI/mobile-linked environment must re-provision the current loopback origin on start (Clerk re-link from the desktop/web session when signed in, or a server/relay origin-update that does not need the CLI). Complementary: persist/pin the linked port and fail loudly if it cannot bind.

Workaround

Still valid: set Windows user env T3CODE_PORT=3773 and move the other 3773 listener (for WSL: systemd drop-in Environment=T3CODE_PORT=3790). CLI-linked servers already re-register on startup. Unlink + re-link from the desktop UI also repairs the tunnel until the next port change.

Severity: high (remote access to that environment is dead until unlink/re-link or a pin).

[juliusmarminge]

Thanks for taking the time to report this and provide the details. We revisited it during the orchestrator V2 cleanup.

Current startup registers managed tunnel recovery with localOrigin even for non-CLI links, then confirms the origin before activation. This adds the UI-linked boot-time origin update missing in the report.

I’m closing this based on the current source and the evidence in this thread.

Source reviewed.

Source-level fix; hosted relay must support the registration endpoint. No live port-hop test run.

If you still hit this on a current build, please reply with the app/server versions and the steps that reproduce it. We can reopen this if the original problem is still there.