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

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Summary

In T3 Code Nightly 0.0.46-nightly.20261004.2648 on macOS, a failed Clerk UI script download left the Settings footer with neither the account avatar nor the "Sign in to T3 Connect" control. A previously connected remote environment could not reconnect through T3 Connect. A separate shell HTTPS request to the exact Clerk UI script URL succeeded while the running app remained in this state. The failing renderer's connectivity before reload was not directly established. View > Reload restored the existing account and remote connection without signing in again or restarting the local server.

Steps to reproduce

The known case involved two Apple Silicon Macs running the same nightly build with identical app.asar hashes. Both had previously been signed in to the same T3 Connect account. The initial network transition was not captured and has not been deliberately reproduced.

In the observed failing desktop app, open Settings > Connections. The account footer has neither an avatar nor a sign-in button, and the previously saved remote environment reports a cloud sign-in error.
Inspect the renderer console. In this case the Clerk UI script reported ERR_NAME_NOT_RESOLVED and ERR_NETWORK_CHANGED, and the account initialization reported failed_to_load_clerk_ui.
In the observed case, a separate unauthenticated shell HTTPS request to the exact Clerk UI script URL returned HTTP 200, while the running renderer still displayed the failure and the footer and remote connection remained unavailable. The renderer's own connectivity before reload was not directly established.
Choose View > Reload. In the observed case, the account avatar and connected remote environment returned without another sign-in.

A proposed controlled reproduction is to make the Clerk UI script unavailable during renderer startup, then restore connectivity. That controlled transition was not run; the precise timing and conditions that produced the original failure are unknown. One existing failure and one successful reload recovery were observed, not a measured failure frequency.

Expected behavior

The desktop Settings > Connections workflow should expose the T3 Connect account controls and allow an already authenticated client to connect to its environment. If account initialization fails because a network dependency is temporarily unavailable, the UI should expose an actionable failure or retry path and permit recovery when connectivity returns. A valid saved login should remain usable.

Actual behavior

Both account controls were absent from the Settings footer. T3 Connect and activity publication switches were disabled. The saved remote environment showed "Connection failed: Your cloud sign-in changed. Sign in again to authorize the environment." There was no visible account initialization error or retry control in the footer.

The other Mac, running the identical desktop app bundle, still displayed its account avatar and a connected environment. This comparison was supplied by the user in a screenshot; installed version and bundle equality were checked directly. On the failing Mac, View > Reload restored the avatar, enabled the cloud controls, and changed the saved environment to "T3 Connect · Connected." The local server PID and start timestamp were unchanged. No sign-in, sign-out, token clearing, pairing change, network setting change, or host restart was performed.

Evidence

Expected source: docs/user/remote-access.md, T3 Connect section, documents the desktop Settings > Connections sign-in and environment workflow. The installed nightly source also renders signed-in and signed-out controls in apps/web/src/components/clerk/T3ConnectSidebarSignIn.tsx and includes them in apps/web/src/components/settings/SettingsSidebarNav.tsx.
Failure source: Direct observation of the affected macOS desktop Settings > Connections footer and renderer console on version 0.0.46-nightly.20261004.2648, followed by direct observation of successful recovery through View > Reload. The relevant sanitized console messages are included below.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: incomplete
Missing fact: The exact initial DNS or network transition and timing that caused the Clerk UI script download to fail. No controlled network-disruption rerun was performed.

Clerk: Failed to load Clerk UI
(code="failed_to_load_clerk_ui")

https://clerk.t3.codes/npm/@clerk/ui@1/dist/ui.browser.js
Failed to load resource: net::ERR_NAME_NOT_RESOLVED
Failed to load resource: net::ERR_NETWORK_CHANGED

Connection failed: Your cloud sign-in changed. Sign in again to authorize the environment.

The stack pointed to ElectronManagedAuthShell-CMN_Cdip.js:95 and dist-Z7xPpGBj.js:19. Source for the installed nightly is commit 5a96895. T3ConnectSidebarSignIn.tsx returns no account or sign-in control while Clerk isLoaded is false, and apps/web/src/cloud/managedAuth.tsx does not activate cloud authentication while it is false. These source observations support the failure path; they do not establish which network change initiated it.

The nightly resolves @clerk/electron 0.0.44. Its published React adapter loads Clerk UI from the CDN and caches the loading promise. See https://unpkg.com/@clerk/electron@0.0.44/dist/esm/react/index.js. The reload result shows the existing saved login remained usable in this case. It does not prove that an app update caused the failure.

Related issue #11004 concerns the misleading sign-in message while cloud identity is pending. This report focuses on recovery and visible feedback after the desktop Clerk UI download fails, with that message recorded as a downstream symptom.

Restoration check

Using a valid existing desktop login, cause the Clerk UI dependency to fail during initialization and then restore its availability. The app should show a visible actionable initialization failure or recovery control and recover the account controls and remote T3 Connect connection without clearing credentials, re-pairing, or restarting the local server. Verify both the avatar and a functioning remote connection, since displaying the avatar alone would not restore the full observed workflow. Keep the exact original transition marked unknown until a controlled reproduction establishes it.

Affected area

apps/desktop, with the account UI implemented in apps/web.

Runtime or environment

macOS, Apple Silicon, desktop app 0.0.46-nightly.20261004.2648. Both comparison machines ran the same app.asar bytes.

Impact

Major degradation: remote T3 Connect work was unavailable on the affected client until the renderer was reloaded. Local work and the other desktop client remained available.

Version or commit

0.0.46-nightly.20261004.2648

Workaround

View > Reload restored the account avatar and remote T3 Connect connection without another login or restarting the local server.

@coygeek

Note

Grok responding on behalf of Julius.

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 [Bug]: T3 Connect reports "Your cloud sign-in changed" when the host is just overloaded #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 [Bug]: T3 Connect reports "Your cloud sign-in changed" when the host is just overloaded #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 [Bug]: Desktop T3 Connect sign-in fails on Linux without a keyring — Clerk tokens can't persist, prepare_first_factor 401s #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

Open the packaged desktop in the xrdp session.
Open Settings > Connections.
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.
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.
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 96bae54. 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 7195b69)

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 fix(connect): stop reporting a loading cloud session as a sign-in change #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.

Navigation Menu

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

Before submitting

Area

Summary

Steps to reproduce

Expected behavior

Actual behavior

Evidence

Restoration check

Affected area

Runtime or environment

Impact

Version or commit

Workaround

Triage

What I found

Likely fix area

Additional affected environment: Linux desktop 0.1.0

Environment

Observed workflow

Expected

Checks and boundaries

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Before submitting

Area

Summary

Steps to reproduce

Expected behavior

Actual behavior

Evidence

Restoration check

Affected area

Runtime or environment

Impact

Version or commit

Workaround

Activity

juliusmarminge commented on Oct 4, 2026

Triage

What I found

Likely fix area

josephv123 commented on Oct 10, 2026

rwflan commented on Oct 16, 2026

Additional affected environment: Linux desktop 0.1.0

Environment

Observed workflow

Expected

Checks and boundaries

juliusmarminge commented on Oct 22, 2026

coygeek commented on Oct 22, 2026

THEtheChad commented on Nov 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions