[$250] iOS - Copilot - The removed copilot is not signed in to their original account

[jponikarchuk]

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.3.28-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #58538
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: iPhone 13 iOS 26.2.1
App Component: User Settings

Action Performed:

User A is a main account
User B is a copilot with full copilot access

Main account

1. Login as the main account
2. Navigate to Settings > Security
3. Remove Copilot access from one of the accounts
4. Verify the user is able to remove copilots from the account
   Copilot
5. Observe the User B account

Expected Result:

The User B will be signed out as copilot and signed in to their original account

Actual Result:

The removed copilit is not signed in to their original account

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @eh2077

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043663723288157853
• Upwork Job ID: 2043663723288157853
• Last Price Increase: 2026-04-27

[MelvinBot]

Proposal

What is the root cause of that problem?

When a copilot's access is removed, there are two paths that return the copilot to their own account:

1. Pusher path (primary): DelegateAccessHandler (src/DelegateAccessHandler.tsx:31-40) detects the removal via an Onyx update and calls disconnect(), which calls HybridAppModule.switchAccount() on iOS HybridApp (src/libs/actions/Delegate.ts:314).

2. Token expiration fallback: When the copilot's restricted delegate token is invalidated, the next API call returns 407. The Reauthentication middleware (src/libs/Authentication.ts:199) detects the delegate state and calls restoreDelegateSession() (src/libs/actions/Delegate.ts:700-711).

The bug: restoreDelegateSession() does not call HybridAppModule.switchAccount(), while disconnect() does. On iOS HybridApp, if the fallback path (Path 2) fires — either because the Pusher update doesn't arrive in time or at all — the NewDot side restores the session but the native OldDot layer is never notified of the account switch. This leaves the copilot in a broken state where they are not properly signed back into their original account.

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

Add the HybridAppModule.switchAccount() call to restoreDelegateSession() in src/libs/actions/Delegate.ts, matching what disconnect() already does at line 314. After restoring the session and calling openApp(), check CONFIG.IS_HYBRID_APP and call HybridAppModule.switchAccount() with the restored account's email, authToken, and accountID.

What alternative solutions did you explore? (Optional)

An alternative would be to ensure the Pusher path (Path 1) always fires reliably so the fallback is never needed. However, Pusher delivery is inherently best-effort (network issues, app backgrounding on iOS, etc.), so hardening the fallback path is the more robust fix. Both paths should produce identical behavior on HybridApp.

Investigation details

Evidence chain:

• disconnect() at Delegate.ts:310-321 calls openApp().then(() => HybridAppModule.switchAccount(...)) — this is the correct iOS HybridApp behavior
• restoreDelegateSession() at Delegate.ts:700-711 calls confirmReadyToOpenApp() and openApp() but never calls HybridAppModule.switchAccount() — iOS native layer is not notified
• The bug is iOS-only (as reported), consistent with HybridApp being the iOS-specific integration layer
• connect() at Delegate.ts:206-216 also calls HybridAppModule.switchAccount() when connecting as delegate, confirming that both connect and disconnect are expected to notify the native layer

Why the fallback path fires:
When the copilot is acting as a delegate, the Pusher channel may be tied to the delegator's account. After removal, if the server invalidates the restricted token before the Pusher update arrives (or if the app was backgrounded), the next API call triggers 407 → reauthentication → restoreDelegateSession() instead of the DelegateAccessHandler → disconnect() path.

---

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 - @eh2077 (External)