[$250] Move Copilot settings to its own section under Preferences

[MelvinBot]

Background

Customers are reporting confusion finding Copilot settings in New Expensify. The current placement is not intuitive, and users are erroneously assuming they've lost access. The flow has more friction than Classic (3 clicks vs 2, navigation in two different places).

Agreed Changes

Based on team discussion, the following changes were agreed upon:

1. Move Copilot to its own section under Preferences

• Remove Copilot from the Security settings page
• Add Copilot as its own dedicated menu item under Account settings, placed under Preferences

2. Reorganize the Copilot page layout

• Position "You can access these accounts" at the top of the page
• Use two separate cards to clearly distinguish:
  • Accounts you have access to (accounts you can copilot)
  • Accounts that have access to your account (accounts that can copilot you)

3. Add a "Switch" action button

• Add a "Switch" action button to each account in the "accounts you have access to" list, so it's clear users can immediately copilot into those accounts

Slack thread: https://expensify.slack.com/archives/C03U7DCU4/p1776938004324109

Issue Owner

Current Issue Owner: @wildan-m

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049812310570599104
• Upwork Job ID: 2049812310570599104
• Last Price Increase: 2026-04-30
• Automatic offers:
• wildan-m | Contributor | 111294915

[flaviadefaria]

cc @laurenreidexpensify @shawnborton

[melvin-bot]

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

[melvin-bot]

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

[wildan-m]

Proposal

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

Copilot settings currently live as a sub-section of the Security settings page (Account → Security), and the related delegator list ("accounts you can copilot") is only surfaced via the account switcher. The team has agreed (per the linked Slack thread) that this placement is unintuitive and adds friction (3 clicks vs. 2 in Classic, navigation split across two places). We need to:

1. Promote Copilot to a dedicated top-level menu item under Account, positioned between Preferences and Security.
2. Reorganize the Copilot page so "Accounts you have access to" (delegators) appears at the top, with two clearly separated cards.
3. Add a "Switch" action button to each row in the "Accounts you have access to" list so users can copilot into those accounts directly from the Copilot page.

What is the root cause of that problem?

The Copilot UI was originally implemented as a section nested inside SecuritySettingsPage, sharing the same screen as 2FA, account merging, lock account, and close account. Copilot is conceptually a delegation/access feature, not a security control, so its placement under Security made it hard to discover and conceptually inconsistent. The page also leads with the "members can access your account" (delegates) list, while in practice users more often want to access the accounts that have delegated to them (delegators) — currently only reachable via the account switcher, with no inline switch action.

The Copilot section is rendered today inside SecuritySettingsPage.tsx as the second <Section> in the page (under the "Copilot: Delegated access" heading), with delegators only shown as a secondary list and no per-row switch action:

App/src/pages/settings/Security/SecuritySettingsPage.tsx

Lines 429 to 477 in 2de2b6e

	<Section
	title={translate('delegate.copilotDelegatedAccess')}
	renderSubtitle={() => (
	<SectionSubtitleHTML
	html={`${translate('delegate.copilotDelegatedAccessDescription')} <a href="${CONST.COPILOT_HELP_URL}" accessibilityLabel="${translate('delegate.learnMoreAboutDelegatedAccess')}">${translate('common.learnMore')}</a>.`}
	subtitleMuted
	/>
	)}
	isCentralPane
	subtitleMuted
	titleStyles={styles.accountSettingsSectionTitle}
	childrenStyles={styles.pt5}
	>
	{hasDelegates && (
	<>
	<Text style={[styles.textLabelSupporting, styles.pv1]}>{translate('delegate.membersCanAccessYourAccount')}</Text>
	<MenuItemList menuItems={delegateMenuItems} />
	</>
	)}
	<MenuItem
	title={translate('delegate.addCopilot')}
	icon={icons.UserPlus}
	sentryLabel={CONST.SENTRY_LABEL.SETTINGS_SECURITY.ADD_COPILOT}
	onPress={() => {
	if (isActingAsDelegate) {
	modalClose(() => showDelegateNoAccessModal());
	return;
	}
	if (!isUserValidated) {
	Navigation.navigate(ROUTES.SETTINGS_DELEGATE_VERIFY_ACCOUNT);
	return;
	}
	if (isAccountLocked) {
	showLockedAccountModal();
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS_ADD_DELEGATE);
	}}
	shouldShowRightIcon
	wrapperStyle={[styles.sectionMenuItemTopDescription, hasDelegators && styles.mb6]}
	/>
	{hasDelegators && (
	<>
	<Text style={[styles.textLabelSupporting, styles.pv1]}>{translate('delegate.youCanAccessTheseAccounts')}</Text>
	<MenuItemList menuItems={delegatorMenuItems} />
	</>
	)}
	</Section>
	</View>

