Repository navigation
[Bug]: T3 Connect managed endpoint provisioning fails for Windows environment #13681
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
Not sure — T3 Connect hosted relay provisioning, triggered from apps/desktop.
Steps to reproduce
- Open the stock T3 Code 0.0.42 desktop app on Windows and sign into T3 Connect.
- Open Settings → Connections.
- Enable T3 Connect for the local Windows environment.
- Retry after the failure; the same error recurs with a new trace ID.
This reproduces for this particular Windows environment. I have not established whether it affects Windows generally.
Expected behavior
The environment provisions a managed endpoint and becomes available to my phone through T3 Connect.
Actual behavior
The request to https://relay.t3.codes/v1/client/environment-links fails with managed_endpoint_provisioning_failed.
The environment does not appear under Account → T3 Connect, so there is no registration there to deregister and retry.
The same account successfully provisioned a new Linux ARM64 VPS environment at approximately 2026-09-25 20:46 UTC, using the same T3 version and relay client version. That tunnel registered four connections, and its authenticated local link-state API reported linked=true and managedTunnelActive=true. An existing Linux desktop is also registered on the account.
Impact
Major degradation: T3 Connect cannot expose this Windows machine to my phone. Local desktop use still works.
Version or commit
Stock stable T3 Code 0.0.42 — not a custom fork build.
Environment
- Windows 11, build 22631, x64 desktop app.
- Managed cloudflared 2026.5.2 is installed; running its executable with
--versionsucceeds. - Local server listens at
http://127.0.0.1:3773/. - Windows environment ID:
fe3edb38-93ab-415d-88e6-3f761985dd1c.
Logs or stack traces
https://relay.t3.codes/v1/client/environment-links failed:
Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).
Original trace: 9a7ec73c7760cf473ffa0468a4e90ce6
Retry trace: ba420157f77192d48966318ef88cc73f
Retry time: approximately 2026-09-25 20:47 UTC
Workaround
No working T3 Connect workaround for this Windows environment yet. Retrying the desktop toggle did not help. I have not reset the environment ID or removed local history.
Could you inspect the failing provisioning stage using the retry trace? A stale/partial allocation is one possibility, but the client error does not establish the cause.
Activity
juliusmarminge commentedon Sep 25, 2026
Triage: this is a relay provisioning failure, not a Windows client or cloudflared install failure. The report is specific enough to investigate, and it is not a duplicate of the open Connect PRs.
POST /v1/client/environment-linksreturnedenvironment_link_unavailable/managed_endpoint_provisioning_failed. That string is only produced whenManagedEndpointProvider.provisionfails (infra/relay/src/http/Api.ts). By the time that runs, the link proof has already verified, the challenge nonce has been consumed, and the origin has passed the loopback check. A bad proof, a non-loopback origin, an insecure endpoint, or the managed-tunnel cap would be different codes (environment_link_proof_*,origin_not_allowed,endpoint_not_secure,environment_link_limit_exceeded).That also explains Account → T3 Connect. The environment link row is written only after provision returns (
EnvironmentLinker.link). A failure here leaves no registration to deregister. Localcloudflared 2026.5.2is not on this path either: the desktop checks the binary before the link request, and the connector is started only after the relay returns a tunnel token.What this rules out:
managed_endpoint_not_configured. The same account provisioned a Linux ARM64 environment on 0.0.42 about a minute earlier, so the base domain and namespace were working.relay_request_deadline_exceeded, not this error.Registered tunnel connection), chore(shared): bump managed cloudflared to 2026.10.0 #11184 (bump managed cloudflared). None of those run before this response. Nomanaged_endpoint_provisioning_failedissue exists, and nothing onmainsince v0.0.42 changes this failure path. 0.0.42 is still the latest stable release.The client drops the failure stage. The relay error carries
stageplus hostname, tunnel name, and tunnel id when it has them. Stages arederive-environment-hash,check-tunnel-limit(a limit-query persistence error, not the cap),reserve-allocation,ensure-tunnel,validate-tunnel-response,record-tunnel,configure-tunnel,ensure-dns-record,record-dns,get-tunnel-token, andmark-allocation-ready. The provision span isrelay.managed_endpoint_provider.provision, annotated withrelay.environment_id,relay.managed_endpoint.origin_host, andrelay.managed_endpoint.origin_port.Please look up both traces in
t3-code-relay-traces-prodbefore changing code or resetting the environment id. A new environment id would only hide a wedged allocation forfe3edb38-93ab-415d-88e6-3f761985dd1c.9a7ec73c7760cf473ffa0468a4e90ce6(first attempt)ba420157f77192d48966318ef88cc73f(retry, ~2026-09-25 20:47 UTC)The retry failing with a new trace means this is sticky to that environment, not a one-off Cloudflare blip and not evidence that Windows in general cannot provision. The stage distinguishes a Cloudflare create/config/DNS error for that hostname from a stuck
relay_managed_endpoint_allocationsrow whose generation claim no longer matches.thatmike1 commentedon Sep 25, 2026
Update: the reporter retried enabling T3 Connect in Windows Settings and it now works.
The installed Windows app is still 0.0.42 (file version 0.0.42.0), and v0.0.42 remains the latest stable release. No local app update, environment-ID reset, or allocation cleanup was performed during this investigation. The cause of the recovery is unconfirmed; I cannot tell whether provisioning recovered on its own or was repaired server-side.
Thanks for the detailed triage. Closing because the reported failure is no longer reproducible for this environment; the trace IDs remain above if useful for investigating the original cause.