The Wallet Settings page is displayed instead of the Settings menu after opening the "Add address" modal on the Home page on mobile web.

[m-natarajan]

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:
Reproducible in staging?: Y
Reproducible in production?: N
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: @dmkt9
Slack conversation (hyperlinked to channel name): #Open source

Action Performed:

Prerequisite: The user is assigned a physical Expensify card and has not yet entered their personal information.

1. Open the application on a mobile device (or in a narrow layout).
2. On the Home screen, tap the "Add address" button.
3. Tap back twice.
4. Tap "Settings" on the tab navigation bar.
5. Note that the Settings menu displays.
6. Tap "Home" on the tab navigation bar.
7. Tap "Settings" on the tab navigation bar again.
   8 Note that the Wallet Settings page is displayed.

Expected Result:

The Settings menu should be displayed.

Actual Result:

The Wallet Settings page is displayed.

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

2026-04-27.22-00-59.mp4

trim.FB4B4DB0-25C7-4DCA-BFFE-193B2E0E71D1.MOV

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @rlinoz (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: #85234 - "Introduce a Bottom Tab Navigator for Top-Level Navigation" by @WojtekBoman (High confidence)
Related Issues: None identified

Recommendation: REVERT

PR #85234 introduced a fundamental navigation architecture change. The bug is a direct consequence of how the new @react-navigation/bottom-tabs-based TabNavigator manages tab state persistence. Reverting this large PR is complex (84 files changed, major architecture refactor), so a roll-forward fix may be more appropriate in practice — but the default recommendation is REVERT unless the team determines a targeted fix is faster.

Assigned: @WojtekBoman (PR author), @ZhenjaHorbach (approving reviewer), @mountiny (approving reviewer)
Labels: DeployBlockerCash is kept (App PR caused the issue). No label changes made.

Details

Evidence

• The bug is staging-only (not reproducible in production), consistent with being introduced by a PR in the current staging deploy.
• The bug is a navigation issue: after opening the "Add address" modal on the Home screen (which navigates to ROUTES.SETTINGS_WALLET_DOMAIN_CARD), tapping back twice, and then tapping the Settings tab, the user sees the Wallet Settings page (SETTINGS.WALLET.ROOT) instead of the top-level Settings menu (SETTINGS.ROOT).
• PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 "Introduce a Bottom Tab Navigator for Top-Level Navigation" was merged on 2026-04-24 and is present in the current staging deploy. It is a large navigation refactor (84 files changed) that replaces individual root stack screens with a proper @react-navigation/bottom-tabs-based TabNavigator.
• The reproduction steps involve the AddShippingAddress component at /home/runner/_work/App/App/src/pages/home/TimeSensitiveSection/items/AddShippingAddress.tsx, which calls Navigation.navigate(ROUTES.SETTINGS_WALLET_DOMAIN_CARD.getRoute(...)).

Verification

• Affected files: src/libs/Navigation/AppNavigator/Navigators/TabNavigator.tsx, src/libs/Navigation/AppNavigator/Navigators/SettingsSplitNavigator.tsx, src/libs/Navigation/AppNavigator/Navigators/TabNavigatorBar.tsx
• PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 directly modifies all three of these files, as well as the entire navigation architecture.
• The AddShippingAddress component navigates to ROUTES.SETTINGS_WALLET_DOMAIN_CARD, which is linked (via SETTINGS_TO_RHP.ts) to SCREENS.SETTINGS.WALLET.ROOT as its entry/context screen, causing the SETTINGS_SPLIT_NAVIGATOR tab to have WALLET.ROOT as its active screen.

Root Cause

Before PR #85234, full-screen navigators (SettingsSplitNavigator, etc.) were individual screens registered directly in the root stack. Every "tab switch" was a regular stack navigation that pushed a new navigator instance. There was no persistent tab state.

After PR #85234, a real @react-navigation/bottom-tabs TabNavigator is used with freezeOnBlur: true. This means each tab's internal navigation state is preserved when the user switches away. When the user taps "Add address" on the Home screen, the app navigates to the Wallet domain card route, which causes the SETTINGS_SPLIT_NAVIGATOR tab to be activated with SETTINGS.WALLET.ROOT as its focused screen. When the user taps back (returning to Home), the Settings tab's state is frozen with WALLET.ROOT still active. The next time the user taps the Settings tab, the bottom tab navigator switches to SETTINGS_SPLIT_NAVIGATOR and restores the persisted state — showing WALLET.ROOT instead of the expected root Settings menu (SETTINGS.ROOT).

The fix should either: (1) reset the SETTINGS_SPLIT_NAVIGATOR tab state back to SETTINGS.ROOT when navigating back from a cross-tab Settings route, or (2) change the "Add address" navigation to not leave the Settings tab in a non-root state, or (3) ensure the Settings tab press always resets to the root settings screen when the tab is already showing a non-root screen.