[Bug]: T3 Connect fails to open environment: endpoint_request_failed on Windows → iOS #8844

Activity

1. Noahtarp

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Aug 31, 2026
2. shivamhwp commented on Sep 8, 2026

   

   shivamhwp

   on Sep 8, 2026

   Collaborator

   More actions

   Note: GPT-6 on behalf of shivam (@shivamhwp).

   The existing report gives us the versions, local reachability, and a relay trace ID. To narrow down why opening the environment fails, could you provide these details?

   1. Did you run t3 connect link directly in a terminal on the Windows host, or through SSH, a forwarded port, or a proxy? How do you normally start T3, and do you use a custom --home-dir?
   2. Does opening this same environment through T3 Connect in the web app fail too? Please include the error if it does. This is a separate check from opening 127.0.0.1:3773 locally.
   3. Make one more failed connection attempt from iOS, then immediately run the PowerShell snippet below on the Windows host. Please share the timestamp, the new error/trace ID, and relevant connection-related output. Please also mention if the server or iOS version has changed since the report.

   The snippet reads recent local traces. It does not restart T3 or change the connection setup. If you launch T3 with --home-dir, set $t3DiagHome to that directory before the $t3DiagTrace line.

   Get-Date -Format o
   $t3DiagHome = Join-Path $env:USERPROFILE '.t3'
   if ($env:T3CODE_HOME) { $t3DiagHome = $env:T3CODE_HOME }
   # If T3 was started with --home-dir, replace $t3DiagHome with that directory.
   $t3DiagTrace = Join-Path $t3DiagHome 'userdata/logs/server.trace.ndjson'
   if (Test-Path -LiteralPath $t3DiagTrace) {
       $t3DiagMatches = @(Get-Content -LiteralPath $t3DiagTrace -Tail 2000 |
           Select-String -Pattern 'mintCredential|mint-credential|relay|cloudflared|tunnel' |
           Select-Object -Last 30 -ExpandProperty Line)
       if ($t3DiagMatches.Count -gt 0) { $t3DiagMatches }
       else { 'No connection-related entries found in the last 2000 lines.' }
   } else {
       "Trace file not found: $t3DiagTrace"
   }

   Please review the output before posting and remove credentials, tokens, pairing links, or private project/conversation content. If there are no matching entries or the file is missing, just report that; an empty result alone does not establish whether the request reached the computer.

   Also copy any T3 terminal errors or "Relay client" / cloudflared warnings that appeared around that attempt. T3 captures output from its managed cloudflared process, so there is no need to start another tunnel. If you run cloudflared separately, include its errors from the same time.

   For a maintainer with relay observability access: could you look up the existing trace 3b4c5cf5a3bf5af6788ace70ab71afa8, or the fresh trace from the reporter, and identify the failing operation plus any upstream HTTP status or underlying network error? That would help establish why the credential request failed. The reporter should not need access to internal relay logs.
3. harshalite commented on Oct 5, 2026

   

   harshalite

   on Oct 5, 2026

   Last edited by harshalite

   More actions

   Additional Windows/mobile T3 Connect evidence from t3 triage. This may be the same failure as this issue; the exact root cause remains unconfirmed.

   The user reports that mobile connections began failing with the Orchestrator V2 release. Windows desktop version: 0.0.46-nightly.20261005.2667, OS x64 10.0.26200. Phone OS and mobile app version were not provided.

   Workflow: start the Windows desktop environment with its existing state, use T3 Connect, then open that environment in the mobile app. The phone reports "relay environment timed out" and "endpoint request failed". A clean-install reproduction has not been performed.

   Verified evidence:

   • A live local cloudflared check returned /ready = 200, cloudflared_tunnel_ha_connections = 4, cloudflared_tunnel_request_errors = 60, and cloudflared_tunnel_total_requests = 60. TCP connections to the backend at 127.0.0.1:3773 succeed. This is not proof of a successful authenticated API request.
   • On October 5, 2026, the backend logged five distinct event-loop stalls at 13:30:11, 13:30:44, 13:31:20, 13:31:55 and 13:32:30 IST: 29,635 / 13,554 / 7,468 / 7,875 / 9,511 ms respectively.
   • After deduplicating repeated captured output, there are 91 distinct environment API warning lines on October 5. Warning details include errorTag: Interrupt and backend trace ID 78b2de49cee02210d373e7d01c772939. This trace has not been matched to the phone's displayed trace ID.
   • At 13:32:01 IST, the backend logged Failed to register T3 Connect managed tunnel recovery; the formatted cause contains only [Object] details.
   • statev2.sqlite is 6,491,475,968 bytes. This is diagnostic context, not proof that SQLite causes the stalls.

   Matching release source constructs the managed origin using loopback and the actual listener port: server.ts. Its recovery fallback can reuse stored configuration that may target a stale port: cloud/http.ts.

   Interrupt indicates Effect cancellation, not its trigger. The recovery warning is a separate non-interrupt failure. Remaining possibilities include stale remote ingress after recovery failure and backend starvation during request handling. Related slow-config reports: #14516 and #14517; neither proves this incident's cause.

   The retained server traces have rolled past the incident window. The next discriminating evidence is the active tunnel ingress destination and a correlated mobile request with backend profiling and relay-side tracing. No settings, source, tunnel configuration or database data were changed. No credentials or home-directory paths are included.

   Prepared by OpenAI Codex triage GPT sol 6.1