[Due for payment 2026-04-23] [$250] Expensify Card - Email is not shown on magic code page after switching to copilot account

[vincdargento]

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: v9.3.54-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://github.com/Expensify/Expensify/issues/578307
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team

Action Performed:

Preconditions:

• Admin has issued a physical card to the member.
• Admin adds member as copilot (any access level).
• Perform the following steps as a member:

1. Go to staging.new.expensify.com
2. Go to Account.
3. Open account switcher.
4. Select Admin account.
5. Open account switcher.
6. Select Member account to change it back to the original account.
7. Go to workspace chat.
8. Click Add shipping details.
9. Finish the flow and reach the magic code page.

Expected Result:

Email will be displayed on magic code page.

Actual Result:

Email is not shown on magic code page after switching to copilot account.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022041927880035222546
• Upwork Job ID: 2041927880035222546
• Last Price Increase: 2026-04-08

[MelvinBot]

Proposal

What is the root cause of that problem?

The magic code page (MissingPersonalDetailsMagicCodePage.tsx:37) reads the user's email from account.primaryLogin in Onyx. When switching back from a copilot account via Delegate.disconnect(), this value gets wiped:

1. Delegate.ts:293-295 sets primaryLogin via Onyx.merge(ONYXKEYS.ACCOUNT, {primaryLogin: requesterEmail})
2. Delegate.ts:300 immediately calls Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS) which wipes ONYXKEYS.ACCOUNT — because ONYXKEYS.ACCOUNT is not in the KEYS_TO_PRESERVE_DELEGATE_ACCESS list (Delegate.ts:23-42)
3. Delegate.ts:310 calls openApp() to repopulate data from the server, but this is async — primaryLogin remains empty until the response arrives

Other magic code pages (e.g., NewContactMethodConfirmMagicCodePage.tsx:22, TwoFactorAuth/VerifyPage.tsx:41) are unaffected because they use getContactMethod(account?.primaryLogin, session?.email) from UserUtils.ts:121, which falls back to session.email. The session IS preserved during delegate switching. The shipping details magic code page lacks this fallback.

What changes do you think we should make in order to solve the problem?

In MissingPersonalDetailsMagicCodePage.tsx, add a session.email fallback using the existing getContactMethod utility — the same pattern already used by other magic code pages:

1. Import useOnyx for ONYXKEYS.SESSION and getContactMethod from @libs/UserUtils
2. Replace the bare primaryLogin ?? '' on line 73 with getContactMethod(primaryLogin, session?.email)

The same fix should also be applied to MultifactorAuthentication/ValidateCodePage.tsx:45 which has the same vulnerability (account?.primaryLogin ?? '' with no session fallback).

What alternative solutions did you explore? (Optional)

• Adding ONYXKEYS.ACCOUNT to KEYS_TO_PRESERVE_DELEGATE_ACCESS: This would preserve primaryLogin through the clear, but risks keeping stale delegate account data (permissions, settings) that should be wiped on disconnect. The fallback approach is safer and more targeted.
• Reordering operations in disconnect() so Onyx.clear happens before setting primaryLogin: This wouldn't fully solve the problem since Onyx.clear needs to happen to reset state, and the fundamental issue is that the magic code page needs a resilient way to get the email.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ShridharGoel (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022041927880035222546

[twilight2294]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After switching away from a copilot account and back, the magic code page for Expensify Card verification shows a blank email instead of the user's address.

What is the root cause of that problem?

