[$250] Copilot: Removing Copilot Triggers Auto-Populated New Account Sign-Up Flow

[nlemma]

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.4-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #78785
Email or phone of affected tester (no customers): applausetester+dp500@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Xiaomi Poco X4 / A13
App Component: Other

Action Performed:

1. Log in as a Copilot user.
2. Navigate to Settings → Security.
3. Scroll down to the Copilot section.
4. From the copilots list, click the three-dot (⋯) menu next to the current login.
5. Select Remove Copilot and submit

Expected Result:

The copilot is successfully removed.
The app cleanly switches to the current user’s existing account (normal login/session state).
No sign-up or authentication flow is triggered.

Actual Result:

Before switching to the current user, the app displays a New Member sign-up page with a “Join” button for a user who already has an account, after that, a Magic Code authentication screen appears., the magic code field is auto-populated, even though no login action was initiated by the user.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7051594_1768626391136.8_55_PM_2026-01-16.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022013317622984663758
• Upwork Job ID: 2013317622984663758
• Last Price Increase: 2026-01-19

Issue Owner

Current Issue Owner: @brunovjk

[melvin-bot]

@mollfpr recently merged #78785, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @CortneyOfstad (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @Gonals (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #78785 - "Copilot/align security features access with OldDot" by @ChavdaSachin (High confidence)
Related Issues: #78105 (original issue that PR #78785 was fixing)

Recommendation: REVERT

PR #78785 introduced a regression by removing access control checks that prevented the automatic disconnect flow from working properly when a copilot removes themselves. The PR inadvertently changed the behavior so that when the current copilot login removes themselves, the app triggers an unintended sign-up/authentication flow instead of cleanly switching back to the original user account.

Labels: This is a Frontend bug - the DeployBlockerCash label is correct and should remain. No label changes needed.

📋 Detailed Analysis

Evidence

The issue occurs when a copilot user removes themselves (the current login) from the copilots list. PR #78785 modified the security settings page to allow copilots to remove themselves, which was the intended behavior. However, this exposed a timing/race condition in the automatic disconnect flow.

What Changed in PR #78785

The PR made several key changes to SecuritySettingsPage.tsx:

1. Line 313: Changed the condition from checking if user is acting as delegate to checking if the selected delegate email matches the current delegate AND is acting as delegate:

   // Before: if (isActingAsDelegate)
   // After: if (selectedDelegate?.email !== account?.delegatedAccess?.delegate && isActingAsDelegate)

   This allows the current copilot to remove themselves.

2. Lines 447-453: Removed the check in the onConfirm handler that prevented delegates from removing themselves:

   // REMOVED:
   if (isActingAsDelegate) {
       setShouldShowRemoveDelegateModal(false);
       showDelegateNoAccessModal();
       return;
   }

Verification

I confirmed that PR #78785 modified the following files that are directly related to the copilot removal flow:

• /home/runner/work/App/App/src/pages/settings/Security/SecuritySettingsPage.tsx - The page where copilots are managed
• /home/runner/work/App/App/src/pages/settings/Security/TwoFactorAuth/TwoFactorAuthWrapper.tsx - Access control wrapper
• /home/runner/work/App/App/src/pages/settings/Security/CloseAccountPage.tsx - Delegate access wrapper changes

Root Cause

When a copilot removes themselves:

1. removeDelegate() is called in SecuritySettingsPage.tsx:448
2. The API removes them from the delegates list
3. The useEffect in Expensify.tsx:341-349 detects the current delegate is no longer in the list
4. It automatically calls disconnect({stashedCredentials, stashedSession})
5. The disconnect() function in /home/runner/work/App/App/src/libs/actions/Delegate.ts:221-317:
   • Calls Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS) which clears most app state
   • Then restores session data via Onyx.set operations
   • Finally calls openApp()

However, during the Onyx clearing and restoration process, there is a timing window where the app has no valid session state. This causes the app to display the new member sign-up page and magic code authentication screen, even though the user already has an account and should be automatically logged back in.

The issue is that the automatic disconnect triggered by removeDelegate has a different timing/synchronization than the intentional disconnect flow (e.g., when using the Account Switcher), causing the race condition to manifest.

Why This is a Regression

The original issue #78105 that PR #78785 was fixing stated that "Full copilot is not able to remove their own copilot" was a bug. However, the fix did not account for the automatic disconnect behavior that is supposed to happen when a copilot removes themselves. The PR assumed that allowing the remove operation would work seamlessly, but it exposed this timing issue in the disconnect/session restoration flow.

The correct behavior (per the expected result in this issue) is:

• The copilot is successfully removed
• The app cleanly switches to the current user's existing account
• NO sign-up or authentication flow should be triggered

[ChavdaSachin]

This should not be coming from my PR, as PR just broaden the scope of self removal, it was already allowed for full access copilot and I extended it for limited access copilot.
So either it's some edge case which should be already present on production or this could be result of recent BE changes.
Even though I'd Investigate tomorrow.