[Bug]: Android T3 Account stays Checking and all T3 Connect environments fail until app relaunch #24306

Activity

1. andybergon commented on Oct 29, 2026

   

   andybergon

   on Oct 29, 2026

   More actions

   I hit this on Android too: T3 Account was disabled and stuck on “Checking”, and connecting to an environment showed “Waiting for the T3 Connect sign-in to load.”

   Force-stopping T3 Code from Android Settings and reopening it restored connectivity.
2. MylesWardell commented on Oct 30, 2026

   

   MylesWardell

   on Oct 30, 2026 – with ChatGPT Codex Connector

   More actions

   Note

   🤖 GPT-6.1-Sol responding on behalf of MylesWardell

   Additional Android case on Pixel 8 Pro with T3 Code 2.2.0, versionCode 735, inspected over USB on October 30. A saved T3 Connect environment repeatedly failed, and the user reported grey “Checking” after five retries.

   The expanded connection diagnostics provided the full error missing from the original report:

   Cause: session-pending
   Route: T3 Connect
   App version: 2.2.0
   Error: Waiting for the T3 Connect sign-in to load.
   

   The headline instead said “T3 Code on [host] did not answer.” The diagnostic UI marked this device, T3 Connect, and the tunnel as passing, then marked the host application as failed. This directs troubleshooting toward the desktop even though the recorded error is a client sign-in initialization wait.

   During the failure, desktop checks reported tunnel readiness HTTP 200 and four connections; t3 connect status also passed with four QUIC connections. The public endpoint responded from the desktop. Those checks do not establish phone-side HTTPS reachability. Android reported validated Wi-Fi, and the phone and PC clocks were within a few seconds.

   The user confirmed recovery after being advised to force-stop/reopen the phone app, with sign-out/sign-in as a fallback. The exact step they used was not captured, so this is not a controlled force-stop-only recovery test. The initial trigger remains unknown, and no expired token or underlying Clerk/network failure was established.

   This supports investigating both recovery from a persistently pending mobile sign-in and the misleading host-failure headline. It adds a 2.2.0 occurrence to this existing issue; it does not establish a shared underlying cause with the original report.
