[Due for payment 2026-05-26] [$250] Web - Tags - User is navigated to "Inbox" on background after updating URL to "Settings"

[lanitochka17]

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.69-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #89582
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

Prerequisite: Account has a workspace with "Tags" enabled.

1. Open the staging.new.expensify.com website.
2. Navigate to "Workspaces" > "Tags"
3. Update the URL from: https://staging.new.expensify.com:8082/workspaces/74F19F3521623397/tags to:
   https://staging.new.expensify.com:8082/settings/74F19F3521623397/tags
4. Note that when "Tag" RHP opens, user is redirected to "Inbox" on the background.

Expected Result:

User should remain on the same page on the background when changing URL to "Settings" while on "Tags" page.

Actual Result:

User is navigated to "Inbox" on background when updating URL to "Settings" while on "Tags" page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7148601_1778262039363.Tag.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022052863128295123378
• Upwork Job ID: 2052863128295123378
• Last Price Increase: 2026-05-15

Issue Owner

Current Issue Owner: @ShridharGoel

[MelvinBot]

Proposal

What is the root cause of that problem?

When navigating to /settings/{policyID}/tags, React Navigation matches it to the SETTINGS_TAGS_ROOT screen inside RIGHT_MODAL_NAVIGATOR > RIGHT_MODAL.MONEY_REQUEST. This correctly opens the Tags RHP, but since SETTINGS_TAGS_ROOT is not registered in any of the RELATIONS maps (checked all of SETTINGS_TO_RHP, WORKSPACE_TO_RHP, HOME_TO_RHP, SEARCH_TO_RHP, SIDEBAR_TO_RHP, DOMAIN_TO_RHP, WORKSPACES_LIST_TO_RHP), getMatchingFullScreenRoute returns undefined.

This causes the fallback at getAdaptedStateFromPath.ts:372 to kick in, which prepends REPORTS_SPLIT_NAVIGATOR (Inbox) as the background page:

if (isRightModalNavigator) {
    return getRoutesWithIndex([getTabNavigatorState({name: NAVIGATORS.REPORTS_SPLIT_NAVIGATOR}), ...currentState.routes]);
}

By contrast, the correct URL /workspaces/{policyID}/tags maps to SCREENS.WORKSPACE.TAGS inside WORKSPACE_SPLIT_NAVIGATOR — a central pane screen that doesn't need the RHP fallback path at all, so the workspace background is preserved.

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

Add the SETTINGS_TAGS screens to the appropriate RELATIONS map so that getMatchingFullScreenRoute can resolve the correct background page (the workspace split navigator) instead of falling through to the Inbox default.

Specifically, add entries for the SETTINGS_TAGS screens (e.g., SETTINGS_TAGS_ROOT, SETTINGS_TAGS_EDIT, etc.) to WORKSPACE_TO_RHP.ts under the SCREENS.WORKSPACE.TAGS key, similar to how other workspace RHP screens are mapped. This would tell the navigation system to show the workspace Tags central pane as the background when the settings tags RHP is open.

What alternative solutions did you explore? (Optional)

An alternative would be to add a redirect in OldRoutes.ts from /settings/{policyID}/tags to /workspaces/{policyID}/tags. However, this would mask the navigation gap rather than fixing it, and other code paths that legitimately open SETTINGS_TAGS_ROOT as an RHP would still lack a proper background mapping.

---

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

[MobileMage]

Proposal

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

When a user manually edits the browser URL from workspaces/:policyID/tags to settings/:policyID/tags, the Tags RHP opens correctly but the background page unexpectedly changes to Inbox instead of remaining on whatever page the user was already on.

What is the root cause of that problem?

The route settings/:policyID/tags is registered in the linking config under RIGHT_MODAL.MONEY_REQUEST's screens block instead of under RIGHT_MODAL.SETTINGS_TAGS. Both SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT and its sibling SCREENS.SETTINGS_CATEGORIES.SETTINGS_CATEGORIES_ROOT are misplaced inside the MONEY_REQUEST navigator section around line 1714–1715 of config.ts:

App/src/libs/Navigation/linkingConfig/config.ts

