[Bug]: Google SSO spinner then no browser after abandoning the first T3 Connect sign-in #13322

Activity

1. juliusmarminge commented on Sep 23, 2026

   

   juliusmarminge

   on Sep 23, 2026

   Member

   More actions

   The second Google click is rejected in the desktop main process before shell.openExternal runs. The Google button’s spinner is Clerk clearing a failed attempt, not a new browser launch.

   T3 Connect sign-in on desktop is Clerk’s prebuilt modal (clerk.openSignIn in apps/web/src/components/clerk/useT3ConnectAuthPrompt.tsx), backed by createClerkBridge in apps/desktop/src/app/DesktopClerk.ts. The bridge registers @clerk/electron’s OAuth transport. On Google, clerk-js calls transport.open(verificationUrl). In 0.0.44 that handler:

   1. Refuses a second call while one flow is stored: Clerk: an OAuth flow is already pending.
   2. Otherwise calls shell.openExternal, then waits for a t3code://app/ callback.
   3. Drops that wait only when the callback arrives, after 180 seconds (Clerk: OAuth callback timed out.), or when the bridge is torn down.

   Closing the Google tab does not send a callback. Closing the in-app modal does not cancel the IPC call. The main-process slot stays occupied, so every later Google click throws immediately and never opens a browser. Fully quitting works because the slot is process memory. On Windows, closing the last window quits the app, which is the same recovery. Waiting out the 180-second timeout should release the slot as well. That path is what the published transport does. It was not part of the report.

   The missing error is also in Clerk’s UI (@clerk/clerk-js 6.32.1). SocialButtons sets the button loading, and on a thrown error it waits 1 second and calls setIdle() without setError. handleError rethrows this string because it is not a Clerk API or runtime error, so the modal never shows “an OAuth flow is already pending.”

   The lock is one slot for every social provider, not Google-specific, and it lives in the shared Electron main process. The report is Windows 11. macOS and Linux should fail the same way when the first attempt is abandoned before the custom-scheme callback. This repo has no cancel hook around the bridge, and 0.0.45 did not add one.

   Upstream fix: replace or cancel the pending flow when a new open starts, or when the renderer drops the in-flight invoke because the modal closed. Until Clerk does that, the only in-repo fix is a patch of oauth-transport in @clerk/electron.
2. juliusmarminge

   added

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

   upstream

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 23, 2026
3. t3dotgg commented on Oct 21, 2026

   

   t3dotgg

   on Oct 21, 2026

   Member

   More actions

   Note

   🤖 Claude Opus 5.5 responding on behalf of Theo

   Thanks for the report. This fault is outside T3 Code, so we cannot fix it here. Please report it to the project that owns that tool. If you find a fault in T3 Code itself, please open a new issue with steps to reproduce it.
4. t3dotgg

   closed this as not plannedon Oct 21, 2026
5. steve-cooks commented on Oct 21, 2026

   

   steve-cooks

   on Oct 21, 2026

   Contributor

   More actions

   Reported upstream as suggested:

   • Fix PR: fix(electron): replace a stale pending OAuth flow instead of blocking new sign-ins clerk/javascript#10334. A new open replaces a stale pending flow instead of throwing an OAuth flow is already pending. It also validates the URL first and only lets a launch failure dispose its own flow.
   • Follow-up issue: [@clerk/electron] OAuth callback is not matched to the attempt that started it clerk/javascript#10335. The callback isn't tied to the attempt that started it, which matters once flows can be replaced.

   Until that ships, #22708 carries the same transport fix as a @clerk/electron patch, which is the in-repo option described above. It also adds a Cancel bar on desktop so an abandoned browser sign-in can be reset without closing the sheet.