ENVIRONMENT Mac mini (M4), macOS 26.7 beta (25G227). iPhone 16 Pro, iOS 27 beta (24A5430a). Same Apple Account on both, two-factor enabled. Important: the failure began on 1 September on shipping builds, macOS 26.6.2 with iOS 26.6.1, after working fine for 27 logged sessions. Both devices were moved to betas afterwards while troubleshooting, and the behaviour has never changed on any build. SUMMARY iPhone Mirroring fails in my main macOS user account with "Cannot Connect to iPhone". A second macOS user account on the SAME Mac, signed in to the SAME Apple Account, connects to the SAME iPhone successfully. The fault is scoped to one macOS user account. FAILING ACCOUNT ScreenContinuityApp check sequence passes 1.1 through 4, then: 5. Checking if Replicator has a device paired Tearing down the session due to: noCompatiblePhone replicatord: Fetched IDS device: ; isCloudPaired: false Cannot handshake with discovered device, sync service does not know about it yet Unable to send message to device; no longer associated with account Error sending handshake request ... unknownDestination Reconciling devices. Known: []; unknown: [state: introduced; isPaired: false; personaID: nil] rapportd: Ignoring BLE device that does not have expected status flags (DF 0x30 ) Resolve identity for signature failed: 0x80 At the same moment sharingd identifies the phone correctly as Type SameAccountDevice at -42 dBm. WORKING ACCOUNT, same phone, minutes apart isCloudPaired: true Handshake completed: rapportd resolves DF 0xA9 "Ignoring BLE device" count 0, session runs over AWDL Every attempt in the failing account creates a NEW pairing relationship stuck at state: introduced, isPaired: false, then abandons it. Three distinct relationshipIDs were observed, each with an initialPairingDate matching the minute of the attempt, so they are regenerated symptoms rather than stale records. RULED OUT Apple Account sign out and back in on the Mac (twice) and on the iPhone (the phone received an entirely new Octagon identity, which the Mac accepted as a trusted peer) A full revoke-and-setup cycle: revoked from the working account so the pairing slot was completely empty, then ran setup from the failing account with the phone unlocked and in hand. Still noCompatiblePhone, and no on-device approval prompt ever appeared. Reset of per-user IDS state, deletion of Continuity keychain items and of the sharingd / rapport / ScreenContinuity preferences, ckksctl resync of DevicePairing and AutoUnlock, restart of identityservicesd, imagent, sharingd, rapportd and replicatord Reset Network Settings on the iPhone, a new macOS Network Location, a different Wi-Fi network, Bluetooth off and on, toggling iPhone Widgets, Lockdown Mode off, Screen Time restrictions off, Sidecar disconnected macOS 26.6.2 to 26.7 and iOS 26.6.1 to iOS 27 beta VERIFIED HEALTHY IN THE FAILING ACCOUNT otctl status reports Ready with the iPhone as a trusted peer. ckksctl reports every view ready, including DevicePairing and AutoUnlock. IDS is registered with no "Not registered" entries. awdl0 is active. No configuration profile restrictions. System Settings shows the correct iPhone selected for iPhone Mirroring. TWO OBSERVATIONS THAT MAY BE USEFUL The iPhone stores this pairing per Mac, not per macOS user account. Settings > General > AirPlay & Continuity > iPhone Mirroring showed exactly one entry, the Mac's name, marked Currently Connected while the working account was mirroring. The "Revoke Access to [iPhone]" button is not permanently disabled. It is only disabled while a mirroring session is active. The same applies to Edit > delete on the phone. QUESTIONS Is the IDS account-associated-devices list maintained per macOS user account, and what determines whether a device is admitted to it? Is there a supported way to force that per-user list to resynchronise, short of deleting and recreating the user account? Is replicatord remaining at Known: [] while regenerating introduced / isPaired: false relationships a known issue? I have not filed via Feedback Assistant yet. Happy to file one with a sysdiagnose from both accounts if that is the right route.