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

💭 I'm checking which TypeScript, TSX, and CSS files in apps/web/src were changed, focusing on the cloud auth and Clerk sidebar components. Looking back at T3ConnectSidebarSignIn.tsx, both issues I flagged earlier were addressed — the aria-label and focus ring are present. I initially noted a discrepancy with outline-none vs outline-hidden, but since Tailwind v4 renamed these classes (v4's outline-none sets outline-style:none, same effect as before), the author's approach with outline-none plus the focus-visible ring is functionally correct, so no need to re-flag it. Now I'm moving on to review the rest of the changed files I haven't looked at yet.

1. browse_code — apps/web/src/components/clerk/useT3ConnectAuthPrompt.tsx

2. browse_code — apps/web/src/components/clerk/T3ConnectSidebarSignIn.tsx

💭 I'm checking the dialog, menu, input, and button primitives for conventions, then reviewing useT3ConnectAuthPrompt for consistency—things like whether inputs disable properly during submission and whether footer button ordering follows the usual pattern of ghost cancel action next to a primary action.

3. browse_code — apps/web/src/components/ui/dialog.tsx

4. browse_code — apps/web/src/components/ui/input.tsx

💭 I'm checking how the Input span behaves inside a flex row with a Button, since w-full combined with flex gap could affect sizing, and comparing against similar existing call sites to confirm the pattern is consistent. Beyond that, I want to verify the submit button doesn't get disabled state during async submission—minor but worth checking. I should also look at how MenuGroupLabel is paired with description text in the connect sidebar's avatar menu, and review the menu primitive defaults to confirm alignment and structural conventions match other menus in the codebase.

5. browse_code — apps/web/src/components/ui/menu.tsx

6. git_tools — flex gap-2">\n

💭 The menu popup width defaults look fine since the max-width classes sit on children rather than the popup itself. I'm considering whether the sign-out item needs a destructive variant, though it's not required, and now checking what's left to review since the last commit.

