[Bug]: Account controls and T3 Connect stay unavailable after Clerk UI load failure until Reload#15725

Triage

Thanks for the careful write-up, and for separating this from the misleading status text, @coygeek. I didn't rerun the original network change. The stuck state after failed_to_load_clerk_ui is still there on main at 4ee6bfd50e. Nightly 5a96895 is an ancestor of that commit, and these files haven't changed since.

What I found

This is separate from #11004. That issue covers the "cloud sign-in changed" message while a session is pending, and it recovers by itself. Here Clerk never finishes loading.

• While Clerk is unloaded, useAuth reports isLoaded: false and isSignedIn: undefined. ConfiguredT3ConnectSidebarAvatar and ConfiguredT3ConnectSidebarSignIn both return null in that state, so the footer shows no controls, no error, and no retry. The app doesn't use Clerk's ClerkFailed state.
• ManagedRelayAuthProvider exits early while !isLoaded, so activateManagedRelayAuthentication never runs. The saved remote environment has no cloud identity, assertSession treats that as sessionChanged(), and the row shows "Your cloud sign-in changed." The T3 Connect and activity switches stay disabled.
• Nothing retries in the same renderer. @clerk/react 6.16.1 starts getEntryChunks() once. If that rejects, it sets status to "error" and never calls clerk.load(). @clerk/electron 0.0.44 caches the UI-loading promise for the publishable key, including a rejected one, so later renders get the same failure.
• View > Reload starts a fresh renderer, so the cached promise is gone and the saved desktop token signs back in. That matches recovering without a new login or a local server restart.

Likely fix area

• Show a visible failure and a retry in the settings footer when the Clerk status is "error".
• A retry would have to drop the cached rejected UI promise. Remounting ClerkProvider in the same document isn't enough on its own. Once isLoaded recovers, the existing activation path should pick up the saved login.
• Rewording the "sign-in changed" message belongs in #11004.

A maintainer will decide on the fix direction.

Hit this today on desktop 0.0.46-nightly.20261010.2935, on macOS 27.0.1 (Apple Silicon). It happened right after a macOS update reboot, on a phone hotspot while the network was still coming up.