3. sasensi commented on Oct 30, 2026

   

   sasensi

   on Oct 30, 2026

   More actions

   Additional report from October 30, 2026: mobile 2.2.0 connecting through T3 Connect to a Windows x64 desktop running T3 Code (Beta) 0.1.5. The same session-pending error and misleading host-failure headline occurred. Posting here rather than opening a duplicate.

   Observed workflow and impact

   1. Attempt to connect from the phone to the already-linked desktop environment.
   2. The phone repeatedly reports that T3 Code on the desktop did not answer and automatically retries without recovering. The captured diagnostics show five attempts.
   3. Open the desktop app: it remains usable and responds normally.
   4. On the phone, open Settings → Environments → the machine → Details → Copy diagnostics. The complete captured output is below.

   Remote access from the phone was unavailable during this episode. The initial trigger, outage duration, recurrence rate, phone OS/model, and mobile build number were not established. This is an observed incident, not a deterministic reproduction recipe.

   Complete phone diagnostics

   T3 Code connection to DESKTOP-OG4K9PI: T3 Code on DESKTOP-OG4K9PI did not answer
   
   This device: ok
   T3 Connect: ok
   DESKTOP-OG4K9PI tunnel: ok
   T3 Code on DESKTOP-OG4K9PI: FAILED
   
   Cause: session-pending
   Attempts: 5
   Next retry: 2026-10-30T20:01:01.710Z
   Route: T3 Connect
   App version: 2.2.0
   Host version: 0.1.5
   Error: Waiting for the T3 Connect sign-in to load.
   
   More info: https://github.com/pingdotgg/t3code/blob/main/docs/user/t3-connect-troubleshooting.md#the-tunnel-works-but-t3-code-does-not-answer
   

   Independent desktop checks during troubleshooting

   • The desktop app was usable; Windows also reported its processes as responding.
   • Its local backend answered an environment diagnostic request and reported server version 0.1.5.
   • The server runtime reported a loopback listener on 127.0.0.1:3773.
   • Desktop Settings → Sharing & access showed T3 Connect enabled, with the text “This environment is available to your other devices through T3 Connect.” and “Tunnel connected · 4 connections · QUIC.” It reported one of three tunnel slots in use, so this was not a displayed tunnel-limit failure.
   • A request from the PC through the environment's public tunnel URL to /.well-known/t3/environment returned HTTP 200 in 575 ms. Server traces also contained successful HTTP 200 requests to that endpoint. These checks establish host-side reachability at the time of the checks, not the phone's end-to-end authorization or network reachability.
   • The installed cloudflared client was available, version 2026.10.4.
   • For completeness, the bundled CLI's t3 connect status --json returned linked: true, revoked: false, linkMode: "managed", and an available relay client, but also desired: false, authenticated: false, and reachability: null. That CLI result was inconclusive about the live desktop connection; the desktop UI independently showed sharing enabled and an active tunnel. It should not be presented as a successful CLI reachability check.

   No desktop restart, tunnel reset, account relink, firewall change, or installed-app modification was performed during this troubleshooting.

   Recovery

   The reporter was advised to fully close and reopen the phone app, then, if the error persisted, sign out of T3 Connect on the phone and sign back into the same account used on the desktop. The reporter confirmed that it worked afterward.

   The exact recovery step used was not captured. This is therefore not proof that reopening alone or signing in again alone fixes the issue.

   Source-level finding: the diagnostic points at the wrong component

   Read-only inspection of source commit 6d450a4284852af137b2f3407fddd89eb76e7644 found the exact error string:

   • authorization/service.ts constructs a ConnectionTransientError with reason session-pending and detail Waiting for the T3 Connect sign-in to load.
   • getDpopToken returns that error when cloudSession.identity is absent, before obtaining a bootstrap credential or performing remote authorization.
   • connection/diagnosis.ts has no dedicated session-pending diagnosis. Its generic classification/headline path can label this as the server failing to answer, matching the captured phone output.

   This identifies the meaning of the recorded error and a diagnostic-classification problem. It does not establish why the mobile cloud identity stayed unavailable, prove an expired token or Clerk outage, or establish that the inspected source commit exactly matches the shipped mobile build.

   Expected behavior

   • A persistently pending mobile sign-in should recover once the account becomes ready, or offer an actionable phone-side recovery path.
   • session-pending should be described as mobile sign-in initialization, rather than a desktop/server failure. Downstream checks should not imply that the desktop failed to answer when the authorization attempt has not reached that stage.
   • The diagnostic's troubleshooting link should direct the user to the relevant sign-in guidance.

   Prepared by GPT-6.1-Sol through the Codex harness in T3 Code, on behalf of the reporter. No credentials or full private logs are attached.
4. alltomstales-dotcom commented on Oct 31, 2026

   

   alltomstales-dotcom

   on Oct 31, 2026

   More actions

   Note

   Written with Claude Code (Claude Opus 5.5) on behalf of the account owner, from the host's server logs and a read of the client source. The phone side was not instrumented.

   Another occurrence, and this one has a repeatable trigger: the phone's screen locks or the phone sleeps, and on wake the T3 Connect environment never reconnects. It happened four times in one day (2026-10-30). Each time the phone app showed "T3 Code on did not answer · Retrying · attempt N". The host had stayed up throughout.

   Setup

   • Phone: Pixel 9a, Android, native app. Tailscale is on the phone.
   • Host: Linux x64 (WSL2), t3 0.1.5 running as a systemd user service. T3 Connect is linked, and t3 connect status passes ("Tunnel connected · 4 connections · QUIC") during every failure.
   • One environment, three saved routes: LAN (an unreachable WSL NAT address), Tailscale, and T3 Connect.

   What the host's trace shows (server.trace.ndjson)

   A good connect (e.g. 00:50:57Z and 01:04:02Z) all happens within about 1 s over the direct Tailscale route:

   GET  /.well-known/t3/environment     200   (x2: route check + descriptor)
   POST /api/auth/websocket-ticket/rpc  200
   GET  /ws
   GET  /api/orchestration/shell        200
   GET  /api/auth/session               200
   

   After a wake (episodes starting about 11:20Z, 21:27Z, 00:59Z and 01:26Z), the phone only ever sends this, every 15–60 s:

   GET  /.well-known/t3/environment     200   (x2, ~2 ms each)
   

   • It never sends a POST /api/auth/websocket-ticket/rpc.
   • No relay-originated /api/t3-connect/mint-credential or /oauth/token arrives through the tunnel either.

   So the route check succeeds. The attempt then stops inside the client before it makes any authenticated request. That points to the session-pending path that @MylesWardell and @sasensi captured, not to the host or the tunnel.

   • Recovery: the episode at 00:59Z ended at 01:04Z, after the app was reopened.
   • Tunnel blip: one QUIC "no recent network activity" warning, about an hour before the 11:20Z episode. Otherwise nothing in the host log lines up with any of the episodes.

   Where it seems to stick (from reading the source at dd14848; not verified on a device)

   1. session-pending is raised in packages/client-runtime/src/authorization/service.ts (sessionPending) when cloudSession.identity is None at the start of an attempt.
   2. On mobile, identity reads managedRelaySessionAtom (apps/mobile/src/connection/platform.ts). Only cloudAccountService writes that atom, through activate, deactivate and detach, driven by Clerk's addListener emissions (packages/client-runtime/src/relay/cloudAccountService.ts).
   3. Connection retries re-read the atom, but nothing re-reads Clerk. The atom changes only when Clerk emits again. If the atom is null after a wake and Clerk has nothing new to emit, every retry hits session-pending until the process restarts. That matches the "T3 Account · Checking" state in the original report.

   Two ways the atom could end up empty after a resume, both unconfirmed:

   • A sign-out from a failed refresh: Clerk's session refresh on resume fails while the network is still coming up, and Clerk emits user: null. observe treats that as a sign-out and calls deactivate. If no later emission restores the user, nothing reactivates the account.
   • A failed activation: prepare throws during a re-activation. The state becomes Failed, and observe retries only on the next emission for the same account.

   Possible direction

   • When the app returns to the foreground (AppState → active), re-read the current Clerk user, after isLoaded, and feed it through observe. That way a missed or transient emission can't leave the relay session empty until a cold start.
   • Separately, the headline for session-pending should name the phone's sign-in, not "T3 Code on did not answer". That headline sent us debugging the host first.

   Workaround

   • Force-stop and reopen the app.
   • Or add the same host as a direct environment from a t3 pair link over Tailscale (a bearer route that does not depend on the cloud session).
