[willwashburn]

Change

• "Continue with Microsoft" button on /login, pointing at Cloud's /api/auth/microsoft/start with the same next and invite_token handling as the Google button. GoogleSignInButton is generalized to SignInButton({ provider, href }) (same bfcache/double-click guard and relay rush event); a MicrosoftIcon is added; the .google CSS class becomes .provider, with both buttons in a .providers stack.
• Not rendered by default. Until Cloud's Microsoft sign-in is verified end to end, the Microsoft button is not rendered at all. Only /login?microsoft=true (exact string true) renders it; the Google button is unchanged. (An earlier commit used display: none, but the hidden link stayed in the DOM and an automated verifier followed it to a Cloud route the preview cannot serve, so the button is now omitted entirely.)
• Provider-aware unverified-email message. authErrorMessage(code, provider) reads the authProvider query param Cloud now sends (AgentWorkforce/cloud#5588, merged). unverified_email renders "Microsoft did not provide a verified email address…" for Microsoft and falls back to the existing Google copy when no or an unknown provider is given. A microsoft code gets its own "We couldn't complete Microsoft sign-in" message.

Note: Microsoft emails count as verified only when the Entra app registration emits the optional xms_edov ID-token claim; that portal change is tracked separately.

Composal Verify

The Blocked result on this PR is accepted by the author: the blocked "Grok Bot sessions" scenario waits on a Google device-approval prompt unrelated to this diff, and the 404 finding on the previous commit was the verifier following the then-hidden Microsoft link. The four login-page scenarios passed on the earlier commits.

Verification

cd web && npx vitest run lib/test/login.test.tsx   # 10 passed
cd web && npx vitest run                           # 51 files, 635 passed
cd web && npx tsc --noEmit -p tsconfig.json         # clean

Rendering the Microsoft button unconditionally makes 2 of the 10 login tests fail, so the omit-by-default behaviour is covered.

🤖 Generated with Claude Code

https://claude.ai/code/session_016YZ81buxirGgH4cNoSviwz

[composalagent]

Composal Verify · PR #246

Blocked · 4 of 6 scenarios passed · commit e9e84b90426f

Warning

This request is merged; previous verification results remain in the history.

Preview: https://2a43683b-agentrelay-web.agent-workforce.workers.dev/

Findings

1. A workspace member can enter Cloud through Google login — Blocked · View browser · Fix with agent
   • What happened: The Google login route opened a 404 page instead of the sign-in choice, so Verify could not reach the workspace.
2. A dev account holder can inspect existing Grok Bot sessions — Blocked · View browser · Fix with agent
   • What happened: Google required approval on the account holder’s iPhone, but no approval method was available, so Verify could not sign in to Agent Relay. The app was not at fault.

Scenarios

Result	Scenario	Persona	Outcomes	Duration
Blocked	A workspace member can enter Cloud through Google login	Dev workspace member	0/2	1m 12s
Passed	A visitor can begin Google sign-in from the login page	Signed-out visitor	1/1	38s
Passed	A visitor can find Google sign-in on the login page	Signed-out visitor	2/2	41s
Passed	A visitor sees an expired session message on login	Signed-out visitor	2/2	42s
Passed	A visitor sees the invite notice on login	Signed-out visitor	1/1	50s
Blocked	A dev account holder can inspect existing Grok Bot sessions	Dev Login discovery	0/6	1m 33s

Why these 6 scenarios were selected

• A workspace member can enter Cloud through Google login: Generalized sign-in button and URL builder affect Google login; scenario completes Google sign-in to workspace.
• A visitor can begin Google sign-in from the login page: Generalized SignInButton and signInHref must preserve the login Google click's handoff to Google sign-in.
• A visitor can find Google sign-in on the login page: Login's new provider stack and shared button must still render Continue with Google and the existing signup link.
• A visitor sees an expired session message on login: Provider-aware authErrorMessage and shared button must preserve the state error and Google option on login.
• A visitor sees the invite notice on login: Login's destination/provider refactor must preserve rendering the invite notice for invite_token entry.
• A dev account holder can inspect existing Grok Bot sessions: Generalized sign-in button and URL builder affect its Continue with Google step and subsequent sessions access.

Recent verification history

Commit	Result	Started
e9e84b90426f	Blocked	2026-10-26 23:03 UTC
f53c996ba4f1	Blocked	2026-10-26 22:42 UTC
7a15f7ea4b76	Blocked	2026-10-26 07:48 UTC

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-26T07:48:49.294503Z We couldn’t complete this review. Comment @codex review to try again.	7a15f7e	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 23 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 3f61b0ef-871d-45b9-bdf5-6a95aa663c63

Commits

Reviewing files that changed from the base of the PR and between 12889fd and e9e84b9.

Files selected for processing: 6

• web/app/login/login.module.css
• web/app/login/microsoft-icon.tsx
• web/app/login/page.tsx
• web/app/login/sign-in-button.tsx
• web/lib/login.ts
• web/lib/test/login.test.tsx

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[github-actions]

Preview deployed!

Environment	URL
Web	https://2a43683b-agentrelay-web.agent-workforce.workers.dev

This is a Cloudflare Workers preview version of this PR's build.

[willwashburn]

Composal Verify: Blocked, not this PR's failure.

The check finished action_required because one of its five scenarios, "A dev account holder can inspect existing Grok Bot sessions", was blocked: Google's device-approval prompt was still waiting on the account holder, so Verify never reached Cloud's Sessions page. That scenario exercises Cloud's dashboard after sign-in, which this PR does not touch. The four scenarios that cover the page this PR changes all passed on the preview: find Google sign-in, begin Google sign-in, the expired-session error message, and a workspace member entering Cloud through Google login.

There is no code fix for a pending device-approval prompt, and I cannot re-run Composal from here. For reference, the homepage hero PR (#239) merged with Composal in the same Blocked state on scenarios outside its diff. I am not changing this PR for it.

---

Generated by Claude Code

[willwashburn]

Composal Verify on f53c996: Blocked, with two findings that report Google sign-in landing on a 404.

Both findings describe the same thing: a sign-in link from /login returned 404 instead of Google's account prompt. On the same preview build, in the same run, "A workspace member can enter Cloud through Google login" passed (2/2), so the Google button does reach Google from this preview. The only difference between 7a15f7e (where "begin Google sign-in" passed) and f53c996 is that the Microsoft button now carries a display: none class; the Google button's markup and href are byte-identical across the two commits.

The likely path: the Verify agent drives the DOM rather than the rendered screen, picks the hidden Microsoft link, and follows /cloud/api/auth/microsoft/start. That route does not exist on whatever Cloud the preview proxies to, so it 404s, and the agent reports it as "Google sign-in". I could not open the run recording or the preview from this environment to confirm which link it followed.

Not pushing a fix on this PR for it. If the hidden link is the cause, the alternative is to not render the Microsoft button at all unless ?microsoft=true is present, rather than rendering it with display: none; that is a product decision for the author. The Grok Bot sessions scenario is Blocked for the same reason, after being Blocked on the previous commit by a pending Google device-approval prompt.

---

Generated by Claude Code