[$250] Copilot - Add delegate confirm page shows @expensify.sms domain for phone number

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.43-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @bernhardoj
Slack conversation (hyperlinked to channel name): #expensify_bugs

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Open Account > Copilot > Add a copilot
3. Select a phone number user without a display name
4. Proceed to the confirm page

Expected Result:

The copilot display name doesn't have @expensify.sms domain

Actual Result:

The copilot display name has @expensify.sms domain

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.3883.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080368632110332077
• Upwork Job ID: 2080368632110332077
• Last Price Increase: 2026-07-23

Issue Owner

Current Issue Owner: @MobileMage

[MelvinBot]

Proposal

What is the root cause of that problem?

The confirm page renders the copilot's name straight from personalDetails.displayName without stripping the SMS domain:

const displayName = personalDetails?.displayName ?? formattedLogin;

ConfirmDelegatePage.tsx:40

For a phone-number user who never set a display name, the backend defaults displayName to the raw login (e.g. +15551234567@expensify.sms). Because that value is not nullish, the ?? formattedLogin fallback never fires, so the raw @expensify.sms login is shown as the title (line 72). Note the description (line 73) uses formatPhoneNumber(login), which does strip the domain — that's why the number under the name looks correct while the name itself doesn't.

The selector list one step earlier looks fine because it renders option.text (already cleaned when the option is built), not the raw displayName.

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

Run the name through a helper that strips the SMS domain when displayName === login, instead of using personalDetails.displayName directly at ConfirmDelegatePage.tsx:40.

The existing getDisplayNameOrDefault already does exactly this — it calls Str.removeSMSDomain(displayName) when the stored display name equals the login. Passing login on the details object so that check fires resolves the bug centrally.

What alternative solutions did you explore? (Optional)

Alternatives & supporting detail

• Guard inline: if personalDetails.displayName === login, use the already-formatted formattedLogin, otherwise formatPhoneNumber(personalDetails.displayName). formatPhoneNumber safely no-ops on non-phone strings (LocalePhoneNumber.ts:28-40).
• getEffectiveDisplayName(formatPhoneNumber, personalDetails) (PersonalDetailsUtils.ts) is another one-line option that strips the domain.

Prefer the centralized getDisplayNameOrDefault path over a bespoke inline guard so the confirm page matches how the rest of the app derives names.

Confidence: High — code path traced end to end; only unverified assumption is that the backend stores displayName === login for un-named phone users, which is documented in the comment at PersonalDetailsUtils.ts:80-81.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/blob/ea855a7b40be392de05663edbddc7fee72eb996f/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx#L40) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

In Account > Copilot > Add a copilot, when we select a phone-number user who has no display name and proceed to the confirm page, the copilot's name renders as the raw SMS login (e.g. +15551234567@expensify.sms) instead of the formatted phone number. The same user's name displays correctly (formatted, no domain) on the previous selection step.

What is the root cause of that problem?

ConfirmDelegatePage builds the row title from the personal details record without ever formatting it:

App/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx

Lines 39 to 40 in a4b6ddf

	const formattedLogin = formatPhoneNumber(login ?? '');
	const displayName = personalDetails?.displayName ?? formattedLogin;

const formattedLogin = formatPhoneNumber(login ?? '');
const displayName = personalDetails?.displayName ?? formattedLogin;

For an account that has never set a name, the backend sets displayName equal to the login itself — for SMS accounts that is the full +15551234567@expensify.sms string. This is documented behavior in getDisplayNameOrDefault in src/libs/PersonalDetailsUtils.ts, which exists precisely to strip it:

App/src/libs/PersonalDetailsUtils.ts