Lines 1714 to 1715 in 50ece39

	[SCREENS.SETTINGS_CATEGORIES.SETTINGS_CATEGORIES_ROOT]: ROUTES.SETTINGS_CATEGORIES_ROOT.route,
	[SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT]: ROUTES.SETTINGS_TAGS_ROOT.route,

Because SETTINGS_TAGS_ROOT is under MONEY_REQUEST rather than SETTINGS_TAGS, the navigation adapter in getAdaptedStateFromPath.ts treats it as a MONEY_REQUEST RHP screen. When getMatchingFullScreenRoute is called for SETTINGS_TAGS_ROOT, it finds no entry in RHP_TO_WORKSPACE (which is derived from WORKSPACE_TO_RHP.ts) and no other relation map. With no matching full-screen background route resolved, the isRightModalNavigator fallback in getAdaptedState kicks in and prepends REPORTS_SPLIT_NAVIGATOR (Inbox) as the background.

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 369 to 373 in 50ece39

	const isRightModalNavigator = currentState.routes.find((route) => route.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR);
	if (isRightModalNavigator) {
	return getRoutesWithIndex([getTabNavigatorState({name: NAVIGATORS.REPORTS_SPLIT_NAVIGATOR}), ...currentState.routes]);
	}

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

Two changes are needed:

First, move SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT (with path ROUTES.SETTINGS_TAGS_ROOT.route) out of the RIGHT_MODAL.MONEY_REQUEST screens block in src/libs/Navigation/linkingConfig/config.ts and add it as an entry inside the RIGHT_MODAL.SETTINGS_TAGS screens block, alongside the existing SETTINGS_TAGS_SETTINGS, SETTINGS_TAGS_IMPORT, and other sub-screens already registered there. The same fix should be applied to SCREENS.SETTINGS_CATEGORIES.SETTINGS_CATEGORIES_ROOT which has the identical misplacement.

Second, add SCREENS.WORKSPACE.TAGS as a key in WORKSPACE_TO_RHP.ts — or more precisely, add SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT to the relation for SCREENS.WORKSPACE.TAGS — so that RHP_TO_WORKSPACE contains a mapping for SETTINGS_TAGS_ROOT. This tells getMatchingFullScreenRoute to show the workspace tags split navigator in the background instead of falling back to Inbox. The WORKSPACE_TO_RHP.ts file already has SCREENS.WORKSPACE.TAGS mapped to an array of its sub-screens; SETTINGS_TAGS_ROOT should be added to that array so the background is correctly resolved to the workspace tags page.

What alternative solutions did you explore? (Optional)

An alternative would be to add a RHP_TO_WORKSPACE mapping directly without moving the route registration, but that would leave the route misregistered under the wrong navigator. Moving it to RIGHT_MODAL.SETTINGS_TAGS and adding the workspace relation is the correct structural fix since it puts the route in the navigator it actually belongs to and gives the navigation adapter the context it needs to resolve the proper background screen.

[melvin-bot]

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

[Abdulloh0109]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

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

[KJ21-ENG]

Proposal

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

When the user is already on Workspace > Tags and manually changes the URL from /workspaces/:policyID/tags to /settings/:policyID/tags, the tags page opens as an RHP, but the page behind it changes to Inbox instead of staying on the workspace Tags page.

What is the root cause of that problem?

/settings/:policyID/tags is still treated as the quick-settings tags root route:

App/src/ROUTES.ts