5. spsrohan commented on Oct 31, 2026

   

   spsrohan

   on Oct 31, 2026 – with ChatGPT Codex Connector

   More actions

   Another Android occurrence on October 31, 2026. Exiting and reopening the phone app restored connectivity. An Android force-stop was not reported.

   The phone had connected successfully to this desktop for over a day before it stopped working. It then reported that T3 Code on the desktop did not answer, with:

   Cause: session-pending
   Error: Waiting for the T3 Connect sign-in to load
   

   The phone’s T3 Account row was stuck on “Checking” and could not be selected.

   On the desktop, Settings → Sharing & access showed the T3 Connect toggle off while reporting one of three tunnels in use. Enabling the toggle did not restore the phone connection. Exiting and reopening the Android app afterward did.

   During troubleshooting, the desktop’s local server answered /.well-known/t3/environment and reported version 0.1.5. Server traces recorded successful managed tunnel activation and subsequent reachability checks. These checks do not establish phone-side connectivity.

   The desktop client identified itself in traces as Windows version 0.1.5, with the backend running under WSL2. The Android app version was not captured. The initial trigger is unknown, and no phone-side logs were collected, so the underlying cause remains unconfirmed.

   Prepared with Codex in T3 Code. The exact model identifier was unavailable to the session.
6. imadtg commented on Nov 3, 2026

   

   imadtg

   on Nov 3, 2026

   More actions

   Confirmed another occurrence on Android app 2.2.0, reported as the latest Play Store beta. Connecting worked the previous day.

   Host: Linux, T3 Code 0.1.7-nightly.20261101.4016, running as a background service.

   Phone diagnostics:

   T3 Code on <host> did not answer
   This device: ok
   T3 Code on <host>: FAILED
   Cause: session-pending
   Attempts: 1
   Route: Direct
   Error: Waiting for the T3 Connect sign-in to load.
   

   During investigation, the host answered locally and t3 connect status reported reachability with four QUIC connections. Force-stopping and reopening the Android app restored access. No host restart or configuration change was needed.

   The misleading host-failure message matches #29338, addressed by #29352. This occurrence also provides evidence of the underlying Android sign-in stall; its trigger remains unknown.

   Prepared by GPT-6 through Codex on behalf of the reporter.
7. mrpbaum commented on Nov 7, 2026

   

   mrpbaum

   on Nov 7, 2026

   More actions

   Hello human here. I'm using the PWA and constantly getting "Failed to reconnect, retrying...". Closing the app and reopening works sometimes, sometimes not. Eventually always works. Perhaps needs a longer pause for server side connection to close properly.

   This sucks plz fix. I chose T3 for its mobile functionality and I'm sure I'm not alone.