Repository navigation
[Bug]: WSL + T3 Connection not publishing workspaces #5210
Description
Activity
Could not obtain environment link proof: Invalid managed endpoint origin.
same issue.
any updates on this issue?
I had the same issue and was able to fix in by adding a line to
.wslconfig:[wsl2] networkingMode=mirroredI had the same issue and was able to fix in by adding a line to
.wslconfig:[wsl2] networkingMode=mirroredThis fix worked for me as well, thanks.
Reacted by JakaI've added the
networkingMode=mirroredto.wslconfig, and restarted the wsl, but it's still not working. The same error:Could not obtain environment link proof: Invalid managed endpoint origin..Continuing here from #11567 (closed as duplicate). Adding the root cause and a workaround that does not require changing WSL networking, since neither is in this thread yet.
Root cause (checked against v0.0.40)
- The desktop app talks to the WSL backend via the distro's
hostname -Iaddress (172.x.x.x) instead of127.0.0.1(DesktopBackendConfiguration.ts~L629–641,DesktopWslEnvironment.tsgetDistroIpImpl). - The server only issues a link proof when the request itself is addressed to a loopback host (
apps/server/src/cloud/http.ts,isAllowedEndpointOrigin). A request arriving on172.x.x.xis always rejected withInvalid managed endpoint origin.
Why
networkingMode=mirroredworks for some people but not othersIn mirrored mode the app switches to
127.0.0.1only if the first IPv4 fromhostname -Iequals a Windows interface address (isLocalHostIpv4). If the first entry is something that exists only inside the distro, for example a Docker bridge or a VPN interface, detection fails and the app keeps using that address, so the error remains. That would fit the report above that mirrored mode did not help, though I have not verified that specific setup.Workaround without mirrored mode (verified on Windows 11, WSL 2, Ubuntu, "Use only WSL")
Run in the WSL shell:
npx t3@0.0.40 connect login --headless npx t3@0.0.40 connect linkThen fully restart the desktop app. Do not also run
npx t3 serve, even though the CLI suggests it, because the desktop app already manages the backend. On startup the backend requests the proof fromhttp://127.0.0.1:<port>itself (server.ts~L717), the link provisions, and the mobile app connects.npx t3@0.0.40 connect statusthen showsEnvironment link: provisioned.Possible fixes
- Issue the link proof through the backend's own loopback path (as the CLI path already does) instead of from the renderer, or
- use
127.0.0.1for the link-proof request when the backend is WSL.
Written by Claude (Anthropic) during a maintenance session, at the request of the account owner, who reproduced the error and confirmed the workaround.
Reacted by Caleb Ditchfield- The desktop app talks to the WSL backend via the distro's
Trying this with nightly, after
t3 connect link, backend link provision hasn't happened, status shows not provisioned, and backend has the same error.@MVPavan thanks for testing. Short version: the workaround path is unchanged in nightly, but your
not provisionedstatus means the backend never saw a pending link. My earlier comment pinnedt3@0.0.40, which no longer matches current builds. Updated steps:Updated steps (WSL shell, same distro and user as the desktop app, no
sudo)T3="$(ls -td ~/.t3/wsl-runtime/*/ | head -1)t3" # t3 binary bundled with your desktop build "$T3" --version # should match the desktop app version "$T3" connect link --headless "$T3" connect status # expect: Environment link: pending server startupThen quit the desktop app completely, including the tray icon, and start it again. The backend can wait up to 30 s before it links. After that,
"$T3" connect statusshould showEnvironment link: provisioned.Do not touch the T3 Connect toggle in the desktop app while doing this. Switching it on hits the bug, and switching it off clears the pending link.
Why
connect statussaysnot provisionedonly when there is no stored credential or no pending link (connect.ts L186–190). After a successfulconnect linkit sayspending server startup. Likely causes: a CLI that does not match the desktop build (headless login switched to the OAuth device flow in feat(server): use Clerk's device authorization grant for headless connect login #11794), or running the CLI in a different distro, as a different user, or withT3CODE_HOME/--base-dirset.- The startup path still requests the proof from
http://127.0.0.1:<port>(server.ts L804), so it passes the loopback check.Invalid managed endpoint origincomes from the toggle in the desktop app, which still sends the request to the WSL address (linkEnvironment.ts L298–312). The original bug is still present in nightly. - Switching the toggle off calls
unlink, which also clears the pending CLI link (http.ts L1335).
If it still fails
If status shows
pending server startupbut never reachesprovisionedafter a full restart, please post the fullconnect statusoutput and any backend log lines containingT3 Connect, especiallyFailed to reconcile T3 Connect desired link on startup. That would mean a real regression in the startup path.Checked against nightly
8ed276c(0.0.46-nightly.20261003.2610). On our side, desktop v0.0.45 with a WSL backend staysprovisionedacross restarts. I have not re-run a fresh link on nightly, because that would mean unlinking a working setup.
Written by Claude (Anthropic) during a maintenance session, at the request of the account owner.
@Raphi54 It worked for provisioning; however, it still couldn't connect, below error, same error in mobile as well.
Its resolved, this was my windows desktop env error, since i have switched to wsl backend its not being used. Though one issue in desktop UI is T3 connect doesn't reflect the wsl backed T3 connect correctly.
Before submitting
Area
apps/web
Steps to reproduce
I am using full only WSL with T3 connect, but cannot publish any workspaces to T3 connect, see attached screenshot. Are there any missing packages I need to install, to make it work with WSL?
Expected behavior
Should let me publish the workspaces
Actual behavior
Hangs, see screenshot for error
Impact
Major degradation or frequent failure
Version or commit
No response
Environment
Windows 11 w/ WSL 2.0 and Ubuntu
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
No response