Lines 1600 to 1608 in 50ece39

	SETTINGS_TAGS_ROOT: {
	route: 'settings/:policyID/tags',
	getRoute: (policyID: string | undefined, backTo = '') => {
	if (!policyID) {
	Log.warn('Invalid policyID while building route SETTINGS_TAGS_ROOT');
	}
	// eslint-disable-next-line no-restricted-syntax -- Legacy route generation
	return getUrlWithBackToParam(`settings/${policyID}/tags`, backTo);

However, that root screen is registered under the money request modal stack in both the component map and linking config:

App/src/libs/Navigation/AppNavigator/ModalStackNavigators/index.tsx

Lines 185 to 203 in 50ece39

	const MoneyRequestModalStackNavigator = createModalStackNavigator<MoneyRequestNavigatorParamList>({
	[SCREENS.MONEY_REQUEST.START]: () => require<ReactComponentModule>('../../../../pages/iou/request/IOURequestRedirectToStartPage').default,
	[SCREENS.MONEY_REQUEST.CREATE]: () => require<ReactComponentModule>('../../../../pages/iou/request/IOURequestStartPage').default,
	[SCREENS.MONEY_REQUEST.CREATE_VERIFY_ACCOUNT]: () => require<ReactComponentModule>('../../../../pages/iou/request/MoneyRequestCreateVerifyAccountPage').default,
	[SCREENS.MONEY_REQUEST.STEP_CONFIRMATION]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepConfirmation').default,
	[SCREENS.MONEY_REQUEST.STEP_CONFIRMATION_VERIFY_ACCOUNT]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/MoneyRequestStepConfirmationVerifyAccountPage').default,
	[SCREENS.MONEY_REQUEST.STEP_AMOUNT]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepAmount').default,
	[SCREENS.MONEY_REQUEST.STEP_TAX_AMOUNT]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepTaxAmountPage').default,
	[SCREENS.MONEY_REQUEST.STEP_TAX_RATE]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepTaxRatePage').default,
	[SCREENS.MONEY_REQUEST.STEP_CATEGORY]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepCategory').default,
	[SCREENS.MONEY_REQUEST.STEP_CATEGORY_CREATE]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepCategoryCreate').default,
	[SCREENS.MONEY_REQUEST.STEP_DATE]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepDate').default,
	[SCREENS.MONEY_REQUEST.STEP_DESCRIPTION]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepDescription').default,
	[SCREENS.MONEY_REQUEST.STEP_DISTANCE]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepDistance').default,
	[SCREENS.MONEY_REQUEST.STEP_DISTANCE_RATE]: () => require<ReactComponentModule>('@pages/iou/request/step/IOURequestStepDistanceRate').default,
	[SCREENS.MONEY_REQUEST.STEP_MERCHANT]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepMerchant').default,
	[SCREENS.MONEY_REQUEST.STEP_PARTICIPANTS]: () => require<ReactComponentModule>('../../../../pages/iou/request/step/IOURequestStepParticipants').default,
	[SCREENS.SETTINGS_CATEGORIES.SETTINGS_CATEGORIES_ROOT]: () => require<ReactComponentModule>('../../../../pages/workspace/categories/WorkspaceCategoriesPage').default,
	[SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/WorkspaceTagsPage').default,

App/src/libs/Navigation/linkingConfig/config.ts

Lines 1666 to 1715 in 50ece39

	[SCREENS.RIGHT_MODAL.MONEY_REQUEST]: {
	screens: {
	[SCREENS.MONEY_REQUEST.START]: ROUTES.MONEY_REQUEST_START.route,
	[SCREENS.MONEY_REQUEST.CREATE]: {
	path: ROUTES.MONEY_REQUEST_CREATE.route,
	exact: true,
	screens: {
	distance: {
	path: ROUTES.MONEY_REQUEST_CREATE_TAB_DISTANCE.route,
	},
	manual: {
	path: ROUTES.MONEY_REQUEST_CREATE_TAB_MANUAL.route,
	},
	scan: {
	path: ROUTES.MONEY_REQUEST_CREATE_TAB_SCAN.route,
	},
	// eslint-disable-next-line @typescript-eslint/naming-convention
	'per-diem': {
	path: ROUTES.MONEY_REQUEST_CREATE_TAB_PER_DIEM.route,
	},
	time: {
	path: ROUTES.MONEY_REQUEST_CREATE_TAB_TIME.route,
	},
	},
	},
	[SCREENS.MONEY_REQUEST.CREATE_VERIFY_ACCOUNT]: ROUTES.MONEY_REQUEST_CREATE_VERIFY_ACCOUNT.route,
	[SCREENS.MONEY_REQUEST.DISTANCE_CREATE]: {
	path: ROUTES.DISTANCE_REQUEST_CREATE.route,
	exact: true,
	screens: {
	// eslint-disable-next-line @typescript-eslint/naming-convention
	'distance-map': {
	path: ROUTES.DISTANCE_REQUEST_CREATE_TAB_MAP.route,
	},
	// eslint-disable-next-line @typescript-eslint/naming-convention
	'distance-manual': {
	path: ROUTES.DISTANCE_REQUEST_CREATE_TAB_MANUAL.route,
	},
	// eslint-disable-next-line @typescript-eslint/naming-convention
	'distance-gps': {
	path: ROUTES.DISTANCE_REQUEST_CREATE_TAB_GPS.route,
	},
	// eslint-disable-next-line @typescript-eslint/naming-convention
	'distance-odometer': {
	path: ROUTES.DISTANCE_REQUEST_CREATE_TAB_ODOMETER.route,
	},
	},
	},
	[SCREENS.SETTINGS_CATEGORIES.SETTINGS_CATEGORIES_ROOT]: ROUTES.SETTINGS_CATEGORIES_ROOT.route,
	[SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT]: ROUTES.SETTINGS_TAGS_ROOT.route,

The dedicated Settings Tags RHP stack contains the child tags routes, but not SETTINGS_TAGS_ROOT:

App/src/libs/Navigation/AppNavigator/ModalStackNavigators/index.tsx

Lines 348 to 360 in 50ece39

	const TagsModalStackNavigator = createModalStackNavigator({
	[SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_SETTINGS]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/WorkspaceTagsSettingsPage').default,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAGS_EDIT]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/WorkspaceEditTagsPage').default,
	[SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_IMPORT]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/ImportTagsPage').default,
	[SCREENS.WORKSPACE.TAGS_IMPORT_OPTIONS]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/ImportTagsOptionsPage').default,
	[SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_IMPORTED]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/ImportedTagsPage').default,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_SETTINGS]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/TagSettingsPage').default,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_LIST_VIEW]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/WorkspaceViewTagsPage').default,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_CREATE]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/WorkspaceCreateTagPage').default,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_EDIT]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/EditTagPage').default,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_APPROVER]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/TagApproverPage').default,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_GL_CODE]: () => require<ReactComponentModule>('../../../../pages/workspace/tags/TagGLCodePage').default,
	});

