We hit what looks like a more destructive variant of the same issue on a Mac running macOS 26.4.1 (25E253). After the machine became unresponsive at login and was force-restarted, loginwindow failed to unlock the existing login keychain with errSecAuthFailed (-25293). The relevant unified log entries were: Keychain did not unlock. Error: -25293 Keychain unlock failed and attempts to recover unsuccessful Keychain could not be unlocked, local account, moving login keychain to the side and creating a replacement _keychainMovedAside: 1 The user's password had not recently changed. This was a local account with Secure Token and FileVault enabled, with no MDM enrollment or configuration profiles. The original keychain's last recorded modification was about 2 minutes 40 seconds before the restart, so we don't have evidence that the restart interrupted an active keychain write. The practical impact was that macOS renamed the original login keychain and created a new blank one. Chrome, Teams, and other applications immediately lost their authentication state because the old keychain's secrets, including Chrome Safe Storage, were no longer accessible. The current and known previous local login passwords do not unlock the moved-aside keychain. After updating to macOS 26.5.2, the replacement login keychain has unlocked successfully across subsequent restarts. We can't confirm that 26.5.2 fixes the underlying issue, only that it hasn't recurred with the new keychain. This seems related to the 26.4 login-keychain authentication changes discussed here, but in our case loginwindow's automatic recovery path moved the original keychain aside and created a replacement rather than a manual lock/unlock clearing the stale state. I can provide the exact sanitized unified-log excerpt or file a separate Feedback Assistant report if that would be useful.We hit what looks like a more destructive variant of the same issue on a Mac running macOS 26.4.1 (25E253). After the machine became unresponsive at login and was force-restarted, loginwindow failed to unlock the existing login keychain with errSecAuthFailed (-25293). The relevant unified log entries were: Keychain did not unlock. Error: -25293 Keychain unlock failed and attempts to recover unsuccessful Keychain could not be unlocked, local account, moving login keychain to the side and creating a replacement _keychainMovedAside: 1 The user's password had not recently changed. This was a local account with Secure Token and FileVault enabled, with no MDM enrollment or configuration profiles. The original keychain's last recorded modification was about 2 minutes 40 seconds before the restart, so we don't have evidence that the restart interrupted an active keychain write. The practical impact was that macOS renamed the original login keychain and created a new blank one. Chrome, Teams, and other applications immediately lost their authentication state because the old keychain's secrets, including Chrome Safe Storage, were no longer accessible. The current and known previous local login passwords do not unlock the moved-aside keychain. After updating to macOS 26.5.2, the replacement login keychain has unlocked successfully across subsequent restarts. We can't confirm that 26.5.2 fixes the underlying issue, only that it hasn't recurred with the new keychain. This seems related to the 26.4 login-keychain authentication changes discussed here, but in our case loginwindow's automatic recovery path moved the original keychain aside and created a replacement rather than a manual lock/unlock clearing the stale state. I can provide the exact sanitized unified-log excerpt or file a separate Feedback Assistant report if that would be useful.