[Bug]: Claude account switched from mobile takes effect, but the desktop keeps showing and attributing usage to the old account #17261

Operating system

Windows

Orca version

v1.4.192

Details

Short summary

Switching the active Claude account from the paired mobile app takes effect — new sessions consume the NEW account's quota — but the desktop keeps displaying the OLD account as active, and the status-bar usage meter attributes the numbers to it. Consumption moves; attribution does not.

What happens

1. Desktop and phone paired; two managed Claude accounts, A active.
2. On the phone: Accounts → select account B (accounts.selectClaude RPC).
3. The switch is real: credentials are re-materialized and the next usage fetch on the host measures account B.
4. The desktop status bar still shows account A as the active account, with the incoming numbers painted under A's label. Account B's row reads as inactive with no data. Restarting the switcher popover does not fix it; the desktop only corrects after some unrelated action forces a settings refetch.

Why (traced in the source)

• Both paths call the same service: the mobile RPC (src/main/runtime/rpc/methods/accounts.ts → runtime.selectClaudeAccount) and the desktop IPC (claudeAccounts:select) both land in ClaudeAccountSelection.select.
• That selection writes the new active id with store.updateSettings({ activeClaudeManagedAccountId, ... }) — without notifyListeners. Store.updateSettings only broadcasts when notifyListeners === true (src/main/persistence/applying-settings/settings-update.ts:246), so no settings:changed ever reaches the renderer.
• The desktop UI never notices because it normally compensates client-side: after a switch initiated in the status bar, the renderer itself calls fetchSettings() (StatusBar.tsx) and re-derives the active-account label from its own settings copy. A comment in runtime-provider-accounts-client.ts states the gap outright: "Local: one-shot reads of the desktop services (they have no push channel here; the pane refetches after each mutation)."
• The rateLimits:update push the desktop does receive carries usage numbers and the runtime target, but no active-account id — so fresh numbers from account B arrive and are rendered under the stale label of account A. Measurement on the main process is actually correct (credentials are resolved per fetch via syncForCurrentSelection); only the desktop's attribution/labeling is stale.

Scope — the trigger is "any selection not initiated by the desktop renderer", not mobile specifically

• CLI: orca account add selects the new account through the same no-notify writes (claude-account-registration.ts), so it should reproduce the same stale desktop label.
• Codex: the codex account service writes activeCodexManagedAccountId with the same pattern (src/main/codex-accounts/service.ts), so a Codex switch from mobile should show the same symptom.

Suggested fix

Minimal: pass { notifyListeners: true } on the selection writes (claude-account-selection.ts, claude-account-registration.ts, and the Codex counterparts). The renderer side already merges settings:changed into the app store (settings-sidebar-ipc-bridge.ts), and the status bar's claudeAccountSyncKey is derived from those settings, so the label and the roster refetch correct themselves with no new wire surface. Main-side onSettingsChanged listeners are all keyed to specific settings keys, so the extra broadcast is low-risk.

More robust alternative: give the desktop renderer the same push the mobile client already gets (runtime.onAccountsChanged), unifying both paths on one channel.

Related, not duplicates

• #16466 — same family of symptom (meter attributed to the wrong account) but a different mechanism: remote-runtime scope resolution of the meter's source. This report is about local selection mutations never notifying the desktop renderer.
• #14833 — adjacent: per-account usage display gaps for inactive accounts.
• #12098 — broad account-switching report; this issue isolates one specific mechanism with a code trace.