[Bug]: T3 Connect managed endpoint provisioning fails for Windows environment

[thatmike1]

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

1. Open the stock T3 Code 0.0.42 desktop app on Windows and sign into T3 Connect.
2. Open Settings → Connections.
3. Enable T3 Connect for the local Windows environment.
4. 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 --version succeeds.
• 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.

[juliusmarminge]

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-links returned environment_link_unavailable / managed_endpoint_provisioning_failed. That string is only produced when ManagedEndpointProvider.provision fails (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. Local cloudflared 2026.5.2 is 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:

• Missing relay config. That is 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.
• The per-account tunnel cap (default 3). A cap hit says how many tunnels are allowed and tells you to unlink one. Two linked environments (existing Linux desktop plus the new VPS) are under that cap, and "four connections" on the VPS tunnel are connector replicas, not four environments.
• A 9s relay deadline. That response is a 504 relay_request_deadline_exceeded, not this error.
• Open follow-ups that only matter after a link exists: fix(desktop): re-register Connect tunnel origin after backend port hop #12724 (re-register origin after a port hop), fix(server): use listener port for managed tunnel origins #8353 (listener port in the link proof), fix(server): wait for Cloudflare tunnel registration #8352 (wait for Registered tunnel connection), chore(shared): bump managed cloudflared to 2026.10.0 #11184 (bump managed cloudflared). None of those run before this response. No managed_endpoint_provisioning_failed issue exists, and nothing on main since 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 stage plus hostname, tunnel name, and tunnel id when it has them. Stages are derive-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, and mark-allocation-ready. The provision span is relay.managed_endpoint_provider.provision, annotated with relay.environment_id, relay.managed_endpoint.origin_host, and relay.managed_endpoint.origin_port.

Please look up both traces in t3-code-relay-traces-prod before changing code or resetting the environment id. A new environment id would only hide a wedged allocation for fe3edb38-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_allocations row whose generation claim no longer matches.

[thatmike1]

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.