Skip to content
macOSFix Published Updated 5 min readViews unavailable

Fixing a Broken Keychain Login Prompt Loop

Why the login keychain stops matching your account password after a reset, and how to fix it without losing every saved password inside it.

Repeated prompts asking to unlock the “login” keychain, or applications persistently reporting they “want to use your confidential information stored in login keychain” every single time they launch, almost always trace back to one specific cause: the login keychain’s own unlock password no longer matches your actual account password, most commonly after a password reset performed in a way that didn’t also update the keychain.

Why this desync happens in the first place

Under normal circumstances, macOS keeps your login keychain’s unlock password synchronized with your account password automatically — changing your password through System Settings updates both together. The desync happens specifically when the account password gets changed through a path that doesn’t go through that normal synchronized flow: a password reset via Apple ID recovery after a forgotten password, a password reset performed by an administrator or MDM profile, or certain FileVault recovery scenarios. In these cases, the account password changes, but the keychain — which was encrypted with the old password — doesn’t get re-encrypted to match, leaving it expecting a password that no longer works as your login credential.

Confirming this is actually the cause

Open Keychain Access (/Applications/Utilities/Keychain Access.app), select the “login” keychain in the sidebar, and check whether it shows as locked despite you having already logged into your account normally. Attempting File > “Change Password for Keychain…” and entering your current account password: if it’s rejected as incorrect even though it’s definitely your current login password, that confirms the keychain’s internal password and your account password have diverged.

The fix that preserves existing keychain contents

If you know (or can recall) the old password the keychain was actually encrypted with — the one that was valid before whatever reset changed your account password — Keychain Access’s “Change Password for Keychain…” option, using that old password to unlock and the new one to re-encrypt, resolves the mismatch while preserving every saved password already in the keychain:

security unlock-keychain -p "old_password" ~/Library/Keychains/login.keychain-db
security set-keychain-password -o "old_password" -p "new_password" ~/Library/Keychains/login.keychain-db

This is unambiguously the better outcome when it’s achievable, since it keeps every previously saved website password, Wi-Fi password, and app credential intact rather than losing them.

When the old password genuinely can’t be recovered

If the previous password is genuinely unrecoverable (a common outcome after an Apple ID-based forced reset with no memory of what the prior password actually was), the practical fallback is resetting the login keychain entirely — which does mean losing everything currently stored in it, but stops the persistent prompt loop and lets the system create a fresh, correctly-synchronized keychain going forward:

security delete-keychain ~/Library/Keychains/login.keychain-db

macOS automatically creates a new, empty login keychain on next login, correctly synchronized with your current account password from that point forward. This is a genuinely lossy fix — every saved password in the old keychain is gone — which is exactly why attempting the password-preserving fix above first, whenever the old password can plausibly be recalled, is worth the extra effort before resorting to a full reset.

Recovering what you can before resetting, if the old password is truly lost

Before deleting an unrecoverable keychain, Keychain Access can sometimes still show metadata about stored items (account names, associated websites) even while the keychain itself is locked, which — while not recovering the actual passwords — at least gives you a list of what you’ll need to re-save credentials for afterward, turning an otherwise silent, unnoticed loss into at least a known, addressable list of accounts to go re-authenticate and re-save.

Preventing this from happening again

Going forward, changing your account password exclusively through System Settings’ own password-change flow (rather than via Apple ID recovery reset, unless genuinely necessary) keeps the login keychain synchronized automatically as part of that normal flow — the desync scenario described here is specifically a consequence of the password changing through a path that bypasses that synchronization step, not something that happens during an ordinary, planned password change.

Why iCloud Keychain doesn’t have this same problem

It’s worth distinguishing the local login keychain covered throughout this guide from iCloud Keychain, a separate, Apple ID-synchronized system for passwords you specifically choose to store in iCloud rather than the local, per-Mac login keychain. iCloud Keychain items sync across your devices via your Apple ID and aren’t tied to your local macOS account password the same way — which is exactly why an Apple ID-triggered password reset doesn’t desynchronize iCloud Keychain items the way it does the local login keychain, and why a user relying primarily on iCloud Keychain-saved Safari passwords may not experience this specific prompt-loop symptom at all, even after the exact same kind of Apple ID password reset that would desync a local login keychain.

Checking which keychain is actually prompting before troubleshooting further

security list-keychains

Since a Mac can have several keychains active simultaneously (the local login keychain, an iCloud-synced one, and potentially others created by specific applications), confirming which one is actually generating the repeated prompt — Keychain Access’s sidebar names each one explicitly — avoids applying this guide’s login-keychain-specific fix to a genuinely different keychain experiencing an unrelated problem.

Related:

Sources:

Comments