Repository navigation
[Bug]: Desktop-linked environment never re-registers its port after restart; stale relay ingress when 3773 is taken #12641
Description
Activity
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 (
resolveDesktopBackendPortstill scans from3773inapps/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 onCloudCliState.readCliDesiredCloudLink, which is set only byt3 connect link. UI/mobile linking (apps/web/src/cloud/linkEnvironment.ts) never sets that secret, anduseCloudLinkControllerre-links only when managed-tunnel mode changes — not when the listen port changes.That split is intentional today.
releaseManagedTunnelOnShutdowninapps/server/src/cloud/http.tssays 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 keepshttp://127.0.0.1:3773.In this report,
3773was a different environment (WSLt3 serveundernetworkingMode=mirrored). Health JWTs are audience-bound, so that process correctly returns401 Invalid cloud health request. The relay then surfacesendpoint_request_failed. Connector/configshowing"service":"http://127.0.0.1:3773"while the desktop backend is on3774matches this.Verified against current HEAD (
d6f291303); the cited paths from52d08a14are 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 (
runtimeConfigKeydoes 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
3773and same-home split-brain. fix(desktop): refuse same-home port fallback #9003 would stop the silent hop to3774, but if3773is another environment the Windows tunnel still points at the wrong listener.
Fix direction
Do not only set
CLOUD_CLI_DESIRED_LINK_SECRETafter a UI link.reconcileDesiredCloudLinkrequires a CLI token (cliTokenManager.getExisting) and will fail with “Runt3 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=3773and move the other3773listener (for WSL: systemd drop-inEnvironment=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).
- [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 (
- added a commit that references this issue
on Sep 25, 2026 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-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.
Before submitting
Area
apps/desktop
Steps to reproduce
networkingMode=mirrored: runt3 service installinside WSL (the service binds 127.0.0.1:3773, which is visible to Windows in mirrored mode). Any other listener on 3773 works too.selected backend port via sequential scanwithport: 3774.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 /configon 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 WSLt3 serveinstance (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:The startup reconcile in
server.tsis gated onCloudCliState.readCliDesiredCloudLink, which is only set byt3 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.tssendsoriginonly 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 installinside WSL. Remote client: macOS desktop 0.0.42.Logs or stack traces
desktop.trace.ndjson:
server.trace.ndjson (the server actually receiving the relay traffic):
Windows connector
GET 127.0.0.1:20242/config:Workaround
Set
T3CODE_PORT=3773as 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 withEnvironment=T3CODE_PORT=3790, it re-registers on startup).