Delegate.disconnect() in Delegate sets account.primaryLogin via Onyx.merge, then immediately calls Onyx.clear() which wipes ONYXKEYS.ACCOUNT (it's not in KEYS_TO_PRESERVE_DELEGATE_ACCESS). The subsequent openApp() call is async, so primaryLogin stays undefined until the server responds.

ExpensifyCardVerifyAccountPage reads account?.primaryLogin ?? '' with no fallback to session.email. Since ONYXKEYS.SESSION is preserved through the clear, session.email is always available but unused.

What changes do you think we should make in order to solve the problem?

In ExpensifyCardVerifyAccountPage, add session.email as fallback — matching the existing pattern in IssueNewCardConfirmMagicCodePage:

 const [account] = useOnyx(ONYXKEYS.ACCOUNT);
-const primaryLogin = account?.primaryLogin ?? '';
+const [session] = useOnyx(ONYXKEYS.SESSION);
+const primaryLogin = account?.primaryLogin ?? session?.email ?? '';

Apply the same one-line fallback to other card-related pages with the identical vulnerability:

• ReportCardLostConfirmMagicCodePage
• ReportVirtualCardFraudVerifyAccountPage
• TravelCVVVerifyAccountPage

What alternative solutions did you explore? (Optional)

MelvinBot's proposal fixes MissingPersonalDetailsMagicCodePage.tsx and MultifactorAuthentication/ValidateCodePage.tsx, but the issue title and reproduction steps specifically involve the Expensify Card flow — the directly affected page is ExpensifyCardVerifyAccountPage.tsx, which MelvinBot's proposal doesn't touch. This proposal targets the actual page shown in the bug report and the other card-related pages sharing the same vulnerability, using the simpler inline fallback (?? session?.email) already established in IssueNewCardConfirmMagicCodePage.tsx rather than pulling in a separate utility function.

[ReaperOAK]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After switching to a copilot (delegate) account and back to the original member account, the magic code page that appears at the end of the "Add shipping details" flow for an Expensify Card displays a blank email instead of the user's address.

What is the root cause of that problem?

The "Add shipping details" button in src/components/ReportActionItem/IssueCardMessage.tsx navigates to the MissingPersonalDetails flow. After completing the form, the user reaches src/pages/MissingPersonalDetails/MissingPersonalDetailsMagicCodePage.tsx, which reads the email via useOnyx(ONYXKEYS.ACCOUNT, {selector: primaryLoginSelector}) (line 37) and renders it on line 73:

descriptionPrimary={translate('cardPage.enterMagicCode', primaryLogin ?? '')}

When the user disconnects from a copilot account via Delegate.disconnect() in src/libs/actions/Delegate.ts, the following sequence occurs:

1. Line 293–296: Onyx.merge(ONYXKEYS.ACCOUNT, {primaryLogin: requesterEmail}) sets primaryLogin.
2. Line 300: Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS) wipes ONYXKEYS.ACCOUNT entirely — because ONYXKEYS.ACCOUNT is not in the KEYS_TO_PRESERVE_DELEGATE_ACCESS list (lines 23–42). This destroys the primaryLogin just set in step 1.
3. Line 306: openApp() fetches fresh data from the server, but this is asynchronous — account.primaryLogin remains undefined until the response arrives.

Crucially, ONYXKEYS.SESSION is preserved through the clear (line 28), so session.email is always available. The page simply never reads it.

What changes do you think we should make in order to solve the problem?

The codebase already has a purpose-built hook for exactly this scenario: src/hooks/usePrimaryContactMethod.ts. It reads account.primaryLogin with an automatic fallback to session.email:

function usePrimaryContactMethod(): string {
    const [account] = useOnyx(ONYXKEYS.ACCOUNT);
    const [sessionEmail] = useOnyx(ONYXKEYS.SESSION, {selector: emailSelector});
    return account?.primaryLogin ?? sessionEmail ?? '';
}

This hook is already used by WorkspaceVerifyWorkAccountPage, WorkspaceCompanyCardAddWorkEmailPage, and WorkspaceCompanyCardFeedSelectorPage, and has its own unit tests at tests/unit/hooks/usePrimaryContactMethod.test.ts.

Primary fix — in src/pages/MissingPersonalDetails/MissingPersonalDetailsMagicCodePage.tsx:

1. Import usePrimaryContactMethod from @hooks/usePrimaryContactMethod.
2. Replace the current Onyx selector:

- import {primaryLoginSelector} from '@src/selectors/Account';
  ...
- const [primaryLogin] = useOnyx(ONYXKEYS.ACCOUNT, {selector: primaryLoginSelector});
+ const primaryLogin = usePrimaryContactMethod();