The account-switcher delegator selection already invokes the connect action from Delegate.ts, which is the same mechanism we will reuse for the new "Switch" button:

App/src/components/AccountSwitcher.tsx

Lines 193 to 219 in 2de2b6e

	const delegatorMenuItems: PopoverMenuItem[] = sortAlphabetically(
	delegators
	.filter(({email}) => email !== currentUserPersonalDetails.login)
	.map(({email, role}) => {
	const errorFields = account?.delegatedAccess?.errorFields ?? {};
	const error = getLatestError(errorFields?.connect?.[email]);
	const personalDetails = getPersonalDetailByEmail(email);
	return createBaseMenuItem(personalDetails, error, {
	badgeText: translate('delegate.role', {role}),
	onSelected: () => {
	if (isOffline) {
	close(showOfflineModal);
	return;
	}
	if (isTrackingGPS) {
	close(() => showGpsInProgressModal(() => connect({email, delegatedAccess: account?.delegatedAccess, credentials, session, activePolicyID})));
	return;
	}
	connect({email, delegatedAccess: account?.delegatedAccess, credentials, session, activePolicyID});
	},
	});
	}),
	'text',
	localeCompare,
	);
	return [currentUserMenuItem, ...delegatorMenuItems];

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

The fix has four coordinated parts.

1. Add a new dedicated Copilot screen.

Create a new file src/pages/settings/Copilot/CopilotPage.tsx that owns the Copilot experience. Move the Copilot-specific logic out of SecuritySettingsPage.tsx into this new page:

• The useOnyx(ONYXKEYS.ACCOUNT) subscription and the delegates / delegators derivations.
• The delegateMenuItems and delegatorMenuItems useMemo blocks and the delegatePopoverMenuItems array.
• The showRemoveCopilotModal useConfirmModal callback, the showPopoverMenu, popover anchor/position state, and the openSecuritySettingsPage effect (which becomes openCopilotPage or stays as-is if the existing endpoint is what we already call to hydrate delegatedAccess).
• The locked-account / delegate-no-access guards already wrapping these actions.

The new page should render with a HeaderWithBackButton titled with a new translation key (e.g. delegate.copilot) and use a Copilot-themed illustration (a dedicated entry under useMemoizedLazyIllustrations, similar to how useSecuritySettingsSectionIllustration is wired up today).

2. Reorganize the layout into two stacked Section cards.

Inside the new CopilotPage, render two <Section> components in this order:

• Top card — "Accounts you have access to" (delegate.youCanAccessTheseAccounts reused or renamed). Renders delegatorMenuItems. Each row gets a new "Switch" action button (see part 3). When the user has no delegators, render an empty-state subtitle but still show the card so the structure stays consistent.
• Bottom card — "Accounts that have access to your account" (delegate.membersCanAccessYourAccount reused or renamed). Renders delegateMenuItems plus the existing "Add copilot" MenuItem button at the bottom and the popover for change-access / remove flows.

Use the same Section styling already in SecuritySettingsPage (isCentralPane, subtitleMuted, titleStyles={styles.accountSettingsSectionTitle}, childrenStyles={styles.pt5}) so the visual treatment matches the existing settings pages. The page-level subtitle ("Allow other members to access your account…learn more") moves to the bottom card subtitle since it specifically describes inviting delegates, not switching to delegators.

3. Add a "Switch" action button per delegator row.

In the top card, each delegator row should render a right-aligned Button (label translated as delegate.switchAccount → "Switch") next to the role badge. The press handler invokes the same connect({email, delegatedAccess, credentials, session, activePolicyID}) call that the account switcher uses today. We will reuse the existing offline / GPS-tracking guards from AccountSwitcher (showing showOfflineModal when offline and the GPS-in-progress modal when a trip is active), and the existing error rendering via errorFields.connect[email].

