Reported from a local run: the Create Account tab showed no social option at all.
The mistake
The button was rendered inside the Log In tab's form only, because I followed the passkey button too closely.
A passkey belongs on Log In and nowhere else, correctly: you cannot register an account with one, since registration needs an account to register it against.
Google is the opposite case. Creating an account is precisely what a new customer reaches for it to do. Leaving it off the sign-up tab hid the feature from the people it helps most — and hid it on the tab the modal opens on by default.
What changed
The button now appears on both tabs. The label is the only difference: "Sign up with Google" on Create Account, "Sign in with Google" on Log In.
One endpoint serves both. It signs in a known identity, links a verified address, or creates an account, and the customer neither knows nor cares which will happen — so the wording matches what they came to that tab to do rather than what the server ends up doing. Both spellings are given in Google's identity guidelines alongside the mark.
The consent checkboxes are not carried across
Deliberately. Google takes the customer off this site entirely, and a tick that survived that round trip would be a consent recorded from a form nobody submitted.
They are asked again, with the same wording and through the same endpoints, on the /welcome step they land on afterwards. That is what #342 built it for.
Testing
A new end-to-end test asserts absence on the sign-up tab, like the one beside it, because local and QA have no credentials and absence is the behaviour that actually runs there.
Reported from a local run: the Create Account tab showed no social option at all.
## The mistake
The button was rendered inside the Log In tab's form only, because I followed the passkey button too closely.
A passkey belongs on Log In and nowhere else, correctly: you cannot register an account with one, since registration needs an account to register it against.
**Google is the opposite case.** Creating an account is precisely what a new customer reaches for it to do. Leaving it off the sign-up tab hid the feature from the people it helps most — and hid it on the tab the modal opens on by default.
## What changed
The button now appears on both tabs. The label is the only difference: "Sign up with Google" on Create Account, "Sign in with Google" on Log In.
One endpoint serves both. It signs in a known identity, links a verified address, or creates an account, and the customer neither knows nor cares which will happen — so the wording matches what they came to that tab to do rather than what the server ends up doing. Both spellings are given in Google's identity guidelines alongside the mark.
## The consent checkboxes are not carried across
Deliberately. Google takes the customer off this site entirely, and a tick that survived that round trip would be a consent recorded from a form nobody submitted.
They are asked again, with the same wording and through the same endpoints, on the `/welcome` step they land on afterwards. That is what #342 built it for.
## Testing
A new end-to-end test asserts absence on the sign-up tab, like the one beside it, because local and QA have no credentials and absence is the behaviour that actually runs there.
Frontend `tsc`, lint and build clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The button was rendered inside the Log In tab's form only, so a visitor on Create Account saw no social option at all. Reported from a local run.
The mistake came from following the passkey button too closely. A passkey belongs only on Log In, and correctly so: you cannot register an account with one, since registration requires an account to register it against. Google is the opposite case. Creating an account is precisely what a new customer reaches for it to do, so leaving it off the sign-up tab hid the feature from the people it helps most — and hid it on the tab the modal opens on by default.
The label differs by tab and nothing else does. One endpoint serves both: it signs in a known identity, links a verified address, or creates an account, and the customer neither knows nor cares which will happen. So the wording matches what they came to that tab to do rather than what the server ends up doing. Both spellings are given in Google's identity guidelines alongside the mark.
The two consent checkboxes above it are deliberately not carried across. Google takes the customer off this site entirely, and a tick that survived that round trip would be a consent recorded from a form nobody submitted. They are asked again, with the same wording and through the same endpoints, on the step they land on afterwards — which is what #342 built that step for.
The end-to-end test asserts absence, like the one beside it, because local and QA have no credentials and absence is the behaviour that actually runs there.
Verified: frontend tsc, lint and build clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Reported from a local run: the Create Account tab showed no social option at all.
The mistake
The button was rendered inside the Log In tab's form only, because I followed the passkey button too closely.
A passkey belongs on Log In and nowhere else, correctly: you cannot register an account with one, since registration needs an account to register it against.
Google is the opposite case. Creating an account is precisely what a new customer reaches for it to do. Leaving it off the sign-up tab hid the feature from the people it helps most — and hid it on the tab the modal opens on by default.
What changed
The button now appears on both tabs. The label is the only difference: "Sign up with Google" on Create Account, "Sign in with Google" on Log In.
One endpoint serves both. It signs in a known identity, links a verified address, or creates an account, and the customer neither knows nor cares which will happen — so the wording matches what they came to that tab to do rather than what the server ends up doing. Both spellings are given in Google's identity guidelines alongside the mark.
The consent checkboxes are not carried across
Deliberately. Google takes the customer off this site entirely, and a tick that survived that round trip would be a consent recorded from a form nobody submitted.
They are asked again, with the same wording and through the same endpoints, on the
/welcomestep they land on afterwards. That is what #342 built it for.Testing
A new end-to-end test asserts absence on the sign-up tab, like the one beside it, because local and QA have no credentials and absence is the behaviour that actually runs there.
Frontend
tsc, lint and build clean.🤖 Generated with Claude Code