IOS - Copilot - App becomes unresponsive when trying to change the Copilot access

[mitarachim]

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.37-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-8762/folder/13176687/41236698/1247680797?sort=%2Bidentifier&p=2
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.3
App Component: User Settings

Action Performed:

Preconditions: account set a copilot.

1. Open the app
2. Go to Account > Security > Copilot
3. Tap the 3-dot menu near the copilot
   4.Tap Change access level

Expected Result:

The user should be able to change Copilot access or tap the back button, and the app should remain responsive

Actual Result:

App gets unresponsive when trying to change copilot access

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7101754_1773369710273.ScreenRecording_03-12-2026_21-33-01_1.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @aldo-expensify (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: #82764 - "Freeze non top screens to prevent extra-rerenders" by @VickyStash (High confidence)
Related Issues: #85184 (another deploy blocker with similar "app freezes" symptoms)

Recommendation: REVERT

PR #82764 introduced screen freezing logic to prevent unnecessary re-renders on non-visible screens. However, this appears to be causing app unresponsiveness when navigating to certain modal screens, including the Copilot "Change access level" page.

Labels: Removed DeployBlocker (backend label) because this is a frontend bug requiring an App PR revert/fix. Kept DeployBlockerCash because this blocks the App deploy and is staging-only (not reproducible on production).

Detailed Analysis

Evidence

PR #82764 was merged on 2026-03-12 and is included in the current staging deploy (v9.3.37-0). The PR introduces screen freezing functionality via:

1. A new ScreenFreezeWrapper component that uses react-freeze to freeze non-visible screens
2. React Navigation patches that freeze screens below the focused screen
3. Enabling enableFreeze(true) from react-native-screens on mobile

The timing aligns perfectly:

• PR merged: 2026-03-12 at 14:05:57 UTC
• Issue reported: 2026-03-13 at 06:15:31 UTC (affects v9.3.37-0)
• Issue is staging-only (not in production)

Verification

The UpdateDelegateRolePage (the "Change access level" screen for Copilots) is part of the Settings RHP (Right Hand Panel) navigator, which uses the SplitNavigator that was modified by PR #82764 to apply screen freezing.

From the PR diff:

// src/libs/Navigation/AppNavigator/createSplitNavigator/index.tsx
const SplitNavigatorComponent = createPlatformStackNavigatorComponent("SplitNavigator", {
    // ...
    freezeNonTopScreens: true,  // <- Added by PR #82764
});

When a user navigates from the Security > Copilot screen to the "Change access level" modal, the screen freezing logic may incorrectly freeze the target screen or interfere with the navigation transition, causing the app to become unresponsive.

Root Cause

The screen freezing implementation in PR #82764 appears to have edge cases that cause navigation to modal screens (like the UpdateDelegateRolePage) to fail or become unresponsive. The ScreenFreezeWrapper and related patches that freeze screens "below the focused one" may be incorrectly determining which screen should be frozen during navigation transitions, particularly for modal presentations.

Additional evidence:

• Issue Web-Ecard-App freezes when clicking on the Go to Expensify cards button #85184 reports similar "app freezes" symptoms when clicking "Go to Expensify Cards" button (also a navigation action)
• The PR explicitly modified navigation freeze behavior and added requestAnimationFrame timing logic that could cause race conditions
• The issue only affects iOS App (mobile), where enableFreeze(true) is called, consistent with the PR changes