[Bug]: T3 Connect reports "Your cloud sign-in changed" when the host is just overloaded #11004

Before submitting

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

Area

apps/web

(The failing logic is in packages/client-runtime, which the dropdown does not list. The message is surfaced by the web client, and the timing that triggers it comes from apps/web/src/cloud/managedAuth.tsx.)

Steps to reproduce

1. Sign in to T3 Connect and connect to a relay environment from the web client.
2. Put the host under heavy CPU/memory load. On a low-power arm64 single-board machine this happens on its own: two or three agent turns plus a build is enough to saturate it.
3. Watch the connection status while the machine is pegged.

Expected behavior

While the machine is overloaded the client should report a transient condition, something along the lines of "Reconnecting, the environment is slow to respond", or a timeout, and keep retrying. The sign-in is still valid and nothing about it changed.

Actual behavior

The connection status reads:

Failed to connect. Reconnecting... Reason: Your cloud sign-in changed. Sign in again to authorize the environment.

The sign-in did not change. Signing out and back in does nothing, because there is nothing wrong with the session. The connection recovers on its own once load drops, which is the tell that the message is describing the wrong cause. The practical cost is that the message sends you to fix an auth problem that does not exist instead of the load problem that does.

Impact

Minor bug or occasional failure (misleading diagnosis, self-recovering)

Version or commit

0.0.40. The string is present in the shipped bundle for that release, and the code below was read at main @ de37964db, whose package.json is also 0.0.40.

Environment

Low-power arm64 single-board Linux host, recent Node. Client is the T3 Code web app, connecting through T3 Connect. Nothing here looks hardware specific: any host slow enough to delay Clerk load or the activation promise chain should reproduce it.

Logs or stack traces

Failed to connect. Reconnecting... Reason: Your cloud sign-in changed. Sign in again to authorize the environment.

No stack trace: this is a handled ConnectionBlockedError rendered into the connection status line, not a throw.

Screenshots, recordings, or supporting files

None. The full text of the status line is quoted above.

Workaround

Wait for the load to drop. The connection recovers without any sign-in action.

Diagnosis

The message comes from sessionChanged() in packages/client-runtime/src/authorization/service.ts:224:

const sessionChanged = () =>
  new ConnectionBlockedError({
    reason: "authentication",
    detail: "Your cloud sign-in changed. Sign in again to authorize the environment.",
  });

It is raised by assertSession and by getDpopToken whenever cloudSession.identity is None, or is a different object reference than the identity captured when the attempt started. On web, identity is the managedRelaySessionAtom value (apps/web/src/connection/platform.ts:185), and that atom is null until ManagedRelayAuthProvider activates it.

Two things make "identity is not available yet" indistinguishable from "the user signed in as somebody else":

1. ManagedRelayAuthProvider (apps/web/src/cloud/managedAuth.tsx) bails out while !isLoaded (line 51), and even on the signed-in path it defers activateManagedRelayAuthentication behind a promise chain (activateAfterTransition, line 92). On a loaded machine, Clerk taking longer to load and that promise chain taking longer to drain both widen the window where the atom is still null while the connection supervisor is already attempting. Every attempt in that window fails with sessionChanged().
2. identity is compared by reference (current.value !== identity). Anything that replaces the session object rather than updating it in place reads as an account change. setManagedRelaySession deliberately keeps the object stable across same-account token refreshes, so this is handled for the common case, but the None case has no such guard and produces the same message.

Because sessionChanged() is a ConnectionBlockedError, the supervisor moves to blocked and parks. When activation finally lands, managedRelayAccountChanges fires the credentials-changed signal and the supervisor retries, carrying the stale failure into the next connecting state as lastFailure. That is exactly the "Failed to connect. Reconnecting... Reason: ..." shape from connectionStatusText in packages/client-runtime/src/connection/presentation.ts:68, and it explains why the message is shown while the client is in fact recovering.

Likely making it worse on a slow host: CACHED_ENDPOINT_SOCKET_TIMEOUT_MS is 3000 ms (service.ts:82). On an overloaded host the /api/auth/websocket-ticket round trip against a cached endpoint routinely exceeds that, so authorizeDpop discards a perfectly good access token, re-runs the full relay bootstrap and token exchange, and adds load to the host that is already the bottleneck. Each of those extra passes is another chance to hit the None-identity window above.

Suggested fix

Separate "the cloud session is not available yet" from "the cloud session changed":

• When cloudSession.identity is None and there is no evidence of an account switch, fail with a ConnectionTransientError (reason: "network", or a new session-pending) so the supervisor uses normal backoff and the UI says reconnecting rather than telling the user to sign in.
• Keep sessionChanged() for the real case: a captured identity whose accountId differs from the current one.
• Consider comparing accountId rather than object reference in assertSession, so an object replacement for an unchanged account cannot produce the message.
• Consider whether the 3 s cached-endpoint socket timeout should scale, or whether a timeout there should avoid throwing away the cached access token.