3. On line 73, the existing primaryLogin ?? '' becomes redundant (the hook already returns '' as final fallback), but is harmless to keep for safety.

Same fix for other vulnerable magic code pages that use account?.primaryLogin ?? '' without a session fallback:

• src/pages/settings/Wallet/ExpensifyCardPage/ExpensifyCardVerifyAccountPage.tsx (line 28)
• src/pages/settings/Wallet/ReportCardLostConfirmMagicCodePage.tsx (line 32)
• src/pages/settings/Wallet/ReportVirtualCardFraudVerifyAccountPage.tsx (line 34)
• src/pages/settings/Wallet/TravelCVVPage/TravelCVVVerifyAccountPage.tsx (line 27)
• src/pages/MultifactorAuthentication/ValidateCodePage.tsx (line 45)

In each file, replace the manual useOnyx(ONYXKEYS.ACCOUNT) + account?.primaryLogin ?? '' with usePrimaryContactMethod().

What alternative solutions did you explore? (Optional)

1. MelvinBot's approach — getContactMethod() utility: Uses getContactMethod(account?.primaryLogin, session?.email) from UserUtils.ts. This works but requires each page to separately subscribe to both ONYXKEYS.ACCOUNT and ONYXKEYS.SESSION, duplicating boilerplate. The usePrimaryContactMethod hook encapsulates this pattern in a single call and is already an established pattern with unit tests.

2. twilight2294's approach — inline ?? session?.email fallback: Correctly identifies the card-related pages as vulnerable, but targets ExpensifyCardVerifyAccountPage.tsx as the primary fix — which is the "Reveal card details" page, not the "Add shipping details" magic code page shown in the reproduction steps. The directly affected page per the repro is MissingPersonalDetailsMagicCodePage.tsx. Additionally, scattering inline ?? session?.email fallbacks across files is less maintainable than using the centralized hook.

3. Adding ONYXKEYS.ACCOUNT to KEYS_TO_PRESERVE_DELEGATE_ACCESS: Would preserve primaryLogin through the clear, but risks retaining stale delegate account data (permissions, delegatedAccess fields) that should be wiped on disconnect. The fallback approach is safer and more targeted.

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After a user opens another account via the account switcher (copilot) and then switches back to their own account, the Expensify Card shipping-details magic code page shows an empty email in the "We've sent a magic code to …" description instead of the user's email address.

What is the root cause of that problem?

The disconnect flow in Delegate.ts wipes account.primaryLogin immediately after setting it, so any screen that reads account.primaryLogin shortly after the switch sees an empty value until the async openApp() response arrives.

Current ordering inside disconnect:

App/src/libs/actions/Delegate.ts