Lines 80 to 85 in a4b6ddf

	// If the displayName is not set by the user, the backend sets the displayName same as the login so
	// we need to remove the sms domain from the displayName if it is an sms login.
	if (Str.isSMSLogin(login)) {
	if (displayName === login) {
	displayName = Str.removeSMSDomain(displayName);
	}

Because personalDetails?.displayName is truthy (it holds the raw SMS login), the ?? formattedLogin fallback on line 40 never fires, and the raw value flows straight into the MenuItem title prop on line 72. Only the description on line 73 goes through formatPhoneNumber (src/libs/LocalePhoneNumber.ts lines 32–49), which is the function that calls Str.removeSMSDomain and pretty-prints the number — so the description shows a clean phone number while the title shows the SMS domain. The previous step (AddDelegatePage) is unaffected because its option labels are produced by OptionsListUtils, which wraps names in formatPhoneNumberPhoneUtils(temporaryGetDisplayNameOrDefault(...)) (src/libs/OptionsListUtils/index.ts line 356) — which is why the name looks correct in the picker and then "gains" the domain on the confirm page.

The same unformatted-displayName pattern exists in the Copilot list on src/pages/settings/Copilot/CopilotPage.tsx: const titleText = personalDetail?.displayName ?? formattedEmail; at line 233 (delegates) and line 283 (delegators), plus the delegatorName used in the remove-access prompt at line 95 and the sortKey at lines 205/271 — so after the copilot is added, the list row title shows the same raw @expensify.sms string for a name-less SMS user. SelectDelegateRolePage and UpdateDelegateRolePage never render the delegate's name, and the magic-code pages only show the current user's own primaryLogin, so those are not affected by this bug.

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

In ConfirmDelegatePage.tsx, wrap the whole expression in formatPhoneNumber (already destructured from useLocalize() on line 30, so no new imports), changing line 40 from const displayName = personalDetails?.displayName ?? formattedLogin; to:

const displayName = formatPhoneNumber(personalDetails?.displayName ?? login ?? '');

This is safe for every case: formatPhoneNumber early-returns any string that contains neither the SMS domain nor only digits/plus (line 29 of LocalePhoneNumber.ts), so real display names like "John Smith" pass through untouched; for a name-less SMS user it strips the domain and locale-formats the number, making the title consistent with the description right below it. This is the exact established pattern used for the same problem elsewhere in the repo, e.g. AccountSwitcher:

App/src/components/AccountSwitcher.tsx

Line 148 in a4b6ddf

text: formatPhoneNumber(personalDetails?.displayName ?? personalDetails?.login ?? ''),

Note that after the fix, a name-less SMS user shows the formatted phone number as both title and description — which matches the page's existing behavior for name-less email users (title and description are both the email), so no special-casing is needed. In the same PR we should apply the same one-line wrap to the four CopilotPage.tsx spots called out above (formatPhoneNumber(personalDetail?.displayName ?? email) for the titles/sort keys and formatPhoneNumber(delegatorEmail)-based delegatorName), since it is the same flow and the same regression surface; there the descriptionText can optionally be suppressed when it equals the title (titleText === formattedEmail ? '' : formattedEmail) to avoid showing the identical string twice. For QA: as a validated user, go to Account > Copilot > Add a copilot, search and select a phone number belonging to an account with no display name, pick a role, and verify the confirm page title shows the locale-formatted number with no @expensify.sms; complete the add and verify the Copilot list row title as well; regression-check an email user (with and without a display name) and an SMS user with a real display name to confirm their names are unchanged.

What alternative solutions did you explore? (Optional)

We considered getDisplayNameOrDefault(personalDetails, formattedLogin), which strips the SMS domain when displayName mirrors the login, but it only removes the domain without locale-formatting, so the title would show raw E.164 (+15551234567) while the description shows the locale-formatted number — inconsistent within the same row. Wrapping with formatPhoneNumber gives both the strip and the formatting and matches the existing AccountSwitcher convention.

[ahmdshrif]

Proposal

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

On the Add Copilot confirm page, selecting a phone-number user who has no display name shows the copilot's name as the raw SMS login (e.g. +15551234567@Expensify.sms) instead of the formatted phone number.

What is the root cause of that problem?

1. For phone-number accounts with no user-set name, the backend stamps personalDetails.displayName with the raw login including the ``@expensify.sms domain. This convention is documented in the codebase itself, inside `getDisplayNameOrDefault`:

   App/src/libs/PersonalDetailsUtils.ts

   Lines 80 to 86 in a4b6ddf

   	// If the displayName is not set by the user, the backend sets the displayName same as the login so
   	// we need to remove the sms domain from the displayName if it is an sms login.
   	if (Str.isSMSLogin(login)) {
   	if (displayName === login) {
   	displayName = Str.removeSMSDomain(displayName);
   	}
   	login = Str.removeSMSDomain(login);

2. ConfirmDelegatePage reads that field raw:

   App/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx

   Lines 39 to 40 in a4b6ddf

   	const formattedLogin = formatPhoneNumber(login ?? '');
   	const displayName = personalDetails?.displayName ?? formattedLogin;

   
   Because displayName is populated (with the login) rather than undefined, the ?? formattedLogin fallback never fires, and the raw +15551234567@Expensify.sms string is rendered as the MenuItem title:

   App/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx

   Lines 72 to 73 in a4b6ddf

   	title={displayName}
   	description={formattedLogin}

3. formatPhoneNumber — which strips the SMS domain and locale-formats the number — is applied only to the description line (L39/L73). That is exactly what the repro shows: the small description under the name is formatted correctly while the title keeps the domain.

Structural cause: the SMS-login convention means any consumer that reads personalDetails.displayName without passing it through formatPhoneNumber (or getDisplayNameOrDefault) will leak the ``@expensify.sms domain. This is the same bug class as `#86308` ("Copilot - Account switcher shows `@expensify`.sms when account is phone number"), fixed by PR `#86741` in `AccountSwitcher`:

App/src/components/AccountSwitcher.tsx

Line 148 in a4b6ddf

text: formatPhoneNumber(personalDetails?.displayName ?? personalDetails?.login ?? ''),

All affected paths in the Copilot flow (same raw displayName read):

• ConfirmDelegatePage.tsx#L40 — the reported page.
• CopilotPage.tsx delegate rows:

  App/src/pages/settings/Copilot/CopilotPage.tsx

  Lines 232 to 234 in a4b6ddf

  	const formattedEmail = formatPhoneNumber(email);
  	const titleText = personalDetail?.displayName ?? formattedEmail;
  	const descriptionText = personalDetail?.displayName ? formattedEmail : '';

• CopilotPage.tsx delegator rows:

  App/src/pages/settings/Copilot/CopilotPage.tsx

  Lines 282 to 284 in a4b6ddf

  	const isPending = !!pendingAction;
  	const titleText = personalDetail?.displayName ?? formattedEmail;
  	const descriptionText = personalDetail?.displayName ? formattedEmail : '';

• CopilotPage.tsx remove-access confirm prompt (delegatorName):

  App/src/pages/settings/Copilot/CopilotPage.tsx

  Line 95 in a4b6ddf

  const delegatorName = personalDetail?.displayName ?? formatPhoneNumber(delegatorEmail);

• (cosmetic) the two sortKey computations at CopilotPage.tsx#L205 and #L271 sort by the raw string.

I verified the other screens in the flow are unaffected: AddDelegatePage renders option.text built by the search selector (already formatted), and SelectDelegateRolePage / the two magic-code pages render no display name at all.

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

Wrap the raw displayName in formatPhoneNumber, the same fix PR #86741 merged for this exact symptom in the same feature. One line in ConfirmDelegatePage.tsx#L40:

const displayName = formatPhoneNumber(personalDetails?.displayName ?? '') || formattedLogin;

formatPhoneNumber detects the SMS domain, strips it, and locale-formats the number (national/international):

App/src/libs/LocalePhoneNumber.ts

Lines 29 to 49 in a4b6ddf

	if (number.indexOf(CONST.SMS.DOMAIN) === -1 && !CONST.REGEX.DIGITS_AND_PLUS.test(number)) {
	return number;
	}
	const numberWithoutSMSDomain = Str.removeSMSDomain(number);
	const parsedPhoneNumber = parsePhoneNumber(numberWithoutSMSDomain);
	// return the string untouched if it's not a phone number
	if (!parsedPhoneNumber.valid) {
	if (parsedPhoneNumber.number?.international) {
	return parsedPhoneNumber.number.international;
	}
	return numberWithoutSMSDomain;
	}
	const regionCode = parsedPhoneNumber.countryCode;
	if (regionCode === countryCodeByIPOnyx) {
	return parsedPhoneNumber.number.national;
	}
	return parsedPhoneNumber.number.international;

For a user with a real display name the early return at L29 leaves the string untouched, so nothing changes for email users or named users — that is the one-sentence regression safety, and it is the precedent-proven behavior already shipped in AccountSwitcher.tsx#L148.

Why the obvious spot-fix does not work: changing the fallback side of the expression (?? formattedLogin) can never fix this, because the ?? branch never executes — the backend guarantees displayName is populated (with the login) for SMS accounts, so the fix must transform the left-hand side. Likewise, swapping in getDisplayNameOrDefault(personalDetails) alone (the "canonical util" fix) only strips the domain, producing an unformatted E.164 +15551234567 title above a locale-formatted description — still inconsistent; the formatPhoneNumber wrap both strips and formats.

Secondary (optional, same PR): apply the same one-line wrap to the titles at CopilotPage.tsx#L233, #L283 and the prompt at #L95, which reproduce the identical symptom on the Copilot list once an SMS delegate/delegator exists; and on the confirm page, optionally blank the description when the user has no real display name (title and description would otherwise both show the formatted number), mirroring CopilotPage's title/description split.

What alternative solutions did you explore? (Optional)

1. formatPhoneNumber(getDisplayNameOrDefault(personalDetails, formattedLogin)) — equivalent result; getDisplayNameOrDefault strips the domain only when displayName === login, and the formatPhoneNumber wrap is still required for locale formatting, so the direct wrap is simpler and matches the merged precedent.
2. Str.removeSMSDomain(personalDetails?.displayName ?? '') — strips the domain but leaves an unformatted +15551234567, inconsistent with the formatted description below it.
3. Stop the backend stamping displayName = login for SMS accounts — not mergeable by a contributor, and every existing consumer (e.g. AccountSwitcher, getDisplayNameOrDefault) already compensates for the convention client-side; the App-side wrap is the established fix.

[mukhrr]

Proposal

What is the root cause of that problem?

ConfirmDelegatePage formats the delegate's login, but uses personalDetails.displayName unchanged whenever it exists:

App/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx

Lines 37 to 40 in a4b6ddf

	const personalDetails = getPersonalDetailByEmail(login);
	const avatarIcon = personalDetails?.avatar ?? icons.FallbackAvatar;
	const formattedLogin = formatPhoneNumber(login ?? '');
	const displayName = personalDetails?.displayName ?? formattedLogin;

For phone users who never chose a display name, the backend sets displayName equal to the SMS login, @expensify.sms included. That is documented behavior that getDisplayNameOrDefault already compensates for:

App/src/libs/PersonalDetailsUtils.ts

Lines 80 to 86 in a4b6ddf

	// If the displayName is not set by the user, the backend sets the displayName same as the login so
	// we need to remove the sms domain from the displayName if it is an sms login.
	if (Str.isSMSLogin(login)) {
	if (displayName === login) {
	displayName = Str.removeSMSDomain(displayName);
	}
	login = Str.removeSMSDomain(login);

So the nullish fallback to formattedLogin never runs, and the raw SMS-domain value reaches the menu item title:

App/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx

Lines 68 to 74 in a4b6ddf

	<MenuItem
	avatarID={personalDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID}
	iconType={CONST.ICON_TYPE_AVATAR}
	icon={avatarIcon}
	title={displayName}
	description={formattedLogin}
	interactive={false}

I confirmed this by seeding my local Onyx personalDetailsList with exactly what the backend returns for such a user (displayName === login === "+15551234567@expensify.sms") and opening the confirm page: the title rendered +15551234567@expensify.sms while the description right below it rendered +1 555-123-4567, matching the screenshot in the report.

The regression came in when phone formatting was first added to this page: that change formatted the login and the description, but left the unformatted personalDetails.displayName as the preferred title:

App/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx

Lines 43 to 46 in 74d5b1b

	const avatarIcon = personalDetails?.avatar ?? FallbackAvatar;
	const login = personalDetails?.login ?? optimisticDelegateData?.login;
	const formattedLogin = formatPhoneNumber(login ?? '');
	const displayName = personalDetails?.displayName ?? formattedLogin;

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

I think we should format the value we actually select for the title, rather than only its fallback:

- const displayName = personalDetails?.displayName ?? formattedLogin;
+ const displayName = formatPhoneNumber(personalDetails?.displayName ?? login ?? '');

formatPhoneNumber strips the SMS domain before parsing, and returns ordinary names and email addresses untouched because it bails out early for anything that has no SMS domain and isn't digits-and-plus:

App/src/libs/LocalePhoneNumber.ts

Lines 20 to 40 in a4b6ddf

	function formatPhoneNumber(number: string): string {
	if (!number) {
	return '';
	}
	// eslint-disable-next-line no-param-reassign
	number = number.replaceAll(' ', '\u00A0');
	// do not parse the string, if it doesn't contain the SMS domain and it's not a phone number
	if (number.indexOf(CONST.SMS.DOMAIN) === -1 && !CONST.REGEX.DIGITS_AND_PLUS.test(number)) {
	return number;
	}
	const numberWithoutSMSDomain = Str.removeSMSDomain(number);
	const parsedPhoneNumber = parsePhoneNumber(numberWithoutSMSDomain);
	// return the string untouched if it's not a phone number
	if (!parsedPhoneNumber.valid) {
	if (parsedPhoneNumber.number?.international) {
	return parsedPhoneNumber.number.international;
	}
	return numberWithoutSMSDomain;

This is the same shape the Account Switcher already uses for the copilot rows it renders, so we stay consistent with an existing, shipped treatment of the same data:

App/src/components/AccountSwitcher.tsx

Lines 148 to 149 in a4b6ddf

	text: formatPhoneNumber(personalDetails?.displayName ?? personalDetails?.login ?? ''),
	description: Str.removeSMSDomain(personalDetails?.login ?? ''),

I verified the fix on web: with the same seeded state, the title changed from +15551234567@expensify.sms to +1 555-123-4567, and a delegate with a real display name still rendered that name unchanged above the formatted phone number.

One thing worth calling out for QA: with the fix, a phone user with no display name shows the same formatted number on both the title and the description line. That is not something this change introduces — it is already how the page behaves for an email user with no display name, since the backend sets their displayName to their email too. I confirmed that on the current code: the confirm page renders nodisplayname@example.com on both lines today. So this change makes phone users consistent with email users rather than creating a new case.

For tests I would add tests/ui/ConfirmDelegatePageTest.tsx covering both directions — a delegate whose login and displayName are both +15551234567@expensify.sms, asserting the page renders no @expensify.sms anywhere and does render the localized number, plus a delegate with a genuine display name, asserting the name survives untouched next to the formatted login. I wrote these locally and checked that the first fails on the current code and passes with the change.

What alternative solutions did you explore? (Optional)

I considered routing the title through getDisplayNameOrDefault, which already knows about the "backend set displayName to the login" case. It works, but it only strips the domain, so the title would read +15551234567 while the description reads +1 555-123-4567 — two different renderings of one number on adjacent lines. Formatting the selected value gives one consistent representation with a smaller diff.

I also considered changing the backend-provided personal details or the shared display-name utilities, but the backend fallback is long-established behavior that other screens already sanitize at the render layer, so fixing this page's inconsistent formatting is the narrowest correct change.

Finally, while tracing this I noticed the Copilot page itself uses the identical expression for both the delegates list and the delegators list, so an SMS copilot's row on the page you land on right after adding them has the same problem:

App/src/pages/settings/Copilot/CopilotPage.tsx

Lines 232 to 234 in a4b6ddf

	const formattedEmail = formatPhoneNumber(email);
	const titleText = personalDetail?.displayName ?? formattedEmail;
	const descriptionText = personalDetail?.displayName ? formattedEmail : '';

I left it out of the change above to keep this PR scoped to the reported page, but it is the same root cause and the same one-line treatment, and I am happy to include it here if we would rather not file a duplicate later.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-23 19:45:07 UTC.

Proposal

What is the root cause of that problem?

For phone-number accounts without a user-defined name, the backend legitimately supplies the internal SMS login as both login and displayName. The App already normalizes that convention in temporaryGetDisplayNameOrDefault() by stripping @expensify.sms when those two values match.

App/src/libs/PersonalDetailsUtils.ts

Lines 128 to 147 in b444723

	let displayName = passedPersonalDetails?.displayName ?? '';
	let login = passedPersonalDetails?.login ?? '';
	// If the displayName starts with the merged account prefix, remove it.
	if (regexMergedAccount.test(displayName)) {
	// Remove the merged account prefix from the displayName.
	displayName = displayName.replaceAll(CONST.REGEX.MERGED_ACCOUNT_PREFIX, '');
	}
	// If the displayName is not set by the user, the backend sets the displayName same as the login so
	// we need to remove the sms domain from the displayName if it is an sms login.
	if (Str.isSMSLogin(login)) {
	if (displayName === login) {
	displayName = Str.removeSMSDomain(displayName);
	}
	login = Str.removeSMSDomain(login);
	}
	if (shouldAddCurrentUserPostfix && !!displayName) {

However, the Copilot confirmation page does not use that normalizer. It prefers any non-null personalDetails.displayName for the row title and applies formatPhoneNumber() only to the description. Because the backend fallback display name is non-null, the internal SMS login becomes the visible title.

App/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx

Lines 37 to 40 in b444723

	const personalDetails = getPersonalDetailByEmail(login);
	const avatarIcon = personalDetails?.avatar ?? icons.FallbackAvatar;
	const formattedLogin = formatPhoneNumber(login ?? '');
	const displayName = personalDetails?.displayName ?? formattedLogin;

The Copilot list repeats the same raw-display-name preference for delegates and delegators, which is why the attached screenshot also shows the domain after the flow completes.

App/src/pages/settings/Copilot/CopilotPage.tsx

Lines 201 to 234 in b444723

	);
	const delegateMenuItems: MenuItemProps[] = useMemo(() => {
	const sortedDelegates = sortAlphabetically(
	delegates.filter((d) => !d.optimisticAccountID).map((d) => ({...d, sortKey: personalDetailsByLogin[d.email.toLowerCase()]?.displayName ?? formatPhoneNumber(d.email)})),
	'sortKey',
	localeCompare,
	);
	return sortedDelegates.map(({email, role, pendingAction, pendingFields}) => {
	const personalDetail = personalDetailsByLogin[email.toLowerCase()];
	const addDelegateErrors = errorFields?.addDelegate?.[email];
	const error = getLatestError(addDelegateErrors);
	const isOwnerRow = isAgentAccount && !!actingDelegateEmail && email.toLowerCase() === actingDelegateEmail;
	const onPress = (e: GestureResponderEvent | KeyboardEvent) => {
	if (isEmptyObject(pendingAction)) {
	showPopoverMenu(e, {email, role});
	return;
	}
	if (!role) {
	Navigation.navigate(ROUTES.SETTINGS_DELEGATE_ROLE.getRoute(email));
	return;
	}
	if (pendingFields?.role && !pendingFields?.email) {
	Navigation.navigate(ROUTES.SETTINGS_UPDATE_DELEGATE_ROLE.getRoute(email, role));
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS_DELEGATE_CONFIRM.getRoute(email, role));
	};
	const formattedEmail = formatPhoneNumber(email);
	const titleText = personalDetail?.displayName ?? formattedEmail;
	const descriptionText = personalDetail?.displayName ? formattedEmail : '';

App/src/pages/settings/Copilot/CopilotPage.tsx

Lines 271 to 284 in b444723

	delegators.map((d) => ({...d, sortKey: personalDetailsByLogin[d.email.toLowerCase()]?.displayName ?? formatPhoneNumber(d.email)})),
	'sortKey',
	localeCompare,
	);
	const delegatorMenuItems: MenuItemProps[] = sortedDelegators.map(({email, role, pendingAction}) => {
	const personalDetail = personalDetailsByLogin[email.toLowerCase()];
	const formattedEmail = formatPhoneNumber(email);
	const connectError = getLatestError(errorFields?.connect?.[email]);
	const removeDelegatorError = getLatestError(errorFields?.removeDelegator?.[email]);
	const error = getLatestError({...connectError, ...removeDelegatorError});
	const isCurrentUser = email === session?.email;
	const isPending = !!pendingAction;
	const titleText = personalDetail?.displayName ?? formattedEmail;
	const descriptionText = personalDetail?.displayName ? formattedEmail : '';

This behavior dates back to the original confirmation-row implementation, which directly preferred displayName over login. The later phone-formatting change formatted only the subtitle and kept the raw title preference.

db4d5be

74d5b1b

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

Resolve the effective Copilot name through temporaryGetDisplayNameOrDefault() and then pass that result through formatPhoneNumber(). Use the formatted login as the fallback when personal details are unavailable. This preserves real display names, converts the backend's SMS-login fallback into a locale-formatted phone number, and reuses the existing shared rule rather than changing legitimate personal-details data.

Apply the same resolution to the confirmation row and every Copilot-page consumer of delegate/delegator names: row titles, sort keys, and the removal confirmation name. Only show the formatted-login subtitle when it differs from the effective title, so a nameless phone account does not render the same phone number twice.

App/src/pages/settings/Copilot/CopilotPage.tsx

Lines 93 to 99 in b444723

	const showRemoveDelegatorModal = (delegatorEmail: string) => {
	const personalDetail = personalDetailsByLogin[delegatorEmail.toLowerCase()];
	const delegatorName = personalDetail?.displayName ?? formatPhoneNumber(delegatorEmail);
	return showConfirmModal({
	title: translate('delegate.removeCopilotAccessTitle'),
	prompt: translate('delegate.removeCopilotAccessConfirmation', {delegatorName}),

The normal picker-to-role flow, a pending delegate reopened from the Copilot page, and direct confirmation-route navigation all converge on the confirmation row, so this fixes each confirmation entry path.

App/src/pages/settings/Security/AddDelegate/AddDelegatePage.tsx

Lines 50 to 55 in b444723

	const handleSelectRow = (option: OptionData) => {
	// toggleSelection would deselect an already-selected row on re-tap, so only select when it isn't selected yet
	if (!option.isSelected) {
	toggleSelection(option);
	}
	Navigation.navigate(ROUTES.SETTINGS_DELEGATE_ROLE.getRoute(option.login ?? ''));

App/src/pages/settings/Security/AddDelegate/SelectDelegateRolePage.tsx

Lines 70 to 76 in b444723

	customListHeader={<DelegateRoleSelectionListHeader />}
	onSelectRow={(option) => {
	Navigation.setParams({
	role: option.value,
	});
	Navigation.navigate(ROUTES.SETTINGS_DELEGATE_CONFIRM.getRoute(login, option.value));
	}}

App/src/pages/settings/Copilot/CopilotPage.tsx

Lines 214 to 230 in b444723

	const onPress = (e: GestureResponderEvent | KeyboardEvent) => {
	if (isEmptyObject(pendingAction)) {
	showPopoverMenu(e, {email, role});
	return;
	}
	if (!role) {
	Navigation.navigate(ROUTES.SETTINGS_DELEGATE_ROLE.getRoute(email));
	return;
	}
	if (pendingFields?.role && !pendingFields?.email) {
	Navigation.navigate(ROUTES.SETTINGS_UPDATE_DELEGATE_ROLE.getRoute(email, role));
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS_DELEGATE_CONFIRM.getRoute(email, role));
	};

The magic-code page has no delegate identity row, so it does not need this display-name change.

App/src/pages/settings/Security/AddDelegate/ConfirmDelegateMagicCodePage.tsx

Lines 26 to 64 in b444723

	function ConfirmDelegateMagicCodePage({route}: ConfirmDelegateMagicCodePageProps) {
	const {translate} = useLocalize();
	const login = route.params.login;
	const role = route.params.role as ValueOf<typeof CONST.DELEGATE_ROLE>;
	const [account] = useOnyx(ONYXKEYS.ACCOUNT);
	const [validateCodeAction] = useOnyx(ONYXKEYS.VALIDATE_ACTION_CODE);
	const currentDelegate = account?.delegatedAccess?.delegates?.find((d) => d.email === login);
	const addDelegateErrors = account?.delegatedAccess?.errorFields?.addDelegate?.[login];
	const validateLoginError = getLatestError(addDelegateErrors);
	const [session] = useOnyx(ONYXKEYS.SESSION);
	useEffect(() => {
	if (!currentDelegate || !!currentDelegate.pendingFields?.email || !!addDelegateErrors) {
	return;
	}
	// Dismiss modal on successful magic code verification
	Navigation.goBack(ROUTES.SETTINGS_COPILOT);
	}, [login, currentDelegate, role, addDelegateErrors]);
	const clearError = () => {
	if (isEmptyObject(validateLoginError) && isEmptyObject(validateCodeAction?.errorFields)) {
	return;
	}
	clearDelegateErrorsByField({email: currentDelegate?.email ?? '', fieldName: 'addDelegate', delegatedAccess: account?.delegatedAccess});
	};
	return (
	<ValidateCodeActionContent
	clearError={clearError}
	validateCodeActionErrorField="addDelegate"
	onClose={() => Navigation.goBack(ROUTES.SETTINGS_DELEGATE_CONFIRM.getRoute(login, role))}
	validateError={validateLoginError}
	title={translate('delegate.makeSureItIsYou')}
	sendValidateCode={() => requestValidateCodeAction()}
	handleSubmitForm={(validateCode) => addDelegate({email: login, role, validateCode, delegatedAccess: account?.delegatedAccess})}
	descriptionPrimary={translate('delegate.enterSecurityCode', account?.primaryLogin ?? session?.email ?? '')}
	/>
	);

formatPhoneNumber() already removes the SMS suffix while leaving ordinary names unchanged, and createDisplayName() demonstrates the same formatter-at-presentation-boundary convention.

App/src/libs/LocalePhoneNumber.ts

Lines 20 to 50 in b444723

	function formatPhoneNumber(number: string): string {
	if (!number) {
	return '';
	}
	// eslint-disable-next-line no-param-reassign
	number = number.replaceAll(' ', '\u00A0');
	// do not parse the string, if it doesn't contain the SMS domain and it's not a phone number
	if (number.indexOf(CONST.SMS.DOMAIN) === -1 && !CONST.REGEX.DIGITS_AND_PLUS.test(number)) {
	return number;
	}
	const numberWithoutSMSDomain = Str.removeSMSDomain(number);
	const parsedPhoneNumber = parsePhoneNumber(numberWithoutSMSDomain);
	// return the string untouched if it's not a phone number
	if (!parsedPhoneNumber.valid) {
	if (parsedPhoneNumber.number?.international) {
	return parsedPhoneNumber.number.international;
	}
	return numberWithoutSMSDomain;
	}
	const regionCode = parsedPhoneNumber.countryCode;
	if (regionCode === countryCodeByIPOnyx) {
	return parsedPhoneNumber.number.national;
	}
	return parsedPhoneNumber.number.international;
	}

App/src/libs/PersonalDetailsUtils.ts

Lines 492 to 513 in b444723

	function createDisplayName(
	login: string,
	passedPersonalDetails: Pick<PersonalDetails, 'firstName' | 'lastName'> | OnyxInputOrEntry<PersonalDetails>,
	formatPhoneNumber: LocaleContextProps['formatPhoneNumber'],
	): string {
	// If we have a number like +15857527441@expensify.sms then let's remove @expensify.sms and format it
	// so that the option looks cleaner in our UI.
	const userLogin = formatPhoneNumber(login);
	if (!passedPersonalDetails) {
	return userLogin;
	}
	const firstName = passedPersonalDetails.firstName ?? '';
	const lastName = passedPersonalDetails.lastName ?? '';
	const fullName = `${firstName} ${lastName}`.trim();
	// It's possible for fullName to be empty string, so we must use "||" to fallback to userLogin.
	return fullName || userLogin;
	}
	/**

Test coverage:

• Add a confirmation-page test with login and displayName both set to an @expensify.sms login; assert that the domain is absent and the formatted phone number is shown without a duplicate subtitle.
• Add a confirmation-page case with a real display name; assert that the name remains the title and the formatted phone is the subtitle.
• Extend the Copilot-page tests for both delegate and delegator rows, including sorting/removal-name resolution, to cover nameless SMS users and custom display names.

What alternative solutions did you explore? (Optional)

Changing the backend or rewriting the personal-details entry would be too broad because the SMS login is valid identity data and the App already treats displayName === login as a presentation fallback. Calling formatPhoneNumber() only on the raw display name would hide this instance, but it would duplicate established normalization logic and would not consistently handle fallback, sorting, subtitle, and removal-modal behavior.

[melvin-bot]

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

[wildan-m]

Proposal

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

On the "Add a copilot" confirmation page (Account > Copilot > Add a copilot > pick a phone-number user with no display name > continue), the copilot's name is rendered as the raw SMS login, e.g. +1555xxxxxxx@expensify.sms, instead of the formatted phone number. The line below it already shows the correctly formatted number, so the same person is shown twice, once correctly and once with the internal @expensify.sms domain leaking into the UI.

What is the root cause of that problem?

The confirm page takes the personal detail's displayName verbatim and only falls back to the formatted login when displayName is missing:

App/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx

Lines 39 to 40 in a4b6ddf

	const formattedLogin = formatPhoneNumber(login ?? '');
	const displayName = personalDetails?.displayName ?? formattedLogin;

For an account that has never set a name, the backend sets displayName equal to the login, and for a phone-number account that login is the SMS login including the @expensify.sms domain. So displayName is not empty — it is the string +1555xxxxxxx@expensify.sms — which means the ?? formattedLogin fallback never runs, and that raw value is passed straight to the menu item title:

App/src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx

Lines 68 to 75 in a4b6ddf

	<MenuItem
	avatarID={personalDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID}
	iconType={CONST.ICON_TYPE_AVATAR}
	icon={avatarIcon}
	title={displayName}
	description={formattedLogin}
	interactive={false}
	/>

The description on the same menu item does not have the bug because it uses formattedLogin, which goes through formatPhoneNumber — that helper is exactly the one that strips the SMS domain and applies locale formatting:

App/src/libs/LocalePhoneNumber.ts

Lines 20 to 48 in a4b6ddf

	function formatPhoneNumber(number: string): string {
	if (!number) {
	return '';
	}
	// eslint-disable-next-line no-param-reassign
	number = number.replaceAll(' ', '\u00A0');
	// do not parse the string, if it doesn't contain the SMS domain and it's not a phone number
	if (number.indexOf(CONST.SMS.DOMAIN) === -1 && !CONST.REGEX.DIGITS_AND_PLUS.test(number)) {
	return number;
	}
	const numberWithoutSMSDomain = Str.removeSMSDomain(number);
	const parsedPhoneNumber = parsePhoneNumber(numberWithoutSMSDomain);
	// return the string untouched if it's not a phone number
	if (!parsedPhoneNumber.valid) {
	if (parsedPhoneNumber.number?.international) {
	return parsedPhoneNumber.number.international;
	}
	return numberWithoutSMSDomain;
	}
	const regionCode = parsedPhoneNumber.countryCode;
	if (regionCode === countryCodeByIPOnyx) {
	return parsedPhoneNumber.number.national;
	}

This is a known shape of the data — the display-name helper in PersonalDetailsUtils documents and handles precisely this case (when displayName equals the login and the login is an SMS login, the SMS domain must be removed), but the confirm page never routes the value through any such helper:

App/src/libs/PersonalDetailsUtils.ts

Lines 80 to 87 in a4b6ddf

	// If the displayName is not set by the user, the backend sets the displayName same as the login so
	// we need to remove the sms domain from the displayName if it is an sms login.
	if (Str.isSMSLogin(login)) {
	if (displayName === login) {
	displayName = Str.removeSMSDomain(displayName);
	}
	login = Str.removeSMSDomain(login);
	}

The earlier steps of the flow (the copilot search list) do not show the bug because the options list builds its text through the shared options utilities, which already format phone numbers. Only this confirmation screen reads displayName raw.

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

In src/pages/settings/Security/AddDelegate/ConfirmDelegatePage.tsx, pass the personal detail's display name through formatPhoneNumber before showing it, instead of using it as-is. Concretely, the displayName constant on line 40 should be computed as: when the personal detail has a display name, use the result of calling the existing formatPhoneNumber (already destructured from useLocalize on line 32) on it; otherwise keep the existing formattedLogin fallback.

formatPhoneNumber is safe for the non-phone case: it returns the input untouched when the string has no SMS domain and is not digits/plus, so real names such as "Jane Doe" and plain email logins are unaffected. For an SMS login it removes the @expensify.sms domain and renders the number in national or international format depending on the viewer's country code — the same value the description line below already shows, so the title and description become consistent instead of contradicting each other.

This mirrors how the rest of the app renders a personal detail's display name, e.g. the account switcher and the workspace approver rows both wrap displayName in formatPhoneNumber before rendering:

App/src/pages/workspace/categories/WorkspaceCategoriesPage.tsx

Lines 276 to 278 in a4b6ddf

	const approverPersonalDetail = getPersonalDetailByEmail(approverEmail);
	const {avatar: approverAvatar, displayName = approverEmail, accountID: approverAccountID} = approverPersonalDetail ?? {};
	const approverDisplayName = displayName ? formatPhoneNumber(displayName) : '';

The change is confined to that one derived value in the confirm page; no other behaviour on the page changes, and the copilot login that is actually submitted to the API is untouched (the route param login is what is passed on to the magic code step).

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/96868-format-copilot-name?expand=1

What alternative solutions did you explore? (Optional)

I considered replacing the manual personalDetails?.displayName ?? formattedLogin expression with the shared getDisplayNameOrDefault helper from PersonalDetailsUtils, which already removes the SMS domain when the display name equals the login. I did not pick it because that helper only strips the domain — it does not apply locale phone formatting — so the title would read as a bare +1555xxxxxxx while the description right below it reads as a formatted number, leaving a subtler version of the same inconsistency. Wrapping in formatPhoneNumber covers both the domain stripping and the formatting in one step, so the two lines agree.

I also considered fixing this further upstream by normalising displayName when personal details are stored in Onyx, but that would change the value everywhere in the app for a display concern, and would risk altering places that legitimately need the raw login. Formatting at the render site is the narrower, safer fix.