[Bug]: Windows nightly: GitHub sign-in (T3 Connect) stalls on GitHub's "You are being redirected" page and never returns to the app #15574

Activity

1. juliusmarminge commented on Oct 4, 2026

   

   juliusmarminge

   on Oct 4, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks a lot for the detailed report, @Reflexoptics01, especially the registry and trace notes. I checked this against main (eac52f00). It looks like two separate problems are showing up together here.

   What I found

   The session not surviving a restart looks like #15001. Packaged Windows builds use %APPDATA%\t3code-v2. On first launch, if that profile has no Local State, it copies T3 Code (Alpha)\Local State when that file exists, and only then falls back to t3code:

   t3code/apps/desktop/src/app/DesktopUserData.ts

   Lines 59 to 66 in eac52f0

   	// Chromium databases require their own profile for each running version.
   	if (input.platform !== "win32") return destinationPath;
   	const destinationState = path.join(destinationPath, "Local State");
   	if (yield* inspect(destinationState)) return destinationPath;
   	const legacyState = path.join(legacyPath, "Local State");
   	const sourceState = (yield* inspect(legacyState))
   	? legacyState
   	: path.join(input.appDataDirectory, "t3code", "Local State");

   Clerk writes clerk-tokens.json encrypted with that profile's safeStorage key, and treats tokens it can't decrypt as signed out. #15001 already reports that 0.0.46-nightly.20261004.2644 still seeds the Alpha key, so a redirect fix alone wouldn't make an already-seeded profile keep its session.

   The stall on GitHub's page seems to be a different issue. That screen is GitHub's own interstitial while it tries to send the browser to the redirect target, and nothing in T3 Code runs until Windows actually launches t3code://. The trace doesn't show either way whether that happened: desktop.clerk.configure only means the listeners were registered, bootstrapRemoteBearerSession is the local environment token exchange, and Clerk's OAuth callback is handled inside @clerk/electron without creating a T3 span.

   On this build the desktop bridge asks Clerk for t3code://app/:

   t3code/apps/desktop/src/app/DesktopClerk.ts

   Lines 80 to 88 in eac52f0

   	function createDesktopClerkBridge(stateDir: string, isDevelopment: boolean) {
   	return createClerkBridge({
   	storage: storage({ path: stateDir }),
   	passkeys: true,
   	renderer: {
   	scheme: ElectronProtocol.getDesktopScheme(isDevelopment),
   	host: ElectronProtocol.DESKTOP_HOST,
   	},
   	});

   @clerk/electron 0.0.44 accepts a callback only when protocol, host, and pathname all match exactly, so t3code://app without the trailing slash would not match. On Windows the callback starts a second process, which forwards its arguments to the running app through the single-instance lock and quits. The registry entry being present doesn't confirm the browser invoked it; Edge and Chrome often won't follow a custom-scheme hop from GitHub's automatic refresh, which is where the "setup page" link comes in.

   If you have a moment, these would help narrow it down (with the nightly running):

   1. Click "this setup page". Does Windows ask to open T3 Code (Nightly), and does the running window come forward?
   2. In a terminal, run start "" "t3code://app/". Does the running window come forward?
   3. Right-click that setup link, copy it, and share only the scheme, host, and path (delete everything from ? onward, since the query carries the authorization code).

   Likely fix area

   • If step 2 focuses the app but GitHub's link doesn't, the callback URL not exactly matching t3code://app/ would be the first thing to look at, in apps/desktop/src/app/DesktopClerk.ts and how @clerk/electron matches it.
   • If step 2 doesn't focus the app, the protocol registration or second-instance handoff on Windows ARM64 would be the place to look.
   • The session persistence part would follow whatever direction is taken on [Bug]: V2 desktop seeds t3code-v2 Local State from a stale "T3 Code (Alpha)" profile, making connection-catalog.json undecryptable #15001.

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

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

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 4, 2026
3. Reflexoptics01 commented on Oct 4, 2026

   

   Reflexoptics01

   on Oct 4, 2026

   Author

   More actions

   Thanks for the triage! Results on 0.0.46-nightly.20261004.2644, Windows 11 ARM64, with the nightly running:

   1. Clicking "this setup page": Windows did not prompt to open T3 Code (Nightly), the app window did not come forward, and sign-in did not complete.

   2. start "" "t3code://app/": The protocol handler itself works. HKCU\Software\Classes\t3code\shell\open\command is "C:\Users\<user>\AppData\Local\Programs\t3code\T3 Code (Nightly).exe" "%1". Launching the URL spawns a second instance that exits after ~0.3s, so the single-instance handoff fires. The existing window did not come to the foreground when another app had focus, though that may just be Windows' foreground-lock rules.

   3. Setup link (query stripped): https://clerk.t3.codes/v1/oauth_callback

   So the setup link goes to Clerk's FAPI OAuth callback, not directly to t3code://. Since a manual t3code://app/ launch reaches the running app but the GitHub flow never does, it looks like the flow breaks somewhere between GitHub → clerk.t3.codes/v1/oauth_callback → t3code://app/, i.e. either the browser never follows through to Clerk's callback, or Clerk's redirect afterwards never hands off to the t3code:// scheme (or doesn't match t3code://app/ exactly).
4. rustanacexd commented on Oct 7, 2026

   

   rustanacexd

   on Oct 7, 2026 – with ChatGPT Codex Connector

   More actions

   We’re also experiencing T3 Connect GitHub sign-in getting stuck on Windows 11 x64 with T3 Code Nightly 0.0.46-nightly.20261007.2774.

   After completing GitHub authorization in the browser, the desktop app remains stuck loading and still shows “Sign in to T3 Connect.” We tried twice and restarted the app, but sign-in still did not complete.

   The t3code:// protocol handler is registered and points to T3 Code (Nightly).exe. This happened after switching from stable 0.0.45 to nightly.
5. juliusmarminge

   added

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   and removed

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   on Oct 22, 2026