Lines 283 to 310 in 7199fc2

	return SequentialQueue.waitForIdle()
	.then(() => {
	return Promise.all([
	Onyx.set(ONYXKEYS.SESSION, {
	...stashedSession,
	accountID: response.requesterID,
	email: requesterEmail,
	authToken,
	encryptedAuthToken: response.encryptedAuthToken,
	}),
	Onyx.merge(ONYXKEYS.ACCOUNT, {
	primaryLogin: requesterEmail,
	}),
	]);
	})
	.then(() => {
	NetworkStore.setAuthToken(response?.authToken ?? null);
	return Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS);
	})
	.then(() => {
	Onyx.set(ONYXKEYS.CREDENTIALS, {
	...stashedCredentials,
	accountID: response.requesterID,
	});
	Onyx.set(ONYXKEYS.STASHED_CREDENTIALS, {});
	Onyx.set(ONYXKEYS.STASHED_SESSION, {});
	confirmReadyToOpenApp();
	openApp().then(() => {

The promise chain does, in order:

1. Onyx.set(ONYXKEYS.SESSION, { …, email: requesterEmail, authToken, … }) — preserved by the clear
2. Onyx.merge(ONYXKEYS.ACCOUNT, { primaryLogin: requesterEmail }) — not preserved by the clear
3. Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS) — wipes ONYXKEYS.ACCOUNT entirely, because it is not in the preserved list

KEYS_TO_PRESERVE_DELEGATE_ACCESS does not include ONYXKEYS.ACCOUNT:

App/src/libs/actions/Delegate.ts

Lines 23 to 42 in 7199fc2

	const KEYS_TO_PRESERVE_DELEGATE_ACCESS = [
	ONYXKEYS.NVP_TRY_FOCUS_MODE,
	ONYXKEYS.PREFERRED_THEME,
	ONYXKEYS.NVP_PREFERRED_LOCALE,
	ONYXKEYS.ARE_TRANSLATIONS_LOADING,
	ONYXKEYS.SESSION,
	ONYXKEYS.STASHED_SESSION,
	ONYXKEYS.HAS_LOADED_APP,
	ONYXKEYS.STASHED_CREDENTIALS,
	ONYXKEYS.HYBRID_APP,
	// We need to preserve the sidebar loaded state since we never unmount the sidebar when connecting as a delegate
	// This allows the report screen to load correctly when the delegate token expires and the delegate is returned to their original account.
	ONYXKEYS.IS_SIDEBAR_LOADED,
	ONYXKEYS.NETWORK,
	ONYXKEYS.SHOULD_USE_STAGING_SERVER,
	ONYXKEYS.IS_DEBUG_MODE_ENABLED,
	ONYXKEYS.COLLECTION.PASSKEY_CREDENTIALS,
	ONYXKEYS.COLLECTION.DEVICE_BIOMETRICS,
	];

So the primaryLogin merge in step 2 is always wiped by the clear in step 3. The only thing that repopulates it is the async openApp() response at step 310, which usually arrives after the magic code screen has already mounted.

ONYXKEYS.SESSION is in the preserved list, which is why session.email remains correct throughout the switch — but the "Add shipping details" magic code page (MissingPersonalDetailsMagicCodePage.tsx:73) reads only from account.primaryLogin via primaryLoginSelector and has no session.email fallback, so it renders blank.

App/src/pages/MissingPersonalDetails/MissingPersonalDetailsMagicCodePage.tsx

Lines 37 to 73 in 7199fc2

	const [primaryLogin] = useOnyx(ONYXKEYS.ACCOUNT, {selector: primaryLoginSelector});
	const [validateCodeAction] = useOnyx(ONYXKEYS.VALIDATE_ACTION_CODE);
	const privateDetailsErrors = privatePersonalDetails?.errors ?? undefined;
	const validateLoginError = getLatestError(privateDetailsErrors);
	const missingDetails = arePersonalDetailsMissing(privatePersonalDetails);
	useEffect(() => {
	if (missingDetails || !!privateDetailsErrors || !areAllCardsShipped) {
	return;
	}
	clearDraftValues(ONYXKEYS.FORMS.PERSONAL_DETAILS_FORM);
	Navigation.dismissModal();
	}, [missingDetails, privateDetailsErrors, areAllCardsShipped]);
	const clearError = () => {
	if (isEmptyObject(validateLoginError) && isEmptyObject(validateCodeAction?.errorFields)) {
	return;
	}
	clearPersonalDetailsErrors();
	};
	const values = useMemo(() => normalizeCountryCode(getSubPageValues(privatePersonalDetails, draftValues)) as PersonalDetailsForm, [privatePersonalDetails, draftValues]);
	const handleSubmitForm = useCallback(
	(validateCode: string) => {
	updatePersonalDetailsAndShipExpensifyCards(values, validateCode, countryCode);
	},
	[countryCode, values],
	);
	return (
	<ValidateCodeActionContent
	title={translate('cardPage.validateCardTitle')}
	descriptionPrimary={translate('cardPage.enterMagicCode', primaryLogin ?? '')}

This is a regression. Before commit c6e22c33d740 ("Fix auth token issues after switching account and handle missing isLoadingApp") both Onyx.set(SESSION) and Onyx.merge(ACCOUNT, { primaryLogin }) ran in the .then after Onyx.clear. That commit moved both of them before the clear to fix an auth-token issue. Moving Onyx.set(SESSION) before the clear is fine (SESSION is preserved). Moving the primaryLogin merge before the clear is the bug — it places a write to ACCOUNT in a slot where ACCOUNT is about to be wiped.

What changes do you think we should make in order to solve the problem?

Move only the primaryLogin merge back to after Onyx.clear, keeping the Onyx.set(SESSION) call where it is (since that fix is still needed for auth-token handling).

Concretely, in the disconnect chain in src/libs/actions/Delegate.ts:

1. In the first .then() (the Promise.all), drop the Onyx.merge(ONYXKEYS.ACCOUNT, { primaryLogin: requesterEmail }) entry. Keep only the Onyx.set(ONYXKEYS.SESSION, …) call — which is the one that actually needs to run before the clear for auth-token reasons.
2. In the .then() that runs after Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS) (the same block that already re-sets CREDENTIALS, STASHED_CREDENTIALS, STASHED_SESSION and calls openApp()), add the Onyx.merge(ONYXKEYS.ACCOUNT, { primaryLogin: requesterEmail }) call. This is exactly where it lived before the regression commit.

With this change, account.primaryLogin is populated synchronously right after the clear — before any magic code screen can mount — so every consumer that reads account.primaryLogin (including MissingPersonalDetailsMagicCodePage, ExpensifyCardVerifyAccountPage, ReportCardLostConfirmMagicCodePage, ReportVirtualCardFraudVerifyAccountPage, TravelCVVVerifyAccountPage, MultifactorAuthentication/ValidateCodePage, VerifyAccountPageBase, and any others) sees the correct email immediately after the switch.

This is a one-place root-cause fix in the delegate disconnect flow, so no per-page patches are needed — all current and future screens that read account.primaryLogin after a copilot-to-member switch are fixed at once.

What alternative solutions did you explore? (Optional)

• Add ONYXKEYS.ACCOUNT to KEYS_TO_PRESERVE_DELEGATE_ACCESS. This would preserve primaryLogin through the clear, but it would also preserve every other field on ACCOUNT (such as delegatedAccess, validation state, 2FA state, errors, etc.) from the previous delegate account. That defeats the purpose of the clear and risks leaking delegate-account state into the member account. Rejected as too broad.

• Re-Onyx.merge on the ACCOUNT key inside the openApp onyxData reducer. The server response does repopulate primaryLogin eventually, but it is async and the magic code screen can mount in between. That leaves a visible blank-email window, which is the exact bug being reported. Rejected because it doesn't actually solve the race.

---

Compare: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/87408-delegate-preserve-primary-login?expand=1

[github-actions]

⚠️ @wildan-m Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[wildan-m]

@ProposalPolice this is a false positive. My proposal and the linked one share a root-cause description, but the fixes are in different files and use different mechanisms:

• The linked proposal patches ~6 individual magic code pages (MissingPersonalDetailsMagicCodePage, ExpensifyCardVerifyAccountPage, ReportCardLostConfirmMagicCodePage, ReportVirtualCardFraudVerifyAccountPage, TravelCVVVerifyAccountPage, MultifactorAuthentication/ValidateCodePage) to add a session.email fallback via usePrimaryContactMethod.
• My proposal touches only src/libs/actions/Delegate.ts and reorders the disconnect promise chain so that Onyx.merge(ONYXKEYS.ACCOUNT, { primaryLogin }) runs after Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS) instead of before it. This is a direct revert of the reordering introduced in commit c6e22c33d740 that caused the regression.

The per-page fallback approach only fixes the specific pages that get patched — every other account.primaryLogin consumer (e.g. WorkspaceWorkflowsPage, ReimbursementAccount/NonUSD/BusinessInfo/subSteps/ContactInformation, ReferralDetailsPage, Travel/TravelTerms, signin/UnlinkLoginForm, etc.) remains susceptible to the same "blank primaryLogin immediately after copilot→member switch" race. The root-cause fix repairs all of them in one place without touching any consumer, and without broadening KEYS_TO_PRESERVE_DELEGATE_ACCESS (which would leak delegate account state).

Restoring the original proposal.