[Bug]: T3 Connect managed endpoint provisioning fails repeatedly on Windows 11

[New2thisshit]

Before submitting

• I searched existing issues. Related: [Bug]: T3 Connect managed endpoint provisioning fails for Windows environment #13681, which involved a different environment and was closed after a later retry worked.
• I included reproduction details and trace IDs.

Area

T3 Connect hosted relay provisioning, triggered from the Windows desktop app.

Steps to reproduce

1. On the Windows host, open T3 Code 0.0.42 → Settings → Connections.
2. Enable T3 Connect for the local environment.
3. The toggle returns to off after the relay request fails.
4. Retry. The failure recurs with a new trace ID, and the mobile app cannot connect to this machine.

Expected behavior

T3 Connect provisions a managed endpoint and the environment becomes available to my mobile T3 app.

Actual behavior

The desktop app reports:

https://relay.t3.codes/v1/client/environment-links failed:
Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).

The local T3 server remains available on 127.0.0.1:3773. The relay health endpoint responds, but no cloudflared connector starts because provisioning fails before a tunnel token is returned.

Impact

Mobile access to this Windows environment through T3 Connect is blocked. Local desktop use still works.

Environment

• T3 Code desktop stable 0.0.42
• Windows 11 Pro, build 26200
• Local server bound to 127.0.0.1:3773
• Date: 2026-09-28

Trace IDs

• Initial user-reported failure: fe743ccef63184b15eebc7f6d03dae13
• Reproduced in Settings: 58a420de14b2a8e16b258082462bfac8
• Retry in Settings: b528e164721834faeeb4d9dff930d04c
• Latest user-reported failure: cf8e4071a1013229da78780a2cd32029

Could the relay team inspect the failing stage and cause in relay.managed_endpoint_provider.provision for these traces? The client only exposes managed_endpoint_provisioning_failed. I have not reset the environment ID or changed local credentials.

[juliusmarminge]

Triage

This is a hosted-relay provisioning failure, not a Windows client or cloudflared install failure. The report is specific enough to investigate. It is the same client-visible failure as #13681, but not a duplicate: that report was a different environment, closed after a later retry worked with the cause unconfirmed. These four attempts are still failing.

POST /v1/client/environment-links returned environment_link_unavailable / managed_endpoint_provisioning_failed. That reason is only produced when ManagedEndpointProvider.provision fails (infra/relay/src/http/Api.ts). The desktop string matches relayProtectedErrorMessage for RelayEnvironmentLinkUnavailableError. By the time provision runs, the link proof has 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 why there is nothing useful to deregister. The environment link row is written only after provision returns (EnvironmentLinker.link). A failure here leaves no Account → T3 Connect registration. Local cloudflared is not on this path either: Settings calls ensureRelayClientAvailable before the link request, and the connector is started only after the relay returns a tunnel token. A missing binary would be a different client error and would not reach this response. Relay health responding is expected; it is a different route.

What this response already rules out:

• Missing relay config. That is managed_endpoint_not_configured.
• The per-account tunnel cap (default 3). A cap hit is environment_link_limit_exceeded and names the maximum.
• The 9s relay deadline. That response is a 504 relay_request_deadline_exceeded, and the client would not show this reason.
• 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.9.1 #11184 (bump managed cloudflared). None of those run before this response.

0.0.42 is still the latest stable desktop release. Updating it will not change this path. The client drops the failure stage. The relay error carries stage plus hostname, tunnel name, and tunnel id when it has them. Provision 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 span is relay.managed_endpoint_provider.provision, annotated with relay.environment_id, relay.managed_endpoint.origin_host, and relay.managed_endpoint.origin_port. The environment id is not in this report; it is on that span. Please do not reset it. A new id would only hide a wedged relay_managed_endpoint_allocations row.

Please look these up in t3-code-relay-traces-prod before changing code:

• fe743ccef63184b15eebc7f6d03dae13 (initial)
• 58a420de14b2a8e16b258082462bfac8 (Settings)
• b528e164721834faeeb4d9dff930d04c (Settings retry)
• cf8e4071a1013229da78780a2cd32029 (latest)

Each retry got a new trace and the same reason, so this is not a consumed nonce and not a one-off client timeout. The stage distinguishes a Cloudflare create/config/DNS/token error from a stuck allocation whose generation claim no longer matches. Since #9386, an offline host releases its Cloudflare tunnel and the next provision recreates it under the same name; a lost claim is supposed to be retryable. The same stage and environment id across all four traces, with no successful provisions in that window, means the allocation for this environment is wedged rather than a single Cloudflare blip.

[dom-devel]

Also seeing this on macOS, so it isn't Windows-specific.

https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed). Trace ID: a8ccbaf9770d93ff3f457945c84cd3ec

• T3 Code (Alpha) 0.0.42, macOS 26.3 (arm64), desktop app, Settings → Connections → T3 Connect
• Fresh install with no earlier cloud link state. Port 3773 is held by T3 Code itself.
• Local desktop use still works.

[vycdev]

I'm also seeing this on Windows with T3 Code 0.0.42. Retrying from Settings → Connections after restarting T3 Code still fails with:

https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).

Latest trace ID: b7785eb3b0dd083a3f640595ec3b50ec

Updating the Codex CLI and restarting resolved a separate local Codex detection problem, but T3 Connect provisioning still fails. Could the relay team inspect the failing provisioning stage for this trace?