Keep copilot sessions signed in across a transition link

[adhorodyski]

Explanation of Change

isLoggingInAsNewUser decides whether a transition link carries a different person than the one already signed in. It compares the email and delegatorEmail params of the link against the session email. Both callers of that decision, LogOutPreviousUserPage and AuthScreensInitHandler, sign the current session out when it returns true.

A copilot session is keyed to the account being worked on. session.email holds the delegator's address, not the copilot's own. So for a transition link generated for the copilot, neither param can equal the session email, the predicate returns true, and the transition path signs a working copilot session out in the middle of the switch. Because both callers run the same check on boot, the sign-out arrives as a pair a few milliseconds apart.

The assumption behind this change is that a copilot who opens a link generated for a specific account expects to end up working in that account.

This change passes the copilot-session fact into isLoggingInAsNewUser and answers that no new user is signing in when the live session is a copilot session. LogOutPreviousUserPage and AuthScreensInitHandler forward isDelegateSession(session), which reads session.authTokenType and which both callers already hold, so the decision stays inside the predicate and the callers only supply a session they have already read. The email and delegatorEmail comparisons are untouched for every other session, so an ordinary switch between two people still signs the previous user out.

One side effect worth calling out. The second effect in LogOutPreviousUserPage skips the exitTo navigation while the transition counts as a new user. A copilot now reaches that navigation, which is what the same predicate already decides for any returning user.

The unit tests record what each transition link shape returns today. Reading them against the reported symptom shows the trigger is the session shape, not the link: a link naming the copilot with no delegatorEmail, and a link naming the copilot in both params, both return true against a copilot session, while the only link shape that returns false is one whose delegatorEmail equals the session email. Either way the session email is the odd one out, which is why the fix reads the session rather than the link.

One follow-up is not in scope here. DelegatorConnectGate runs connect only when the link carries a delegatorEmail, and the link shape above carries none, so with the sign-out suppressed the page still signs the client into the account named by email. Making a copilot land in the target account for that shape needs a change to that connect step.

Fixed Issues

No issue is linked. This change comes from reading the transition path against a reported copilot symptom, and there is no issue to reference here.

$
PROPOSAL:

Tests

Automated coverage, which is the primary evidence for this change:

1. Run npx jest tests/unit/SessionUtilsTest.ts --maxWorkers=2. The new isLoggingInAsNewUser block records each transition link shape against each session email, including the copilot shape, and asserts the copilot link is read as the same person.
2. Run npx jest tests/unit/LogOutPreviousUserPageTest.tsx --maxWorkers=2. The first case seeds a copilot session and a link generated for the copilot, and asserts signOutAndRedirectToSignIn is never called. The second case seeds an ordinary session the link does not name, and asserts the sign-out still happens with LOGIN_AS_NEW_USER.
3. Run npx jest tests/ui/AuthScreensInitHandlerTest.tsx --maxWorkers=2. The new case points the mocked predicate at the real implementation, so the second caller is checked against real behaviour rather than a stub, for a copilot session and for an ordinary one.
4. Confirm the fix is what makes those cases pass. Delete the if (isCopilotSession) guard from isLoggingInAsNewUser and the three copilot cases fail while all 57 others pass. Make that guard unconditional and the six genuine new-user cases fail instead, which is the check that the exemption stayed narrow.

Manual check, which needs an OldDot session because NewDot does not generate the transition link itself:

1. Set up two accounts where one is a copilot of the other with full access.
2. Sign in as the copilot in the browser and switch into the delegator account.
3. Trigger a transition link from the OldDot session of that same copilot while the copilot session is still live.
4. Before this change the app signs the copilot out and lands them on the sign-in page. After this change the copilot stays signed in and the transition proceeds.

• Verify that no errors appear in the JS console

Offline tests

This change reads a value already held in the session and adds no network call, so offline behaviour is unchanged. There is no offline state that reaches a transition link, because a transition link arrives over a live OldDot session.

QA Steps

Same as the Tests section. This path needs an OldDot session to produce the transition link, so it is not repeatable on staging alone, and there is no UI change to verify visually.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
  • No issue is linked, and that section says so.
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • The failure case here is a genuine switch between two different people, and the second case in LogOutPreviousUserPageTest and the ordinary-account row in AuthScreensInitHandlerTest both assert that sign-out still happens.
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
    • Not run against a high traffic account. The change adds one boolean read to a decision that already runs on mount, and no list, render, or network path.
• I included screenshots or videos for tests on all platforms
  • There is no UI change to capture. The changed behaviour is a sign-off decision, and the automated cases above are the evidence.
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
    • Unit and component suites pass on the JS runtime, which is shared. The copilot transition itself needs an OldDot session, so it was not driven by hand on each platform.
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
    • The new guard in isLoggingInAsNewUser carries a comment, because a session keyed to a different address than the link is not obvious from the code.
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
    • No copy was added.
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • No new pattern. The exemption reuses isDelegateSession, which already answers "is this a copilot session" elsewhere in the app.
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • isLoggingInAsNewUser has exactly two callers, and both are in this diff. The existing suites for both are green.
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
    • No styles were added.
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
    • No assets were added or changed.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
  • This path does not touch message editing or sending.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • No component here has a story.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
  • /transition is that page. The new cases cover it with a copilot session and with an ordinary session, and a signed-out session reaches LogInWithShortLivedAuthTokenPage rather than this page, so it is unaffected.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
    • No UI change.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
  • Three suites, listed in the Tests section.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

No UI change, so there is nothing to capture.

Android: mWeb Chrome

No UI change, so there is nothing to capture.

iOS: Native

No UI change, so there is nothing to capture.

iOS: mWeb Safari

No UI change, so there is nothing to capture.

MacOS: Chrome / Safari

No UI change, so there is nothing to capture.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}