[Due for payment 2026-05-29] Agent - Not so far page opens on the first copilot into the agent account.

[applause-bot]

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.78-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: #90371
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 15.4.1 Safari/Chrome
App Component: User Settings

Action Performed:

1. Go to https://staging.new.expensify.com
2. Log in with expensifail account
3. Go to Account > Agents
4. Create a new agent
5. Click the Account icon and copilot into the agent account

Expected Result:

Not so far page should not appear on the first copilot into the agent account.

Actual Result:

Not so far page opens on the first copilot into the agent account.
The Agent section is hidden, but still on the first log in, the https://staging.new.expensify.com/settings/agents/ page opens.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7158400_1779239299598.Recording__2216.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7158400

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/ac03b97082a36240fcadb35a64eaf33d3fa8b4645ea8cfa7588bbfb5cffb1224

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #90371

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

[MelvinBot]

Proposal

What is the root cause of that problem?

When copiloting into an agent account, connect() clears Onyx data via clearOnyxForDelegateTransition() but does not reset the React Navigation state. The in-memory preservedNavigatorStates remain intact — only search navigator states are cleared (line 202).

If the user was viewing /settings/agents/ before switching, the SplitRouter restores AGENTS.ROOT from previousSelectedCentralScreen instead of falling back to the defaultCentralScreen (Profile). Since PR #90371 wrapped that screen with withAgentAccessDenied, the agent session email triggers DelegateNoAccessWrapper to render the "Not so fast..." page.

The sidebar correctly hides the Agents menu item for agent accounts (InitialSettingsPage.tsx:318), but the central pane still shows the stale route.

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

In Delegate.ts, clear all preserved navigator states (not just search) during connect() and disconnect(). This way the SplitRouter falls back to defaultCentralScreen (Profile) after the delegate transition, avoiding stale routes that are now access-denied.

Concretely: add and call a clearAllPreservedNavigatorStates() function in usePreserveNavigatorState.ts that empties the entire preservedNavigatorStates record. Call it in connect() and disconnect() in place of (or in addition to) clearPreservedSearchNavigatorStates().

What alternative solutions did you explore?

An alternative would be to navigate explicitly to /settings/profile after the delegate transition completes. However, clearing all preserved states is more robust — it prevents any stale route from persisting across account switches, not just the agents route.

---

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.

[NicolasBonet]

This isn't a bug, this is intended:

it actually works? The idea is you cannot see the agents page anymore, so this is intended, we could redirect to the agent profile if the page isn't accessible or something else but the functionality isn't broken it might need polishing tho.

This is also behind a beta, so not a blocker