Login - User is asked to go back to original session to enter 2FA after clicking sign in here

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.9-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90488
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Other

Action Performed:

1. Go to staging.new.expensify.com
2. Enter email of existing account that has 2FA enabled.
3. Go to email.
4. Copy Open Expensify link.
5. Add staging to the link and navigate to it on another browser (incognito mode).
6. Click just sign in here.

Expected Result:

App will redirect to 2FA entry page so user can enter 2FA code.

Actual Result:

App asks user to go back to the original browser to enter 2FA code.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7182806_1781643054362.4.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7182806

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/6cfd3c4da55cb8f433466c4a1f58a41a283084f9d3841dab4f16dab08934ef0b

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #90488

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Issue Analysis

Root Cause: The separate-browser magic-link sign-in feature added in #90488 deliberately has no 2FA entry UI. When a 2FA-enabled user opens the magic link in a different browser (so there's no cached credentials.login) and clicks "just sign in here", ValidateLoginPage/index.web.tsx:127 renders a static JustSignedInModal — text + animation only, no code input field — instead of the real 2FA form. The inline comment at lines 50‑53 confirms this is intentional: "Excludes 2FA: it can't complete from here, so the 2FA modal (below) handles it…". So the user has nowhere to type their code and is stuck.

Recommended Fix: Render the existing 2FA entry form (BaseValidateCodeForm 2FA branch, line 318) in the separate-session path instead of the informational JustSignedInModal, and remove the !is2FARequired exclusion from the direct-sign-in logic. The 2FA form only depends on account.requiresTwoFactorAuth && credentials.validateCode — not on credentials.login — so it can render in the separate browser as long as credentials.validateCode is populated.

One thing to verify before implementing: submitting the 2FA code calls signInWithValidateCode(...) which reads credentials.validateCode from Onyx. That value is merged only on the successData path (lines 942‑948), not on failureData. If SignInUserWithLink returns the 2FA-required response down the failure pipeline (autoAuthState: FAILED), credentials.validateCode will be missing and the 2FA submission will fail. Confirm via logs whether the 2FA-required response lands on JUST_SIGNED_IN (success) or FAILED, and if the latter, also persist validateCode so the code can be submitted.

Investigation details & alternatives considered

• Symptom → mechanism: The modal text shown is validateCodeModal.tfaRequiredDescription = "Please enter the two-factor authentication code where you're trying to sign in." This is purely informational; the component has no TextInput. That matches the reporter's "App asks user to go back… to enter 2FA code."
• Same-browser flow works because SignInPage/BaseValidateCodeForm mounts the 2FA form when requiresTwoFactorAuth && credentials.validateCode are set; credentials.login is not required (SignInPage.tsx:119-127, :241).
• Alternative explanation considered: that 2FA "fundamentally can't complete" in a separate session. Ruled out — the 2FA form's only hard dependency is credentials.validateCode, which the initial signInWithValidateCode call merges on success. The genuine open risk is solely whether the backend's 2FA-required response uses the success vs failure path (the validateCode-persistence gap noted above).
• Scope match: This affects every 2FA-enabled user using the separate-browser sign-in link — consistent with a deploy blocker on a brand-new feature, not an edge case.

Confidence: Medium-High. Root cause is confirmed by code; the only unverified link is which Onyx autoAuthState the 2FA-required backend response triggers, which determines whether the fix is a pure UI swap or also needs validateCode persistence.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93753) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.