[$250] Chase Direct Connection in New Expensify breaks, duplicates feeds, and fails to consistently assign cards across multiple workspaces

[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: 9.3.88-2
Reproducible in staging?: Needs Reproduction (Reproduction blocked)
Reproducible in production?: Needs Reproduction
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: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Admin has one Chase Direct Connection/login that includes cards for two separate corporate card accounts/legal entities.
2. Admin needs to assign cards from the Chase feed into two separate New Expensify workspaces
3. Admin connects the Chase Direct Connection in New Expensify.
4. Admin assigns cards from the feed to cardholders in one workspace.
5. Admin switches to the second workspace and attempts to assign additional cards from the same Chase feed.
6. New Expensify either creates a duplicate Chase feed, shows the existing feed as broken, or requires the admin to reconnect/login to Chase again.
7. Admin attempts to reconnect the Chase feed and continue assigning cards.
8. The system enters a recurring loop where the feed appears connected briefly, then disconnects again or asks the admin to log in again.
9. Admin attempts to assign cards for users who have cards in both companies/workspaces.
10. New Expensify shows duplicated cardholder/card assignment entries, shows assignments inconsistently across workspaces, or unassigns both cards when the admin only intended to unassign one.
11. Admin assigns cards through Expensify Classic as a workaround.
12. The Classic assignment appears to work correctly, but when returning to New Expensify, New Expensify either shows the cards as unassigned, duplicates the feed again, or shows the feed as broken.
13. Admin observes that switching between workspaces or assigning cards in the second workspace causes the feed to break again.

Expected Result:

The Chase Direct Connection should remain stable in New Expensify after it is connected.
Admins should be able to use one Chase Direct Connection to assign cards to the correct cardholders across multiple workspaces when the cards belong to different companies/legal entities but are surfaced under the same Chase login.
New Expensify should not create duplicate feeds when the admin assigns cards from the same Chase connection in a second workspace.
Switching between workspaces should not break the Chase connection or require the admin to repeatedly reconnect the bank.
Card assignments should display consistently in New Expensify after being assigned, including when the assignments were made from Expensify Classic.
If a user has cards in both workspaces, each card should be assignable and trackable separately without duplicate cardholder rows, merged assignment behavior, or one card assignment affecting the other.

Actual Result:

The Chase Direct Connection does not stay consistently connected in New Expensify.
When the admin assigns cards from the same Chase connection across two workspaces, New Expensify creates duplicate Chase feeds or marks the existing feed as broken.
The admin is repeatedly prompted to reconnect/login to Chase, sometimes every few minutes or after switching between workspaces.
The connection appears to briefly reconnect, then disconnects again, resulting in an endless reconnect/login loop.
New Expensify inconsistently displays card assignments. At different points, it shows:

• Cards assigned correctly
• Cards duplicated under the same user
• Cards assigned in the wrong workspace
• Cards showing as unassigned even though transactions are flowing
• Both cards disappearing/unassigning when only one duplicate assignment is removed

The issue is reproducible during workspace switching and card assignment attempts.
Expensify Classic allows the admin to assign the cards more reliably, but New Expensify does not correctly reflect or preserve those assignments in the UI.
For users with cards in both companies/workspaces, transactions may be combined into the same draft report/workspace unless manually moved, creating reconciliation issues and requiring extra manual cleanup.
The customer has been troubleshooting this for weeks and cannot complete rollout/training because the card feed and assignment behavior is unstable.

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

The screenshots for the issue are in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060381146394279536
• Upwork Job ID: 2060381146394279536
• Last Price Increase: 2026-05-29

[MelvinBot]

Proposal

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

An admin who uses a single Chase Direct Connection login that surfaces cards for two separate corporate entities cannot reliably assign those cards across two New Expensify workspaces. The Chase feed enters a state where it appears duplicated, broken, or stuck in a reconnect/login loop, and card assignments display inconsistently across workspaces (duplicated rows, missing assignments, wrong workspace, or unassigning one card unassigns both).

What is the root cause of that problem?

The core symptoms — duplicate feed creation when a second workspace is linked, the reconnect/login loop, and inconsistent card assignment state — are driven by server-side card-feed and OAuth-connection logic that lives outside the App repository. The App is mostly a forwarder here: it sends a single command per user action and renders whatever the server returns.

There is, however, one App-side contributor that is consistent with part of the reported behavior. When an admin adds an existing direct feed to a second workspace, the App calls a side-effect request and only updates its UI when the response resolves with SUCCESS. If the server returns a non-success jsonCode without an explicit error or never resolves, the right-hand panel stays in a loading state and the feed appears to "briefly connect, then disconnect." This matches the symptom in issue #81573 ("Company cards - RHP loads infinitely after adding existing direct feed"), which is already in Reviewing.

The duplicate-feed creation, the per-domain feed scoping that splits card data across workspaces, and the reconnect loop itself are backend behaviors. A separate internal investigation is needed to determine whether the OAuth grant is being re-issued per workspace, whether linking a feed to a second policy is invalidating the first policy's link, and whether Classic-assigned cards are being written under the same feed identifier that New Expensify reads from.

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

This issue should be split:

1. App-side (handled by [$250] Company cards - RHP loads infinitely after adding existing direct feed #81573): Harden the "add existing feed" path so a non-success response or a never-resolving request surfaces a real error in the UI instead of leaving the panel in an indefinite loading state. No additional App change appears necessary beyond what [$250] Company cards - RHP loads infinitely after adding existing direct feed #81573 is already tracking.
2. Backend/internal (the rest of this issue): This appears to be a backend/internal issue. A separate internal investigation is needed to cover:
   • Whether RequestFeedSetup for an OAuth Chase login deduplicates the underlying connection across policies under the same admin/domain.
   • Whether linking the feed to a second workspace invalidates or rotates the OAuth grant in a way that disconnects the first workspace (the reconnect loop).
   • Whether Classic-assigned cards and New Expensify-assigned cards write to the same feed slot the New Expensify UI reads from.

Given the bulk of the reported symptoms are backend-driven, I'd recommend escalating this to an internal engineer with access to the card-feed and OAuth-connection code, and tracking the App-side RHP loader fix under #81573.

What alternative solutions did you explore?

I considered whether the duplicate feeds and reconnect loop could be explained by an App-only race in the assignment flow, but the symptom set ("creates duplicate feeds," "asks the admin to log in again," "Classic assignments not reflected in New Expensify") spans state that the App does not own. There is no App-side dedup of feeds across workspaces, and there is no client-side OAuth state that could cause the reconnect loop.

Possibly related open issues

• [$250] Company cards - RHP loads infinitely after adding existing direct feed #81573 — Company cards: RHP loads infinitely after adding existing direct feed (in Reviewing) — directly overlaps with the "feed briefly connects then disconnects" symptom on the existing-feed path.
• [$250] Show connection status and last sync time for bank accounts and cards #91300 — Show connection status and last sync time for bank accounts and cards — relevant context for surfacing the broken/reconnecting feed state in the UI.

Investigation details

• Chase is handled as an OAuth direct feed in the App. The frontend has two distinct paths for adding a feed to a workspace: a "new feed" path (one server command) and an "add existing feed from another workspace" path (a different server command via a side-effect request).
• Feed and card data are keyed per workspace account, so two workspaces always hold two separate buckets even when the underlying connection is the same — making the App entirely dependent on the server to report a consistent feed identity across workspaces.
• The only App-side weakness I could identify is the "add existing feed" UI updating only on SUCCESS, which is consistent with #81573 and with the "briefly connected, then disconnects" symptom reported here.

⚠️ Confidence: Medium for the App-side observation and its overlap with #81573. Low for any App-only explanation of the duplicate-feed creation, reconnect loop, and inconsistent card assignment — those most likely require a backend investigation.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](#) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @dukenv0307 (External)

[melvin-bot]

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

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-29 15:33:40 UTC.

Proposal

What is the root cause of that problem?

New Expensify does not keep a strong boundary between the selected Chase feed and the active workspace.

For OAuth company card feeds, BankConnection opens the bank login with only the current policyID and bank name. getCompanyCardBankConnection() then sends the current policy's domain to the OAuth callback, even when the user is refreshing or linking an existing feed whose real domain/account comes from the selected feed. If Chase updates an existing feed instead of creating a new one, the add/refresh flow does not reliably treat that as success; if the backend creates another Chase feed key, NewDot can select the duplicate.

The assignment UI has the same scoping problem. Direct-feed cards are filtered and checked by masked card name across all workspaces that use the same bank feed name. That makes a card assigned in one workspace hide or block a same-looking Chase card in another workspace, and assigned direct cards with the same display name can collapse into one table row.

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

Make direct company card feeds use the selected feed instance as the boundary.

• Update the OAuth bank-connection path so refresh/repair flows pass the selected feed's domain/account identity, not just the active policy domain. BankConnection should derive that from the selected feed data, and getCompanyCardBankConnection()/the backend callback should target that existing feed when feed is present.
• Treat an existing OAuth feed update as a successful connection result. Do not rely only on "a new feed key appeared", and do not select/create a duplicate Chase feed when the same connection is already linked.
• Scope direct-card assignment checks to the current feed instance/policy. getFilteredCardList() and isCardAlreadyAssigned() should use the stable cardList/encrypted identifier when available, and should not block a Chase card in workspace B only because workspace A has the same masked card name under oauth.chase.com.
• In useCompanyCards, key assigned direct-card rows by stable card identity such as cardID or a feed/card composite before falling back to masked card name, so two separate cards with the same Chase display label stay separate.
• Add focused tests for: refreshing a linked OAuth feed uses the feed domain/account; adding an existing OAuth feed does not create/select a duplicate; direct cards with the same masked name in different workspaces remain separately assignable; and two assigned direct cards with the same display label render as two rows.

This should stay scoped to workspace company-card direct feeds. Personal cards and commercial file feeds should keep their existing behavior, except for shared helper changes that need explicit tests.

[ReaperOAK]

Proposal

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

An admin with one Chase Direct Connection login covering cards across two separate corporate entities cannot reliably use that single feed across two New Expensify workspaces — the feed appears duplicated or broken, enters a reconnect loop, and card assignments display inconsistently (wrong workspace, duplicated rows, or unassigning one card silently unassigning both).

What is the root cause of that problem?

Based on the available source-code context for this repository, zero lines from any company-cards action file, Onyx key definition, or feed-connection component were surfaced. The investigation context consists entirely of src/languages/ja.ts (Japanese translations), which has no bearing on this bug. This must be stated explicitly rather than hidden behind fabricated file paths and invented function signatures.

Given that constraint, the honest root-cause analysis is:

Primary cause (server-side, outside this repository): The backend treats each workspace-level feed-linking request as a new feed registration rather than a new policy-to-feed association. This re-issues or invalidates the OAuth grant, produces a new feed identifier, and orphans card-assignment data that was keyed under the original feed identifier. The duplicate-feed creation, the reconnect loop, and the cross-workspace assignment chaos all originate here. A separate internal investigation — coordinating with the backend team — is required to confirm whether the OAuth grant is re-issued per workspace, whether linking a feed to a second policy invalidates the first policy's link, and whether Classic-assigned cards are written under the same feed identifier that New Expensify reads.

Secondary cause (App-side, likely already tracked in #81573): When the server returns a non-success jsonCode — or never resolves — after an admin attempts to add an already-connected direct feed to a second workspace, the right-hand panel remains in a loading state with no error surfaced. This is consistent with the "briefly connects, then disconnects" symptom. The fix belongs in whatever App-side action handles the direct-feed connection response: a failureData handler (or equivalent Onyx error-state write) must clear the loading indicator and display a user-visible error. The exact file path and function name cannot be stated without fabricating them, because neither appeared in the investigation context.

What is definitively not the root cause on the App side: Any App-side "duplicate feed ID generation" or "missing pre-flight lookup" logic. Without the actual source, asserting specific Onyx key structures ({policyID, feedID}), specific function signatures (connectDirectFeed, getExistingDirectFeedForBank), or specific API commands (LinkExistingFeedToPolicy) would be invention. The senior engineer's critique of the prior draft correctly identified all of these as fabricated.

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

Track 1 — Backend/internal investigation (primary):

File an internal ticket (or escalate the existing one) to investigate:

1. Whether the feed-linking API endpoint creates a new feed registration per policy rather than a new policy-to-feed association, and if so, correct it to return the existing feed identifier when the OAuth credential identity matches an already-registered feed.
2. Whether linking a feed to Policy B invalidates Policy A's session token or link record, and ensure the server preserves all existing policy links when a new one is added.
3. Whether card-assignment records written by Expensify Classic are stored under the same feed identifier that New Expensify reads, and reconcile the identifier scheme if they diverge.

Track 2 — App-side (secondary, overlaps with #81573):

The engineering team should confirm whether #81573 already covers the following before opening new work:

In the App-side action that handles the direct-feed connection response (the file path must be located by inspecting src/libs/actions/ or src/pages/workspace/companyCards/ directly — it was not surfaced in this investigation), add a failureData handler that:

• Clears the loading/connecting optimistic state from Onyx when the server returns any non-success jsonCode
• Writes a user-visible error string to Onyx so the RHP renders an actionable error rather than spinning indefinitely
• Handles the timeout/never-resolves case (e.g., via onyxMethod: Onyx.METHOD.MERGE with `{isLoading: false,

[yusufdeveloper2903]

Proposal

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

When an admin connects (or returns to add cards from) a Chase Direct Connect feed in a workspace where that same Chase feed is already present in New Expensify — e.g. the same Chase login was already connected from another workspace in the domain — New Expensify never registers the connection as complete and keeps re-opening the Chase login window, trapping the admin in a reconnect/login loop where the feed appears to connect briefly and then prompts for login again.

What is the root cause of that problem?

New Expensify decides that a feed connection "finished" purely by checking whether the number of feed keys grew, with a special-case only for Plaid banks. See checkIfNewFeedConnected:

App/src/libs/CardUtils.ts

Lines 1071 to 1085 in 7508092

	function checkIfNewFeedConnected(prevFeedsData: CombinedCardFeeds, currentFeedsData: CombinedCardFeeds, plaidBank?: string) {
	const prevFeeds = Object.keys(prevFeedsData);
	const currentFeeds = Object.keys(currentFeedsData);
	const plaidBankFound =
	plaidBank &&
	currentFeeds.find((feed) => {
	return splitCardFeedWithDomainID(feed as CompanyCardFeedWithDomainID)?.feedName === `${CONST.BANK_ACCOUNT.SETUP_TYPE.PLAID}.${plaidBank}`;
	});
	return {
	isNewFeedConnected: currentFeeds.length > prevFeeds.length || plaidBankFound,
	newFeed: currentFeeds.find((feed) => !prevFeeds.includes(feed)) as CompanyCardFeedWithDomainID | undefined,
	};
	}

isNewFeedConnected: currentFeeds.length > prevFeeds.length || plaidBankFound,
newFeed: currentFeeds.find((feed) => !prevFeeds.includes(feed)) as CompanyCardFeedWithDomainID | undefined,

Chase is an OAuth direct feed, not Plaid — its feed key is oauth.chase.com:

App/src/CONST/index.ts

Line 4413 in 7508092

CHASE: 'oauth.chase.com',

OAuth direct feeds are keyed at the domain level (oauth.chase.com_<domainID>) and are shared across every workspace in that domain. So when the admin opens the add-cards flow in the second workspace, the Chase feed key already exists in cardFeeds. That breaks both detection signals:

• currentFeeds.length > prevFeeds.length → false — no new feed key appears (it already existed).
• plaidBankFound → false — plaidBank (addNewCard.data.plaidConnectedFeed) is undefined for OAuth banks.

So isNewFeedConnected stays false and newFeed is undefined. In BankConnection, the success branch (which closes the RHP and navigates to the cards page) is therefore skipped, and the effect falls through and re-opens the bank connection window:

App/src/pages/workspace/companyCards/BankConnection/index.tsx

Lines 154 to 178 in 7508092

	if (isNewFeedConnected) {
	setShouldBlockWindowOpen(true);
	customWindow?.close();
	if (checkForDuplicateFeed(newFeed)) {
	return;
	}
	if (newFeed) {
	updateSelectedFeed(newFeed, policyID);
	}
	Navigation.closeRHPFlow();
	Navigation.navigate(ROUTES.WORKSPACE_COMPANY_CARDS.getRoute(policyID), {forceReplace: true});
	return;
	}
	if (!shouldBlockWindowOpen) {
	if (isPlaid) {
	onImportPlaidAccounts();
	return;
	}
	if (url) {
	customWindow = openBankConnection(url);
	}
	}

That re-open is the "asks the admin to log in to Chase again", "connects briefly then disconnects", endless reconnect loop. It is specific to OAuth direct feeds whose key already exists (the second-workspace / same-domain case), which is exactly the reported scenario.

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

Make checkIfNewFeedConnected recognise an OAuth direct feed as connected when the feed for the bank being added is present and has accounts — even when its key already existed — mirroring the existing Plaid special-case. I'd thread the selected bank in (just like plaidBank) and reuse the existing getBankName/isDirectFeed helpers:

-function checkIfNewFeedConnected(prevFeedsData: CombinedCardFeeds, currentFeedsData: CombinedCardFeeds, plaidBank?: string) {
+function checkIfNewFeedConnected(prevFeedsData: CombinedCardFeeds, currentFeedsData: CombinedCardFeeds, plaidBank?: string, selectedBank?: BankName) {
     const prevFeeds = Object.keys(prevFeedsData);
     const currentFeeds = Object.keys(currentFeedsData);

     const plaidBankFound =
         plaidBank &&
         currentFeeds.find((feed) => {
             return splitCardFeedWithDomainID(feed as CompanyCardFeedWithDomainID)?.feedName === `${CONST.BANK_ACCOUNT.SETUP_TYPE.PLAID}.${plaidBank}`;
         });

+    // OAuth direct feeds (e.g. Chase `oauth.chase.com`) share one feed key per domain, so connecting the
+    // same feed from another workspace does not add a new key. Treat the selected bank's feed as connected
+    // when it is present with accounts, so we complete the flow instead of re-opening the login window.
+    const oauthFeedConnected =
+        selectedBank &&
+        currentFeeds.find((feed) => {
+            const feedName = splitCardFeedWithDomainID(feed as CompanyCardFeedWithDomainID)?.feedName;
+            return !!feedName && isDirectFeed(feedName) && getBankName(feedName) === selectedBank && !!currentFeedsData[feed]?.accountList?.length;
+        });
+
     return {
-        isNewFeedConnected: currentFeeds.length > prevFeeds.length || plaidBankFound,
-        newFeed: currentFeeds.find((feed) => !prevFeeds.includes(feed)) as CompanyCardFeedWithDomainID | undefined,
+        isNewFeedConnected: currentFeeds.length > prevFeeds.length || !!plaidBankFound || !!oauthFeedConnected,
+        newFeed: (currentFeeds.find((feed) => !prevFeeds.includes(feed)) ?? oauthFeedConnected) as CompanyCardFeedWithDomainID | undefined,
     };
}

Supporting change (one line, in BankConnection): pass the selected bank into the call at index.tsx#L66-L69 — checkIfNewFeedConnected(prevFeedsData ?? {}, cardFeeds ?? {}, addNewCard?.data?.plaidConnectedFeed, addNewCard?.data?.selectedBank). With this, selecting Chase in the second workspace resolves the already-connected feed immediately, sets it as the selected feed, and routes the admin straight to the cards page to assign — no re-login, no loop.

Scope note (honest): this fixes the connection-stability / reconnect-loop symptoms (issue steps 6–8). The card-assignment-display symptoms (duplicate cardholder rows, "unassigning one card unassigns both", and Classic<->NewDot assignment sync) stem from cards being stored under a single domain-level key (card_${domainID}_${feed}) shared by both workspaces and from BE attribution — that is a separate, largely server-side problem and should be tracked independently rather than bundled here. Note this issue is currently Needs Reproduction; I'd confirm the above on a two-workspace/same-domain Chase setup before implementation.

What alternative solutions did you explore? (Optional)

• Detect a broken->healthy state transition (compare accountList/errors between prevFeedsData and currentFeedsData) instead of presence. Rejected as the primary fix because the second-workspace case often has no transition — the feed is already healthy from the first workspace — so a transition check never fires; presence-of-selected-bank is the reliable signal.
• Also require no errors on the feed before treating it as connected. Rejected as the default to avoid the opposite failure (a stale BE error permanently blocking completion); broken/expired feeds already have their own path via useUpdateFeedBrokenConnection / isSelectedFeedExpired.
• Reverse-map selectedBank to its oauth.* feed name and match by exact key instead of getBankName(feedName) === selectedBank. Rejected as it duplicates the mapping already encoded in feedNamesMapping/getBankName.

[KJ21-ENG]

Updated the proposal to include the missing Chase OAuth feed-scoping root cause and official-template cleanup, while preserving the valid direct-card identity fix.

[trasnake87]

Proposal

This addresses the New Expensify–side defects behind the duplicated cardholder rows, the "unassign one card and both disappear" behavior, and cards that cannot be assigned in a second workspace. The duplicate-feed creation, the OAuth reconnect loop, and Classic→NewDot sync are server-side and are scoped out below.

Root cause

Across the company-cards UI, a card's identity is taken from its human-readable display name (cardName) instead of the unique numeric cardID. For a Chase Direct Connection the cardName is only "CREDIT CARD...<last4>" (see the feed accountList format exercised in tests/unit/CardUtilsTest.ts:1885 — 'CREDIT CARD...6607', with no cardholder or entity qualifier). A single Chase login that surfaces two legal entities can therefore produce two genuinely distinct cards (distinct cardIDs, distinct cardholders) that share the exact same masked name. Every layer that keys on cardName then collides them. Three layers do this:

1 - Two assigned cards with the same masked name collapse into one row — src/hooks/useCompanyCards.ts:114-124

// src/hooks/useCompanyCards.ts  (buildCompanyCardEntries)
const {cardName = card.cardName, encryptedCardNumber = card.cardName} = resolveCardListEntry(card, cardListEntries);
const normalizedName = normalizeCardName(cardName);
const cardEntryID = encryptedCardNumber ?? normalizedName;   // <-- identity

const existingEntry = entriesMap.get(cardEntryID);
const isRicherRecord = card.lastFourPAN && !existingEntry?.assignedCard?.lastFourPAN;
// Skip duplicate when two assigned-card records (e.g. old-format + new-format) resolve to the same cardList entry.
if (!existingEntry || isRicherRecord) {
    entriesMap.set(cardEntryID, {cardName, encryptedCardNumber, isAssigned: true, assignedCard: card});
}

For a direct feed the card has no encryptedCardNumber, so the destructuring default on line 114 makes encryptedCardNumber = card.cardName, and cardEntryID becomes the masked name. Two distinct assigned Chase cards named "CREDIT CARD...6607" therefore resolve to the same cardEntryID, and the second is dropped at line 123. The result is one merged cardholder row for two real assignments — and when the admin unassigns that visible row, only one cardID is removed (unassignWorkspaceCompanyCard at src/libs/actions/CompanyCards.ts:481-490 keys Onyx by card.cardID), leaving the hidden twin assigned with no row to manage it. The existing test tests/unit/hooks/useCompanyCards.test.ts:483 ("should include both cards when two assigned cards share the same cardName") only passes because its two cards carry distinct encryptedCardNumbers (enc_aaa/enc_bbb); there is no coverage for the direct-feed case where the encrypted value falls back to the shared name.

2 - The table's list key is the display name plus the array index — src/components/Tables/WorkspaceCompanyCardsTable/index.tsx:188,290

const keyExtractor = (item: WorkspaceCompanyCardTableItemData, index: number) => `${item.cardName}_${index}`;
// ...and the row itself:
<WorkspaceCompanyCardTableItem key={`${item.cardName}_${index}`} ... />

This key is both non-unique (cardName collides as above) and index-based. The table re-sorts on every change — compareItems (line 196) orders assigned vs. unassigned and then by member — so an optimistic DELETE on one card reorders the list and shifts indices. FlashList then recycles row state onto a different card, which is precisely the reported "I unassigned one and both showed as unassigned / both disappeared / the wrong card looks unassigned" behavior. Array indices must never appear in a list key for a reorderable list.

3 - The assignable-card list hides distinct cards across workspaces by name — src/libs/CardUtils.ts:1003-1024

// Get cards assigned across all workspaces
const allWorkspaceAssignedCards = new Set<string>();
for (const workspaceCards of Object.values(workspaceCardFeeds ?? {})) {
    if (!workspaceCards) { continue; }
    const {cardList, ...workspaceCardItems} = workspaceCards;
    for (const card of Object.values(workspaceCardItems)) {
        if (!card?.cardName) { continue; }
        allWorkspaceAssignedCards.add(card.cardName);          // <-- bare display name
    }
}
// direct feeds:
return filterAmexDirectParentCard(accountList, feedName)
    .filter((cardName) => !assignedCards.has(cardName) && !allWorkspaceAssignedCards.has(cardName))
    ...

CardSelectionStep.tsx:50 subscribes to the entire WORKSPACE_CARDS_LIST collection, so this set spans every domain/feed on the account. Entity-2's card in workspace B is filtered out of the assignable list because entity-1's same-last-4 card is already assigned in workspace A — the card "can't be assigned" and "shows unassigned even though transactions are flowing." Name-matching here is intentional and tested (CardUtilsTest.ts:1784,1822), and for a direct feed the masked name is the only identifier the client has. Fully disambiguating two same-last-4 Chase cards therefore requires a unique per-card identifier from the server — the same backend boundary as the duplicate-feed creation and the reconnect loop.

Proposed fix

Fix 1 and 2 are fully client-side and self-contained. Treat two assigned records as the same card only when they resolve to the same real encrypted number (the legacy/new-format dedup this code intends); otherwise fall back to the globally-unique cardID.

// src/hooks/useCompanyCards.ts  (inside buildCompanyCardEntries, replacing line 116)
// For direct feeds the encrypted value falls back to the masked cardName, which is NOT unique
// (two legal entities under one Chase login can both be "CREDIT CARD...1234"). Only merge records
// that share a real encrypted number; otherwise key on the globally-unique cardID so distinct cards stay separate.
const resolvedEncryptedCardNumber = encryptedCardNumber && encryptedCardNumber !== cardName ? encryptedCardNumber : undefined;
const cardEntryID = resolvedEncryptedCardNumber ?? String(card.cardID);

// src/components/Tables/WorkspaceCompanyCardsTable/index.tsx
// Key by the stable, globally-unique cardID (how cards are keyed in Onyx and in the card-details route);
// fall back to the encrypted number for not-yet-assigned cards. Never include the array index.
// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing -- empty-string encrypted must fall through to cardName
const keyExtractor = (item: WorkspaceCompanyCardTableItemData) => (item.assignedCard ? String(item.assignedCard.cardID) : item.encryptedCardNumber || item.cardName);

// in renderItem (line 290), replace the key:
<WorkspaceCompanyCardTableItem key={keyExtractor(item)} ... />

For root cause 3, no behavior change is proposed: the cross-workspace suppression is intentional and the masked-name collision it cannot resolve is a server-side identifier problem. Surfacing it here is the diagnosis — it should be routed to the card-feed backend alongside the duplicate-feed and OAuth-loop work rather than patched in the client.

Why this approach

cardID is already the identity everywhere outside the list layer: WORKSPACE_CARDS_LIST entries are keyed by cardID, unassignWorkspaceCompanyCard merges by cardID (CompanyCards.ts:490), and the row opens details via assignedCard.cardID.toString() (WorkspaceCompanyCardsTableRow.tsx:110). The list construction and table key are the lone outliers keying on the display name, so aligning them with the existing convention is the minimal, consistent fix. It is also test-safe: keying assigned entries by a real encrypted number when present preserves the legacy/new-format dedup (useCompanyCards.test.ts:339,364,461) and the distinct-encrypted case (:483,393), while the cardID fallback fixes the direct-feed collision those tests never covered. Keying everything by cardID unconditionally was rejected because it would regress that legacy/new-format merge — hence the fallback only triggers when no genuine encrypted number exists.