• Settings showed neither the account avatar nor "Sign in to T3 Connect".
• The saved T3 Connect environment showed Connection failed: Your cloud sign-in changed. Sign in again to authorize the environment.
• 30+ minutes later the network was fine. From the same Mac, clerk.t3.codes, relay.t3.codes/health and the host's tunnel /.well-known/t3/environment all returned 200. The host's server logs showed no connection attempt from this client since the reboot.
• Turning the environment off and on in Settings did not help. Each attempt fails immediately because the relay session atom is still null (see #11004). The row's ⋯ menu has no retry action, so the only way out the UI hints at, signing in, wasn't available.
• View > Reload fixed it, with no sign-in and without restarting the local server.

I didn't capture the renderer console, so I can't say whether it was the UI-script failure or the FAPI failure. Reading the dependencies, neither recovers:

• FAPI failure. In @clerk/clerk-js 6.32.1, the Electron load path (#tg) fetches /v1/environment and /v1/client with 4 tries when navigator.onLine is true. On failure it rethrows, because no __internal_getCachedResources fallback is wired. load() then sets status to "error". Nothing listens for online or focus to try again.
• IsomorphicClerk. In @clerk/react 6.16.1, getEntryChunks() runs once from the constructor. Its catch only emits status: "error", so loaded stays false. useAuth() returns isLoaded: false for both "loading" and "error".
• UI script. In @clerk/electron 0.0.44, loadClerkUI caches the UI-script promise at module level, including a rejected one. So remounting ClerkProvider alone would not recover the UI-script case.
• T3 Code. It never reads useClerk().status, so "error" is shown the same as "still loading".

Suggested direction: watch useClerk().status === "error". On online, focus, or a periodic retry, remount the provider under a new key, and reset the cached UI promise. Show a visible "Couldn't reach T3 Connect · Retry" state in the account footer instead of rendering nothing.

Additional affected environment: Linux desktop 0.1.0

Reporting a Linux instance of the missing account/sign-in controls symptom. This is a potential match to this issue, not confirmation of the same Clerk download failure. The original triggering transition and renderer console error have not been captured.

Environment

• Official Linux amd64 .deb, package t3code 0.1.0.
• Installed release tag source checkout: v0.1.0, commit 81493efb71e8e8244f95d3e9f71d8369654ab151.
• Installed /opt/T3 Code (Beta)/resources/app.asar SHA256: 54e2346258da31c28761984a0cca48bba5de4918e506ce65e340c2a28d000c16.
• Ubuntu 26.10 x86_64, kernel 7.3.0-9-generic, Intel i7-8550U, 16GB RAM.
• Xfce session 4.20.4-1, X11 through xrdp 0.10.6.1-2ubuntu1.
• gnome-keyring 51.1-1 and libsecret-1-0 0.21.7-2build1 installed. A separate Chrome launch reported a locked default keyring, so keyring availability/unlock in this desktop process is not established. This is not an assertion that Secret Service is functioning or that #7689 is ruled out.
• xrdp GUI session uses a private /tmp/dbus-* session bus; systemd user services use /run/user/1000/bus. A physical Xfce login also exists for this user.
• Desktop is remote-only (localEnvironmentEnabled: false); an independent t3code.service owns the local environment. Desktop process executable is the packaged Electron app, not a browser tab or source/dev build.

Observed workflow

1. Open the packaged desktop in the xrdp session.
2. Open Settings > Connections.
3. Inspect the Settings sidebar footer: it has Back and a small refresh/status icon, but neither an account avatar nor Sign in to T3 Connect.
4. Connections shows No environment selected, Local environment off, No saved remote environments, and Add environment. Add environment offers Remote link / SSH, not an account sign-in route.
5. The app gives no visible authentication initialization failure or retry explanation.

This was observed before and after successfully authorizing the separate host CLI; CLI credentials should not be presumed to sign in the desktop client. We are not reporting that the desktop must automatically inherit CLI credentials. The defect is the missing client account/sign-in entry point.

Expected

An unsigned-in Linux desktop client, including remote-only mode, should expose T3 Connect account sign-in. If authentication initialization cannot finish, show an actionable error/retry instead of hiding the entry point. The upstream remote-access docs explicitly support T3 Connect and remote-only desktops; the account component has no Linux exclusion.

Checks and boundaries

• Inspected the shipped client assets inside app.asar: Clerk publishable-key, JWT-template and HTTPS relay configuration are present. No private credentials or bundled telemetry values are included here.
• At tag v0.1.0, apps/web/src/components/clerk/T3ConnectSidebarSignIn.tsx returns null while useAuth().isLoaded is false. apps/web/src/cloud/publicConfig.ts additionally gates on public config. This supports a possible initialization failure path, but the running renderer's isLoaded value has not been measured.
• desktop.trace.ndjson includes a successful desktop.clerk.configure span. That alone does not establish completed renderer authentication/UI initialization.
• A separate shell HTTPS GET with redirects to https://clerk.t3.codes/npm/@clerk/ui@1/dist/ui.browser.js returned HTTP 200. This does not establish the renderer can fetch it.
• Ctrl+R was attempted and controls remained absent. We did not establish that this shortcut actually triggered a reload in this packaged app; therefore this is not a confirmed failure of the issue's View > Reload workaround.
• t3 connect login --headless completed, then t3 connect link --headless installed the managed relay client. After restarting the independent background service, t3 connect status --base-dir ~/.t3 reported Exposure enabled, stored authorization, environment provisioned and relay provisioned. Service logs recorded multiple registered tunnel connections. This restores host exposure, not the missing desktop sign-in UI.

Impact: desktop users cannot discover/initiate their account login from the UI; CLI host exposure is a partial workaround. Browser/provider logins and all application data were left intact. Root cause and whether this is specific to xrdp, private D-Bus, locked keyring, or another startup condition remain unconfirmed. Please split into a separate issue if the Linux failure is distinct.

Fresh triage on main at b5a226e49c: inspected the account footer and Electron Clerk provider. Both account controls still return nothing while Clerk is unloaded. This is source inspection, not a runtime reproduction. Checked 947 open issues; the discovery failure in #17106 and saved-environment deletion in #17917 describe different symptoms.

The restoration check requires an authenticated desktop client and a saved T3 Connect environment; that session is unavailable here. No network-disruption or reload recovery test was run. Recovery involves authentication initialization, which this triage workflow reserves for maintainer review. Leaving this issue open for Julius; no fix PR. This is classified as an ordinary bug, with no exploitable vulnerability reported.

Rechecked v0.1.1 and main at 96bae546. I would keep this open. Both account controls still disappear while Clerk is unloaded, and there is no initialization-error/retry state in the footer. A focused probe of the pinned Clerk Electron loaders (0.1.1 and 0.1.3) also confirms that a failed UI load remains cached after connectivity is restored. #11013 fixes the downstream missing-session diagnosis/retry behavior, but does not recover Clerk or restore the account controls. This was source inspection plus a pure loader probe, not a new desktop network-disruption reproduction; recovery of both the saved login and remote connection still needs a controlled desktop check.

A hosted-web case of the same stuck state. It differs from desktop in four ways: it is in the browser, the clerk-js script failed rather than the UI bundle, it followed a sleep/wake, and it landed on a thread route. Seen on app.t3.codes 0.1.6 in Chrome 154 on macOS, with server 0.1.2 on Linux. This is from a report, not reproduced independently.

Observed

• The Mac slept for several hours. About 11 s after the lid opened, the open tab navigated itself. It was a navigate entry, not a reload, and document.wasDiscarded was false. What triggered the navigation is unknown.
• About 16 s later, the console logged Clerk: Failed to load Clerk JS (code="failed_to_load_clerk_js"), thrown from getClerkJsEntryChunk.
  • The gap fits the loader's default 15 s scriptLoadTimeout. It isn't confirmed, because the resource-timing buffer was already full before the script request.
• window.Clerk was still undefined 12+ minutes later.
• The server received no requests from the tab after wake: no websocket ticket and no /ws. A manual fetch of the environment's /.well-known/t3/environment from the same tab returned 200 in about 150 ms.
• The tab was on a thread route. The only signal was the composer banner "‹env› is reconnecting · T3 Code on ‹env› did not answer". It offered no retry and said nothing about sign-in.
• Dispatching online, focus and visibilitychange in the tab didn't help. A plain reload fixed it immediately.

How it maps to the code (source reading on main at 7195b69954)

• With Clerk never loaded, the account service in apps/web/src/cloud/managedAuth.tsx never sees a user, so the relay session stays unset.
• getDpopToken in packages/client-runtime/src/authorization/service.ts then fails with the transient session-pending error added in #11013, and the supervisor keeps retrying.
  • That explains authorization stopping before a websocket ticket is created.
  • Zero server requests is consistent with a relay-only route. A direct endpoint would be verified first.
• session-pending has no hop, so locate() in packages/client-runtime/src/connection/diagnosis.ts falls through to the server hop. The headline then blames the host: "T3 Code on ‹host› did not answer".
• After getEntryChunks() fails, nothing restarts it. That includes online and visibilitychange. The online listener in apps/web/src/connection/platform.ts only feeds the connection supervisor.

So this is the same defect reaching the browser through clerk-js, with a misleading banner on top.

Investigated with Claude Opus 5.5 in T3 Code; reviewed by GPT-6 Astra via Codex.

Same stuck state on the macOS desktop app, recovered by Reload, while other clients on the same account connected fine at the same time.

Observed

• Desktop app on a MacBook (Apple M5), Settings → Environments: both saved T3 Connect environments (a Linux server and a second Mac) showed "This device is still loading its T3 Connect sign-in", retrying with backoff (attempt 7, next retry 90 s / 120 s).
• The desktop app's own environment row read "T3 Connect is on. Reachability has not been checked yet.", so the app did not consider itself signed out (per SavedEnvironmentRows.tsx, that text is only shown when signedOut is false).
• At the same time, app.t3.codes in a browser and the desktop app on another Mac reached the same Linux server through T3 Connect without problems.
• Cmd+R in the desktop app fixed it: both environments connected.

Diagnosis

• getDpopToken (packages/client-runtime/src/authorization/service.ts) raises session-pending while cloudSession.identity is empty, so no relay attempt was made from this client.
• The host side was healthy throughout: server 0.1.10-nightly.20261113.4630 running as a systemd service; its managed relay tunnel registered at 10:36 UTC and was still proxying requests from other clients at 11:37 UTC (relay-client.ndjson, only "context canceled" client disconnects).
• Because another client on the same account worked concurrently, the account and relay were fine; the stuck state is local to the desktop renderer's cloud session, consistent with this issue. A Retry in that state (#23620) would have recovered it without a reload.

Environment

• Client: T3 Code desktop on macOS, Apple M5, version: unknown
• Host: Linux x64, server 0.1.10-nightly.20261113.4630, managed T3 Connect tunnel
• Trigger before the stall: unknown

Related: #29337 (closed as duplicate of this), #24306 (Android, same symptom).

Triaged with Claude Code (Claude Opus 5.5) via t3 triage.

@linksmith One clarification: #23620's Retry does reload the renderer—retryClerkLoad() calls window.location.reload(). The improvement is a visible recovery control in Settings.

At the current head (5adf81b), "Retry T3 Connect" appears in the Settings sidebar footer when useClerk().status === "error", before the loaded/signed-in checks. Your report doesn't establish that status; a renderer remaining in loading would not get this control.

The pinned Electron Clerk loader retains a rejected UI-loading promise until reload, so that failure mode is consistent with your symptoms. Other clients working concurrently supports a client-local problem, but doesn't establish this particular cause. Console/network evidence and Clerk status would help distinguish it next time.

The environment rows remain unchanged while sign-in is pending. The thread banner now has an environment "Retry now" action, but still no Clerk reload action. Recovery of both an existing account and a saved remote connection through the new Settings control still needs the signed-in verification requested on the PR.