Two implementation notes:

• The current delegatorMenuItems builds plain MenuItemProps with interactive: false. We will switch to a custom row component (or extend MenuItemProps with a right-side button slot) so the row stays informational while the dedicated Switch button owns the action. This avoids accidentally triggering the switch when the user taps anywhere in the row.
• Disable the Switch button while pendingAction is set on that delegator entry (the existing optimistic-update pattern), and surface the connect error inline via the same clearDelegatorErrors mechanism used by AccountSwitcher.

4. Wire up navigation and remove Copilot from Security.

• Add SCREENS.SETTINGS.COPILOT.ROOT and ROUTES.SETTINGS_COPILOT = 'settings/copilot'.
• Register the new screen in the settings central-pane / RHP relations alongside the existing settings entries (mirror how SETTINGS_PREFERENCES is wired in SETTINGS_TO_RHP.ts and the central-pane navigator).
• In InitialSettingsPage.tsx, add a new entry to the accountItems array between 'common.preferences' and 'initialSettingsPage.security' (so it lands directly under Preferences, matching the URL-usage ordering called out in the issue). Use a Copilot-appropriate icon (e.g. icons.UserPlus or a new dedicated icon if design provides one) and a sentry label following the existing CONST.SENTRY_LABEL.ACCOUNT.* pattern.
• In SecuritySettingsPage.tsx, delete the entire Copilot <Section> (lines 429–477 today), the trailing <PopoverMenu> for delegate management (lines 478–494), and the related state/memo/callback declarations that were moved to CopilotPage. Drop the now-unused imports (MenuItem, SectionSubtitleHTML, the personal-details/Onyx pieces only used by the Copilot section, etc.). The remaining security menu items (2FA, MFA revoke, merge accounts, lock/unlock, close account) stay untouched.

5. Translations.

• Add delegate.copilot (menu item title — "Copilot").
• Add delegate.switchAccount ("Switch") for the new button.
• Reuse delegate.copilotDelegatedAccess for the page-level title or a tightened variant for the menu icon line; keep the existing youCanAccessTheseAccounts / membersCanAccessYourAccount / copilotDelegatedAccessDescription / addCopilot / removeCopilot strings, just relocated.
• Mirror all new keys across every locale file in src/languages/.

The result: Copilot becomes its own top-level Account menu item one click away from any Account settings landing, the page leads with the more frequently used "you can access these accounts" list with an inline Switch action, and the Security page is trimmed down to genuine security controls.

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

What alternative solutions did you explore? (Optional)

• Keep Copilot under Security and just reorder the two lists / add the Switch button in place. Rejected because it does not address the discoverability complaint that drove the issue — users explicitly reported assuming they had lost access because the feature was nested under Security.
• Place Copilot as a sub-page under Preferences (settings/preferences/copilot) rather than its own top-level menu entry. Rejected because the agreed change in the issue is explicit: "Add Copilot as its own dedicated menu item under Account settings, placed under Preferences." The dedicated top-level entry also matches the URL-level click data referenced in the issue.
• Reuse the AccountSwitcher popover delegator rows verbatim inside the new page. Rejected because the page version needs richer per-row affordances (Switch button, error inline, role badge layout) that do not fit the popover menu item shape; building a dedicated row component keeps both surfaces clean.

[neerajbachani]

Proposal

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

Copilot settings are currently buried inside the Security settings page, which makes them hard to discover. Users are reporting they think they've lost access to Copilot entirely. The agreed fix is to promote Copilot to its own dedicated menu item under Account (between Preferences and Security), reorganize the page so "accounts you can access" appears first with inline Switch buttons, and remove Copilot from the Security page.

What is the root cause of that problem?

Copilot was originally implemented as a <Section> inside SecuritySettingsPage.tsx. It is conceptually a delegation/access feature, not a security control, so placing it under Security made it unintuitive to find. The page also leads with "members who can access your account" (delegates), when users more frequently need "accounts you can switch into" (delegators) — which today is only reachable via the account switcher with no inline action.

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

12 files need to change, in this order:

1. src/CONST/index.ts — Add SENTRY_LABEL.ACCOUNT.COPILOT: 'Account-Copilot' following the existing PROFILE / PREFERENCES / SECURITY pattern.

