feat(desktop): sign in through the browser, sharing the t3 connect credential - #7483

💭 I'm reviewing the changed web files flagged in prior runs to check whether earlier issues were fixed and whether any new problems have appeared, starting with the cloud auth-related files. Checking T3ConnectSidebarSignIn.tsx against the two prior flagged issues at earlier commits, I confirm both were resolved at the current head — the MenuTrigger now has proper cursor and focus-visible styling, and the DialogPopup has an aria-label. Next I want to verify the new useT3ConnectAuthPrompt.tsx dialog against the UI primitives, so I'll pull up the actual files at head to check. With both prior findings addressed, I want to check whether the MenuTrigger primitive already has cursor/focus styles built in, since if it doesn't, the call-site override is just a workaround rather than fixing the shared contract—I should look at menu.tsx and dialog.tsx to verify. I also want to confirm the Dialog usage properly includes a DialogTitle as Base UI requires, beyond just the aria-label on DialogPopup. I'm checking the useT3ConnectAuthPrompt dialog to see if the input-and-button row pattern needs a flex-1 wrapper so the input properly fills the available space alongside the button. The MenuTrigger custom class matches existing raw-trigger call sites like DiffPanel, LegacySidebar, and PullRequestListFilters, so that's consistent. I'm checking the DialogPopup in T3ConnectSidebarSignIn for the aria-label and default showCloseButton, and verifying the dialog structure in useT3ConnectAuthPrompt follows the standard header/panel/footer pattern with a simple input-and-button row. I'm wondering whether the Input's full-width span could overflow inside the flex row alongside the Button, depending on whether Button has shrink-0 set — I want to check button.tsx and look for similar Input+Button patterns elsewhere in the repo to see if they add flex-1 to the Input, and whether there's an InputGroup primitive meant for this exact case. The button's shrink-0 looks fine layout-wise. I'm not going to nitpick the Enter-key submit pattern since it's not really a UI consistency issue. Checking connectAuth.tsx, it's mostly logic with nothing styling-related to flag. Now I'm looking at DesktopConnectAvatar, which uses a raw span for the avatar circle, so I want to check if there's an existing Avatar primitive in the codebase it should use instead. There's no Avatar primitive, so that's fine. I'm checking the MenuGroupLabel usage—a raw paragraph tag inside a MenuGroup for descriptive text, which seems acceptable since it's non-interactive. The padding on that paragraph matches the MenuGroupLabel's padding, so the styling looks consistent. I'm also verifying the max-w-56 truncate on MenuGroupLabel doesn't affect the popup width, confirming the DesktopConnectAvatar dialog's missing DialogTitle was already flagged, and checking that useT3ConnectAuthPrompt properly includes one. The Input with aria-label looks fine without a Field/Label wrapper, and the DialogFooter's border/background styling is standard. The ConnectOnboardingDialog, ConnectCliAuthSurface, and useCloudLinkController changes are just logic, nothing UI-related to flag. Now I'm looking at whether the error text color in useT3ConnectAuthPrompt should use text-destructive or text-destructive-foreground, comparing against how MenuItem handles destructive variants elsewhere in the codebase. The text-destructive styling matches existing patterns elsewhere, so that's fine. Now I want to check other consumers of useT3ConnectAuthPrompt to see if any rely on the previous return shape of authPrompt. There's only one call site, and the sign-in component returns null both when signed in and when not yet loaded, so the dialog correctly unmounts on success and can't render before loading completes. But wait — are there other consumers that trigger sign-in directly, like ConnectOnboardingDialog or CloudEnvironmentConnectList calling signIn() from useT3ConnectAuth? On desktop, calling signIn() directly would launch the browser without any waiting dialog, which could be a UX gap. I should check where signIn is actually invoked elsewhere. I should check if there are other sign-in entry points on desktop, like the ConnectOnboardingDialog's "Sign in" button or CloudEnvironmentConnectList, so I'll search for other openAuthPrompt usages and "Sign in" buttons across cloud components. I should also check ConnectOnboardingDialog to see if it triggers sign-in itself, since it uses useT3ConnectAuth for state — I want to confirm whether it calls openSignIn from Clerk somewhere, since my grep only turned up references in connectAuth and ConnectCliAuthSurface. Let me check if there's a sign-in surface in Settings > Connections that might still use Clerk directly for desktop, searching for remaining useClerk references in the web app source. I'm checking a UI-consistency issue: on desktop, ClerkSidebarAvatar renders UserButton via useT3ConnectAuth, but since UserButton isn't mounted under ClerkProvider there, I need to verify it's properly gated under the DesktopConnectAuthProvider instead. Next I want to check whether T3ConnectUserProfilePage or MobileClientsUserProfilePage, which were built for Clerk's UserProfile frame, use Clerk-specific hooks like useUser that would throw when rendered inside a dialog on desktop without a ClerkProvider — that would be a real crash regression worth verifying. No Clerk hooks used, that's good. I want to check ClerkUserProfilePage for styling assumptions, since rendering it inside a DialogPanel with its own padding might duplicate spacing or conflict with Clerk's internal scroll container. The missing accessible name was already fixed with an aria-label, but whether the profile page visually fits well inside a Dialog is still worth checking. The pr-8 spacing makes sense to avoid overlapping the close button, and the header's aria-label duplication is fine too. I'm now checking other components like the avatar's background styling and the menu trigger's focus ring states for consistency. The dialog's onOpenChange handler returning a boolean instead of void should be fine under TypeScript's rules, and the missing DialogTitle likely isn't an issue since aria-label covers it. I'm also checking the Enter key handler on the input and whether the flex layout around it needs a flex-1 class, though w-full with shrink behavior should work fine. I'm tracing through the min-width resolution for the flex span wrapping the input — since the inner input has min-w-0, the span's computed min-content size ends up being zero, so it can shrink properly within the flex container. Now I'm checking whether the submitting state shows a loading spinner via the Button component, then comparing styling consistency between the desktop avatar trigger and the sidebar avatar trigger — they match aside from the added transition and focus ring. I'm also considering whether the MenuTrigger needs a larger touch target for coarse pointers, similar to how the Button primitive handles it. Since other raw triggers in the repo don't add this either, and the earlier cursor/ring issue was already fixed, I'll leave this one alone — it's desktop-only and not worth flagging. I'm also confirming that connectAuth.tsx doesn't need UI changes. Now I want to check how the provider nesting looks in main.tsx for the desktop branch, specifically whether DesktopConnectAuthProvider properly wraps ManagedRelayAuthProvider around the app. I'm checking whether any component still renders Clerk UI on desktop outside the gated provider—ConnectCliAuthSurface uses Clerk hooks but only on the web-hosted /connect route, so it shouldn't be reachable from the desktop renderer's navigation. Before this change, desktop mounted its own Clerk provider so this worked fine; now it could crash if that route is somehow reachable, so I want to verify whether the route is registered in the desktop build or guarded by an isElectron check. I should check whether connectCliAuthRoutesEnabled() returns false specifically on Electron. That function likely returns false in Electron, so no crash risk there. I'm checking the desktop menu flow — clicking the menu item closes the menu and opens the dialog, with focus handling seeming fine since they're siblings. I'm now looking at whether the dialog popup in the desktop connect avatar has any accessibility or consistency issues with how it renders profile content. The close button and cancel button setup matches existing repo patterns, and the scroll fade behavior is fine given the short content. What concerns me more is the external link with target="_blank" — in Electron, this typically needs a setWindowOpenHandler in the main process to open externally rather than inside a new Electron window, which would defeat the purpose of browser-based auth this PR is trying to achieve. I want to check whether the desktop app actually handles this case, even though that handler itself would be in an out-of-scope file — the anchor element triggering it is in scope. The desktop app's window-open handler already routes https URLs to the system browser and blocks in-app navigation, so a target="_blank" anchor would work fine. I want to check the codebase for how other external links are handled to stay consistent, likely using rel="noreferrer" alongside target="_blank". The rel="noreferrer" usage matches the existing ThemeSearchSection pattern, so that's fine. I'm also checking the signedOutAuth context defaults and DesktopConnectAuthProvider, which have no UI concerns, and looking at whether getToken is stable across the desktop and web Clerk providers since it's used in a dependency array in ManagedRelayAuthProvider. Tracing through activateManagedRelayAuthentication, the web getToken wraps resolveRelayClerkTokenOptions inside connectAuth as before, so that's preserved correctly. Both prior findings appear to have been addressed in the current head, so I don't see any new UI-consistency issues — I'll report this as all clear.