7. git_tools — apps/web/src/** 640df82..627b8cb

💭 Since the branch was force-pushed, I need to re-review the current head state of the in-scope files rather than reposting already-fixed findings. Checking connectAuth.tsx, managedAuth.tsx/.test.ts, and useCloudLinkController.ts — these are mostly logic-focused with minimal UI styling concerns. Continuing through the file list: T3ConnectSidebarSignIn.tsx already had its findings fixed, authRedirect logic looks fine, and I need to focus more carefully on useT3ConnectAuthPrompt.tsx since it introduces new dialog UI, plus smaller changes in ConnectCliAuthSurface, ConnectOnboardingDialog's hook swap, and main.tsx's provider swap. For the auth prompt dialog, I'm checking whether the link styling matches conventions used elsewhere in the app, and tracing through how the Input's width behaves as a flex child alongside the Button to make sure there's no overflow or sizing issue. I'm now questioning whether the error text should use text-destructive or text-destructive-foreground, since I recall destructive menu item variants using the foreground token — this could be a real inconsistency worth checking against the theme's CSS tokens and other error-message usages in the codebase.

8. git_tools — text-destructive(-foreground)?\b

9. git_tools — --color-destructive

💭 The text-destructive pattern for error text is used widely, so nothing notable there. I'm checking whether dialogs share a common error component and also looking for an established link styling pattern to see if there's a shared Link/ExternalLink component being reused. Actually, a more important consideration: in Electron, target="_blank" links are usually intercepted via setWindowOpenHandler rather than handled natively. If the app has a dedicated openExternal helper or ExternalLink component, using a raw anchor tag with target="_blank" instead would be a real consistency finding worth checking.

10. git_tools — target="_blank"

11. git_tools — openExternal|ExternalLink|openExternalUrl

💭 That PR comment clarifies that a plain anchor with target="_blank" is fine since the desktop window intercepts blocked blank targets and routes them through openExternal itself, so no finding there. Now I want to compare against how Sidebar.tsx styles its anchor and its rel attribute, since the new anchor uses rel="noreferrer". Checking similar patterns elsewhere isn't a major consistency issue. I'm also looking at the dialog's footer buttons—cancel as ghost, try again as primary—and wondering if other dialogs use a DialogClose wrapper instead of a manual onClick handler, though functionally it works either way. I'm also noting that the error text under the input isn't wired up with aria-describedby or aria-invalid, and the app does have a Field/FieldError primitive that could handle this more accessibly. ThemeEditorPanel uses aria-live, so it's mixed usage elsewhere and not a real inconsistency here. Now I want to check ConnectOnboardingDialog and ConnectCliAuthSurface, which were just hook swaps, and also look at main.tsx to confirm ClerkProvider's appearance prop is still correctly scoped after removing the electron branch.

12. browse_code — apps/web/src/main.tsx

💭 On desktop, this provider only mounts when the Clerk key and cloud config are present, which affects behavior rather than UI. I'm also noting that T3ConnectUserProfilePage and MobileClientsUserProfilePage were built to render inside Clerk's UserProfile page. Now they're rendered inside a DialogPanel on desktop instead, so I should check whether these pages depend on Clerk's own layout classes or scroll behavior, and whether they already have their own heading markup that would make sense without Clerk's header. Let me look at T3ConnectUserProfilePage's root structure to confirm.

13. browse_code — apps/web/src/components/clerk/T3ConnectUserProfilePage.tsx

💭 I should check the ClerkUserProfilePage wrapper to see if it relies on Clerk's own container styling, like cl- selectors or padding that assumes Clerk's modal chrome.

14. git_tools — function ClerkUserProfilePage

15. browse_code — apps/web/src/components/clerk/ClerkUserProfilePage.tsx

💭 I'm checking that the header spacing works fine with the close button placement in both dialogs, and confirming the panel padding is consistent since there's no separate header/footer. Now I'm starting to think through another potential issue with the layout. Sizing on the desktop dialog looks fine with ScrollArea handling overflow, and the Empty component's minimum height seems okay too. Since connectAuth.tsx is mostly provider logic without styling, it's likely out of scope for UI consistency checks. I'm now wondering if the sidebar avatar's initial span should instead use an existing Avatar primitive from the ui components rather than reconstructing it locally, so I want to check if that file exists.

16. browse_code — apps/web/src/components/ui/*.tsx

💭 There's no Avatar primitive, so I'll skip that. I'm checking whether input-group.tsx offers a convention for pairing an input with an adjacent action button, since the code-entry row currently just uses a flex div wrapping Input and Button. Since they're using the actual Input component rather than recreating it, that satisfies the rule. To confirm the button placement pattern is consistent with the rest of the app, I want to check PairingRouteSurface.tsx, which has a similar "paste a code" flow.

17. browse_code — apps/web/src/components/auth/PairingRouteSurface.tsx

💭 I'm noticing the pairing surface uses a proper form submission with disabled states during submit, while the new code-entry relies on a manual Enter keydown handler and doesn't disable the input while submitting—this looks like a potential consistency and accessibility gap worth flagging against the migration guidelines. Though actually, since submitCode returns early during submission, there's no real double-submit risk, just a missing busy indicator, which feels more like an optional aesthetic nit than a concrete violation. Let me check if there's a real layout issue instead—comparing the Input's computed height against the Button's default size to see if they'd visually mismatch in a flex row, so I want to check the Button primitive's sizing.

18. browse_code — apps/web/src/components/ui/button.tsx

💭 Checking the button and input heights, they line up at both default and small sizes, so no CSS changes are needed there. I'm also double-checking whether the sign-out menu item follows the repo's convention for destructive actions. Looking at the MenuGroupLabel with a plain paragraph inside a menu group, I want to verify this pattern against ARIA menu semantics and see if other menus in the codebase place descriptive text alongside menu items in a similar way.

19. git_tools — MenuGroupLabel

💭 The <p> inside MenuGroup matches the ProjectSettingsPanel pattern consistently. I'm noting that unlike ProjectSettingsPanel, which sets an explicit popup width for text wrapping, this popup relies on min-w-32 with max-w-56 on the child text to constrain wrapping instead. I also check that truncate on MenuGroupLabel works fine since max-w-56 gives it the required constrained width, and confirm MenuPopup's layout is consistent. The DesktopConnectAvatar's raw span matches the size-7 avatar used elsewhere, so that's fine too. I don't find new concrete violations in the in-scope files after these checks, but connectAuth.tsx raises a real regression concern: previously authPrompt was always null, so if any consumers of useT3ConnectAuthPrompt ignore the returned prompt, they'd now silently drop the desktop dialog. I need to check all call sites of that hook to see if they actually render authPrompt.

20. git_tools — useT3ConnectAuthPrompt

💭 I'm checking that the single consumer just renders the auth prompt, and confirming the sign-in component safely returns null once signed in, closing the dialog. I'm also noting a subtlety: when the whole component returns null before loading completes, hooks still execute underneath even though nothing renders. Now I want to trace whether ConnectOnboardingDialog has its own sign-in trigger that might call Clerk's openSignIn directly, which would be a problem on desktop if Clerk isn't mounted there — I should check its sign-in CTA next.

21. git_tools — signIn|openSignIn|Sign in

💭 No sign-in CTA there, that's good. Now I'm wondering if other places in apps/web/src still call useClerk().openSignIn or useAuth from @clerk/react — since this PR migrates to useT3ConnectAuth, those components would render without a ClerkProvider on desktop and could throw or silently fail, which seems like a consistency risk worth checking.

22. git_tools — from "@clerk/react"

💭 I'm checking that Clerk usage stays properly scoped to web-only surfaces — the auth provider, sidebar avatar, and the ConnectCliAuthSurface all seem confined to the hosted web app rather than the desktop Electron build. Since ConnectCliAuthSurface uses Clerk hooks unguarded and the diff dropped the isElectron check, I want to make sure this route can't actually be reached from the desktop bundle, since useAuth would throw without a ClerkProvider present there. Let me trace where this component gets rendered and whether it's gated behind an electron check.

23. git_tools — ConnectCliAuth

💭 The /connect routes are gated by isHostedStaticApp(), so they're unreachable on desktop — no crash risk there. Both prior findings appear fixed, and checking the sidebar avatar branching between Electron and web auth providers confirms that's fine too. Verifying that the auth prompt hook works safely even without a provider present, and that the sign-in flow on web still calls the same Clerk sign-in path as before — all consistent. I'm not finding anything new, so per the instructions, since there are no findings, the response should just be "All clear." Weighing whether skipping complete_check risks the run being marked incomplete against the customer's explicit, emphatic instruction to output exactly "All clear" with no tool call — I'll go with following the customer literally and just respond with that plain text.