App/src/libs/Navigation/linkingConfig/config.ts

Lines 1521 to 1539 in 50ece39

	[SCREENS.RIGHT_MODAL.SETTINGS_TAGS]: {
	screens: {
	[SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_SETTINGS]: {
	path: ROUTES.SETTINGS_TAGS_SETTINGS.route,
	},
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAGS_EDIT]: DYNAMIC_ROUTES.SETTINGS_TAGS_EDIT.path,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_CREATE]: DYNAMIC_ROUTES.SETTINGS_TAG_CREATE.path,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_EDIT]: DYNAMIC_ROUTES.SETTINGS_TAG_EDIT.path,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_SETTINGS]: DYNAMIC_ROUTES.SETTINGS_TAG_SETTINGS.path,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_APPROVER]: DYNAMIC_ROUTES.SETTINGS_TAG_APPROVER.path,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_LIST_VIEW]: DYNAMIC_ROUTES.SETTINGS_TAG_LIST_VIEW.path,
	[SCREENS.SETTINGS_TAGS.DYNAMIC_SETTINGS_TAG_GL_CODE]: DYNAMIC_ROUTES.SETTINGS_TAG_GL_CODE.path,
	[SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_IMPORT]: {
	path: ROUTES.SETTINGS_TAGS_IMPORT.route,
	},
	[SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_IMPORTED]: {
	path: ROUTES.SETTINGS_TAGS_IMPORTED.route,
	},
	},

Also, the workspace Tags central screen only maps to the SCREENS.WORKSPACE.* tags RHP screens. It does not include SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT, so RHP_TO_WORKSPACE has no way to infer that the /settings/:policyID/tags RHP should sit over SCREENS.WORKSPACE.TAGS:

App/src/libs/Navigation/linkingConfig/RELATIONS/WORKSPACE_TO_RHP.ts

Lines 184 to 198 in 50ece39

	[SCREENS.WORKSPACE.TAGS]: [
	SCREENS.WORKSPACE.TAGS_SETTINGS,
	SCREENS.WORKSPACE.TAGS_EDIT,
	SCREENS.WORKSPACE.TAG_CREATE,
	SCREENS.WORKSPACE.TAG_SETTINGS,
	SCREENS.WORKSPACE.TAG_EDIT,
	SCREENS.WORKSPACE.TAG_LIST_VIEW,
	SCREENS.WORKSPACE.TAG_GL_CODE,
	SCREENS.WORKSPACE.TAG_APPROVER,
	SCREENS.WORKSPACE.TAGS_IMPORT,
	SCREENS.WORKSPACE.TAGS_IMPORT_OPTIONS,
	SCREENS.WORKSPACE.TAGS_IMPORTED,
	SCREENS.WORKSPACE.TAGS_IMPORTED_MULTI_LEVEL,
	SCREENS.WORKSPACE.TAGS_IMPORT_MULTI_LEVEL_SETTINGS,
	],