2. src/languages/en.ts (+ all locale files) — Add delegate.copilot ("Copilot") for the menu item label and delegate.switchAccount ("Switch") for the per-row button. All existing delegate.* strings are reused on the new page.

3. src/SCREENS.ts — Add SCREENS.SETTINGS.COPILOT as a top-level settings central-pane screen constant, same style as SCREENS.SETTINGS.SECURITY.

4. src/ROUTES.ts — Add ROUTES.SETTINGS_COPILOT = 'settings/copilot' following the existing settings/preferences and settings/security convention.

5. src/libs/Navigation/types.ts — Add [SCREENS.SETTINGS.COPILOT]: undefined to SettingsSplitNavigatorParamList.

6. src/libs/Navigation/AppNavigator/Navigators/SettingsSplitNavigator.tsx — Register SCREENS.SETTINGS.COPILOT in CENTRAL_PANE_SETTINGS_SCREENS pointing to the new CopilotPage.

7. src/libs/Navigation/linkingConfig/config.ts — Add deep-link mapping SCREENS.SETTINGS.COPILOT → ROUTES.SETTINGS_COPILOT.

8. src/libs/Navigation/linkingConfig/RELATIONS/SETTINGS_TO_RHP.ts — Move the delegate subflow screens (add copilot, verify account, etc.) from SCREENS.SETTINGS.SECURITY to SCREENS.SETTINGS.COPILOT so RHP back navigation stays correct after the move.

9. src/pages/settings/InitialSettingsPage.tsx — Insert a new account menu item between Preferences and Security entries with translationKey: 'delegate.copilot', screenName: SCREENS.SETTINGS.COPILOT, sentryLabel: CONST.SENTRY_LABEL.ACCOUNT.COPILOT, and icon icons.UserSwitch (or icons.UserPlus as fallback if no dedicated icon exists).

10. src/pages/settings/Copilot/CopilotPage.tsx (new file) — New dedicated page following the src/pages/settings/Preferences/PreferencesPage.tsx file convention. Structure:

• ScreenWrapper + HeaderWithBackButton titled delegate.copilotDelegatedAccess
• Subscribes to ONYXKEYS.ACCOUNT, ONYXKEYS.CREDENTIALS, ONYXKEYS.SESSION, ONYXKEYS.NVP_ACTIVE_POLICY_ID
• Extracts all Copilot-specific state and logic from SecuritySettingsPage: delegateButtonRef, shouldShowDelegatePopoverMenu, selectedDelegate, selectedEmail, showConfirmModal, showRemoveCopilotModal, anchorPosition, setMenuPosition, showPopoverMenu, delegateMenuItems, delegatorMenuItems, delegatePopoverMenuItems
• Renders two labeled subsections inside one <Section> (matching the mockup — single card, not two separate cards):
  • Top: "You can access these accounts" — delegatorMenuItems where each row uses MenuItem with shouldShowRightComponent and rightComponent set to a green "Switch" Button. The Switch handler reuses the exact same guard chain from AccountSwitcher: offline check → GPS tracking check → connect({email, delegatedAccess, credentials, session, activePolicyID})
  • Bottom: "These members can access your account" — delegateMenuItems + existing "Add copilot" MenuItem + PopoverMenu for change-access/remove flows
• Empty state: if user has no delegators, the "You can access these accounts" label still renders with an empty-state subtitle so the structure is consistent

11. src/pages/settings/Security/SecuritySettingsPage.tsx — Remove the entire Copilot <Section> (lines ~429–477), the delegate <PopoverMenu> (lines ~478–494), and all Copilot-only state/callbacks/imports listed above. The remaining security controls (2FA, merge accounts, lock/unlock, close account) are untouched. Note: isActingAsDelegate check remains because it is also used by the security-specific lock account guard.

What alternative solutions did you explore? (Optional)

• Two separate <Section> cards for the two lists: rejected because the mockup shows a single unified page card with two labeled subsections, not two distinct cards.
• Keep Copilot under Security, just reorder lists: rejected — the issue explicitly states the agreed change is a dedicated top-level menu item for discoverability.
• Sub-page under Preferences (settings/preferences/copilot): rejected — the issue spec says a dedicated top-level Account menu item placed under Preferences in the menu order, not nested inside it.

[github-actions]

⚠️ @neerajbachani 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.

[Nghondzweni]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.