When getAdaptedStateFromPath() adapts an RHP route, it first tries RHP_TO_WORKSPACE to build the workspace split background:

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 170 to 187 in 50ece39

	if (RHP_TO_WORKSPACE[route.name]) {
	const paramsFromRoute = getParamsFromRoute(RHP_TO_WORKSPACE[route.name]);
	const workspaceSplitRoute = getInitialSplitNavigatorState(
	{
	name: SCREENS.WORKSPACE.INITIAL,
	params: paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : undefined,
	},
	{
	name: RHP_TO_WORKSPACE[route.name],
	params: paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : undefined,
	},
	);
	return getTabNavigatorState({
	name: NAVIGATORS.WORKSPACE_NAVIGATOR,
	state: getRoutesWithIndex([{name: SCREENS.WORKSPACES_LIST}, workspaceSplitRoute]),
	});

Because the settings tags root has no relation, the generic RHP fallback runs and prepends the reports split navigator, which is why Inbox appears behind the tags RHP:

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 369 to 372 in 50ece39

	const isRightModalNavigator = currentState.routes.find((route) => route.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR);
	if (isRightModalNavigator) {
	return getRoutesWithIndex([getTabNavigatorState({name: NAVIGATORS.REPORTS_SPLIT_NAVIGATOR}), ...currentState.routes]);

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

Move the quick-settings tags root route into the Settings Tags RHP stack and give it the same workspace background relation as the rest of the tags RHP flow:

1. In src/libs/Navigation/AppNavigator/ModalStackNavigators/index.tsx, move SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT from MoneyRequestModalStackNavigator into TagsModalStackNavigator, using the existing WorkspaceTagsPage component.
2. In src/libs/Navigation/linkingConfig/config.ts, move the ROUTES.SETTINGS_TAGS_ROOT.route entry from SCREENS.RIGHT_MODAL.MONEY_REQUEST into SCREENS.RIGHT_MODAL.SETTINGS_TAGS.
3. In src/libs/Navigation/linkingConfig/RELATIONS/WORKSPACE_TO_RHP.ts, add SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT to the SCREENS.WORKSPACE.TAGS relation so RHP_TO_WORKSPACE[Settings_Tags] resolves to Workspace_Tags.
4. Add a navigation regression test for /settings/p123/tags that asserts the adapted state uses the workspace navigator with SCREENS.WORKSPACE.TAGS behind the RHP, not NAVIGATORS.REPORTS_SPLIT_NAVIGATOR.

Scope boundaries:

• Files touched: src/libs/Navigation/AppNavigator/ModalStackNavigators/index.tsx — MoneyRequestModalStackNavigator and TagsModalStackNavigator; src/libs/Navigation/linkingConfig/config.ts — SCREENS.RIGHT_MODAL.MONEY_REQUEST and SCREENS.RIGHT_MODAL.SETTINGS_TAGS; src/libs/Navigation/linkingConfig/RELATIONS/WORKSPACE_TO_RHP.ts — SCREENS.WORKSPACE.TAGS; navigation tests — add one /settings/:policyID/tags state assertion.
• Platforms: web route handling, with shared navigation config also affecting any platform that opens this URL.
• Code paths / callers explicitly NOT touched: tag CRUD actions, Onyx policy tag data, workspace tags UI rendering, settings categories routes, and dynamic child tag routes such as tag-settings, tag-new, and tag-list.
• API contracts or backend behavior changes: no.

What alternative solutions did you explore? (Optional)

I considered changing WorkspaceTagsPage to navigate back to /workspaces/:policyID/tags when isQuickSettingsFlow is true, but that would only patch this page after the wrong navigation state has already been created. The route adapter is the boundary that chooses the background screen for RHP URLs, so the fix should keep the quick-settings tags route registered in the correct RHP stack and add the missing WORKSPACE_TO_RHP relation.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The URL /settings/:policyID/tags resolves to the RHP screen Settings_Tags (SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT), introduced as the "Quick Settings" tags flow by the recent migration in #89582. When you change the URL while already on /workspaces/:policyID/tags, React Navigation re-runs getAdaptedStateFromPath against the new path from scratch — the previous full-screen state is not preserved, so the navigator must inject a background full-screen for the RHP itself.

That injection happens in getMatchingFullScreenRoute, which walks RHP_TO_SEARCH / RHP_TO_HOME / RHP_TO_WORKSPACES_LIST / RHP_TO_WORKSPACE / RHP_TO_SETTINGS / RHP_TO_DOMAIN / RHP_TO_SIDEBAR looking for the focused RHP screen name:

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 97 to 230 in 50ece39

	function getMatchingFullScreenRoute(route: NavigationPartialRoute) {
	const isDynamicScreen = isDynamicRouteScreen(route.name as Screen);
	// Check for backTo param. One screen with different backTo value may need different screens visible under the overlay.
	// Dynamic screens are skipped here because they never carry their own backTo - they only
	// inherit it from the screen underneath. Letting backTo dictate the full-screen route for
	// a dynamic screen would resolve the wrong page.
	if (isRouteWithBackToParam(route) && !isDynamicScreen) {
	const stateForBackTo = getStateFromPath(route.params.backTo as RoutePath);
	// This may happen if the backTo url is invalid.
	const lastRoute = stateForBackTo?.routes.at(-1);
	if (!stateForBackTo || !lastRoute || lastRoute.name === SCREENS.NOT_FOUND) {
	return undefined;
	}
	const isLastRouteFullScreen = isFullScreenName(lastRoute.name);
	// If the state for back to last route is a full screen route, we can use it
	if (isLastRouteFullScreen) {
	return lastRoute;
	}
	const focusedStateForBackToRoute = findFocusedRouteWithOnyxTabGuard(stateForBackTo);
	if (!focusedStateForBackToRoute) {
	return undefined;
	}
	// If not, get the matching full screen route for the back to state.
	return getMatchingFullScreenRoute(focusedStateForBackToRoute);
	}
	const routeNameForLookup = getSearchScreenNameForRoute(route);
	if (RHP_TO_SEARCH[routeNameForLookup]) {
	const paramsFromRoute = getParamsFromRoute(RHP_TO_SEARCH[routeNameForLookup]);
	const copiedParams = paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : {};
	let queryParam: Record<string, string> = {};
	if (route.path) {
	const query = getSearchParamFromPath(route.path, 'q');
	if (query) {
	queryParam = {q: query};
	}
	}
	const searchRoute = {
	name: RHP_TO_SEARCH[routeNameForLookup],
	params: Object.keys({...copiedParams, ...queryParam}).length > 0 ? {...copiedParams, ...queryParam} : undefined,
	};
	const searchState = getRoutesWithIndex([searchRoute]);
	return getTabNavigatorState({name: NAVIGATORS.SEARCH_FULLSCREEN_NAVIGATOR, state: searchState});
	}
	if (RHP_TO_HOME[route.name]) {
	return {
	...getTabNavigatorState({name: SCREENS.HOME}),
	path: normalizePath(ROUTES.HOME),
	};
	}
	if (RHP_TO_WORKSPACES_LIST[route.name]) {
	return getTabNavigatorState({
	name: NAVIGATORS.WORKSPACE_NAVIGATOR,
	state: getRoutesWithIndex([
	{
	name: SCREENS.WORKSPACES_LIST,
	// prepending a slash to ensure closing the RHP after refreshing the page
	// replaces the whole path with "/workspaces", instead of just replacing the last url segment ("/x/y/workspaces")
	path: normalizePath(ROUTES.WORKSPACES_LIST.route),
	},
	]),
	});
	}
	if (RHP_TO_WORKSPACE[route.name]) {
	const paramsFromRoute = getParamsFromRoute(RHP_TO_WORKSPACE[route.name]);
	const workspaceSplitRoute = getInitialSplitNavigatorState(
	{
	name: SCREENS.WORKSPACE.INITIAL,
	params: paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : undefined,
	},
	{
	name: RHP_TO_WORKSPACE[route.name],
	params: paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : undefined,
	},
	);
	return getTabNavigatorState({
	name: NAVIGATORS.WORKSPACE_NAVIGATOR,
	state: getRoutesWithIndex([{name: SCREENS.WORKSPACES_LIST}, workspaceSplitRoute]),
	});
	}
	if (RHP_TO_SETTINGS[route.name]) {
	const paramsFromRoute = getParamsFromRoute(RHP_TO_SETTINGS[route.name]);
	const settingsState = getInitialSplitNavigatorState(
	{name: SCREENS.SETTINGS.ROOT},
	{
	name: RHP_TO_SETTINGS[route.name],
	params: paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : undefined,
	},
	);
	return getTabNavigatorState(settingsState);
	}
	if (RHP_TO_DOMAIN[route.name]) {
	const paramsFromRoute = getParamsFromRoute(RHP_TO_DOMAIN[route.name]);
	const domainSplitRoute = getInitialSplitNavigatorState(
	{
	name: SCREENS.DOMAIN.INITIAL,
	params: paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : undefined,
	},
	{
	name: RHP_TO_DOMAIN[route.name],
	params: paramsFromRoute.length > 0 ? pick(route.params, paramsFromRoute) : undefined,
	},
	);
	return getTabNavigatorState({
	name: NAVIGATORS.WORKSPACE_NAVIGATOR,
	state: getRoutesWithIndex([{name: SCREENS.WORKSPACES_LIST}, domainSplitRoute]),
	});
	}
	// Fallback: if no specific central screen RELATION matched, check if the RHP screen
	// maps to a sidebar. This shows the split navigator with just the sidebar (no central screen).
	if (RHP_TO_SIDEBAR[route.name]) {
	const splitState = getInitialSplitNavigatorState({
	name: RHP_TO_SIDEBAR[route.name],
	});
	return getTabNavigatorState(splitState);
	}

Settings_Tags (and its sibling Settings_Categories) is not present in any of those relation files — SETTINGS_TO_RHP covers the user-settings split navigator only, and the Quick-Settings entries were never added to WORKSPACE_TO_RHP next to the existing Workspace_Tags / Workspace_Categories mappings:

App/src/libs/Navigation/linkingConfig/RELATIONS/WORKSPACE_TO_RHP.ts

Lines 184 to 215 in 50ece39

	[SCREENS.WORKSPACE.TAGS]: [
	SCREENS.WORKSPACE.TAGS_SETTINGS,
	SCREENS.WORKSPACE.TAGS_EDIT,
	SCREENS.WORKSPACE.TAG_CREATE,
	SCREENS.WORKSPACE.TAG_SETTINGS,
	SCREENS.WORKSPACE.TAG_EDIT,
	SCREENS.WORKSPACE.TAG_LIST_VIEW,
	SCREENS.WORKSPACE.TAG_GL_CODE,
	SCREENS.WORKSPACE.TAG_APPROVER,
	SCREENS.WORKSPACE.TAGS_IMPORT,
	SCREENS.WORKSPACE.TAGS_IMPORT_OPTIONS,
	SCREENS.WORKSPACE.TAGS_IMPORTED,
	SCREENS.WORKSPACE.TAGS_IMPORTED_MULTI_LEVEL,
	SCREENS.WORKSPACE.TAGS_IMPORT_MULTI_LEVEL_SETTINGS,
	],
	[SCREENS.WORKSPACE.CATEGORIES]: [
	SCREENS.WORKSPACE.DYNAMIC_CATEGORY_CREATE,
	SCREENS.WORKSPACE.CATEGORY_SETTINGS,
	SCREENS.WORKSPACE.DYNAMIC_CATEGORIES_IMPORT,
	SCREENS.WORKSPACE.DYNAMIC_CATEGORIES_IMPORTED,
	SCREENS.WORKSPACE.DYNAMIC_CATEGORIES_SETTINGS,
	SCREENS.WORKSPACE.CATEGORY_EDIT,
	SCREENS.WORKSPACE.CATEGORY_GL_CODE,
	SCREENS.WORKSPACE.CATEGORY_PAYROLL_CODE,
	SCREENS.WORKSPACE.CATEGORY_DEFAULT_TAX_RATE,
	SCREENS.WORKSPACE.CATEGORY_FLAG_AMOUNTS_OVER,
	SCREENS.WORKSPACE.CATEGORY_DESCRIPTION_HINT,
	SCREENS.WORKSPACE.CATEGORY_APPROVER,
	SCREENS.WORKSPACE.CATEGORY_REQUIRE_RECEIPTS_OVER,
	SCREENS.WORKSPACE.CATEGORY_REQUIRE_ITEMIZED_RECEIPTS_OVER,
	SCREENS.WORKSPACE.CATEGORY_REQUIRED_FIELDS,
	],

So getMatchingFullScreenRoute falls all the way through and returns undefined. getAdaptedState then falls back to getDefaultFullScreenRoute, which hard-codes the Home (Inbox) tab as the background:

App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

Lines 277 to 291 in 50ece39

	function getDefaultFullScreenRoute(route?: NavigationPartialRoute) {
	if (route && isRouteWithReportID(route)) {
	const reportID = route.params.reportID;
	// Only allReports should be checked here
	if (!getReportOrDraftReport(reportID, undefined, undefined, {})) {
	return getTabNavigatorState({name: NAVIGATORS.REPORTS_SPLIT_NAVIGATOR});
	}
	const reportsState = getInitialSplitNavigatorState({name: SCREENS.INBOX}, {name: SCREENS.REPORT, params: {reportID}});
	return getTabNavigatorState(reportsState);
	}
	return getTabNavigatorState({name: SCREENS.HOME});
	}

That is exactly what the user sees — the RHP opens correctly, but the central pane gets reset to Inbox because Settings_Tags has no relation to a full-screen route.

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

Register Settings_Tags and Settings_Categories under their workspace full-screen counterparts in WORKSPACE_TO_RHP.ts. They share the same component and the same workspace context as Workspace_Tags / Workspace_Categories, so those are the correct backgrounds (closing the RHP also lands the user back on the workspace page, matching the expected behaviour):

     [SCREENS.WORKSPACE.TAGS]: [
+        SCREENS.SETTINGS_TAGS.SETTINGS_TAGS_ROOT,
         SCREENS.WORKSPACE.TAGS_SETTINGS,
         SCREENS.WORKSPACE.TAGS_EDIT,
         SCREENS.WORKSPACE.TAG_CREATE,
         ...
     ],
     [SCREENS.WORKSPACE.CATEGORIES]: [
+        SCREENS.SETTINGS_CATEGORIES.SETTINGS_CATEGORIES_ROOT,
         SCREENS.WORKSPACE.DYNAMIC_CATEGORY_CREATE,
         SCREENS.WORKSPACE.CATEGORY_SETTINGS,
         ...
     ],

After this, getMatchingFullScreenRoute resolves Settings_Tags → Workspace_Tags via RHP_TO_WORKSPACE, takes the existing branch at lines 170–188 of getAdaptedStateFromPath.ts, and the workspace navigator (with the tags page as the central screen) is injected as the background — no more redirect to Inbox. The same applies to the analogous /settings/:policyID/categories route, which has the identical defect.

What alternative solutions did you explore? (Optional)

1. Add the mapping to SETTINGS_TO_RHP instead. Rejected — that file is for the user settings split navigator (Profile / Preferences / Wallet / Security…), and the workspace-scoped tag/category pages don't live there. Putting them in SETTINGS_TO_RHP would inject Settings_Root (the user settings screen) as the background, which is wrong context and would also break the back-navigation from the RHP.

2. Make getDefaultFullScreenRoute policy-aware (return Workspace_Tags when the focused route has a policyID param). Rejected as too broad — the default-fallback is a last-resort safety net for any unmapped RHP, and special-casing policyID there would shadow the explicit relation files which are the intended source of truth. The relation file is the right place to encode this knowledge.

3. Pass an implicit backTo to WORKSPACE_TAGS when constructing the route. Rejected — that only works when the user reaches /settings/:policyID/tags through our internal Navigation.navigate calls; the bug is specifically about the URL being typed/pasted, where no backTo exists. The fix has to live in the path-to-state adapter, not at the call sites.