Locked Use auth plugin suspected in recurring hours-long macOS keybag lockouts (login keychain rejects correct credentials with CSSMERR_CSP_INVALID_DATA)

Open 💬 2 comments Opened Jul 27, 2026 by fujiwarakasei

What version of the Codex App are you using (From "About Codex" dialog)?

ChatGPT.app 26.721.41059 (build 5848) — Computer Use / Locked Use installed via this app. The auth plugin bundle was /Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle (bundle mtime 2026-06-02; Locked Use enabled ~2026-07-10).

What platform is your computer?

Mac Studio M4 Max (Mac16,9), macOS 26.5.2 (25F84), Apple silicon, FileVault ON. Input: Magic Keyboard with Touch ID.

What issue are you seeing?

Since enabling Locked Use, this machine has had 3 incidents of an hours-long "keybag lockout": during one screen unlock, the data-protection keybag unlock step fails; from that second on, the login keychain (and the modern keychain) become undecodable system-wide until a later unlock succeeds in unlocking the keybag. The GUI session itself unlocks and works normally the whole time — only keychain-backed things break (apps report "keychain locked"/auth errors; security show-keychain-info ~/Library/Keychains/login.keychain-db exits 51 "The user name or passphrase you entered is not correct" even though the password is correct and unchanged).

Incidents (all with the plugin installed; timestamps JST):

| # | Onset | Heal | Duration |
|---|-------|------|----------|
| 1 | 2026-07-16 17:28:33 | 2026-07-17 00:09:54 | ~6.7 h |
| 2 | 2026-07-18 16:20:37 | 2026-07-19 01:29:13 | ~9.1 h |
| 3 | 2026-07-27 10:48:29 | 2026-07-27 12:10:22 | ~1.4 h |

Onset signature (incident #3, unified log):

10:48:27.545 loginwindow: -[LWKeybagSupport nullKeybagUnlockForScreenLock] | MKBUnlockDevice returned: -3, so will return NO
10:48:29.194 loginwindow: -[LWScreenLockAuthentication _authSuccessUsingPassword:forUser:] | Unlock succeeded, with password, attempting to unlock the login keychain
10:48:29.216 securityd: CSSM Exception: -2147415994 CSSMERR_CSP_INVALID_DATA      <-- first error, lockout begins
10:48:29.219 loginwindow: ... attempting to unlock the keybag                      <-- keybag unlock did not take effect

During an episode, secd also logs SecDbKeychainItemV7: cannot decrypt metadata key / decode item failed, keychain is locked, and in incidents #1/#2 loginwindow logged KeyBagUnlock ... err:-3 on the password path. The episode ends only when a later unlock actually unlocks the keybag (Unlock succeeded, with password, attempting to unlock the keybag succeeding, or securityd keybag already unlocked).

Key observation — credential in the log does not match the user's action: at the 10:48:29 onset the user is 100% certain they unlocked with Touch ID, yet loginwindow recorded a password-credential unlock ("Unlock succeeded, with password"). On the same day, other Touch ID unlocks on this machine logged the normal Touch ID form instead: Screen saver unlocked by admin, did NOT unlock the user's keychain (e.g. 11:55:53, plugin still installed, same keybag-locked conditions). So at the exact onset second, something submitted a password-shaped credential on the user's behalf, the session unlocked, but the keybag step failed — which matches an auth-plugin-vended credential whose keybag unlock is flaky. Earlier forensics (incident #2 era) also showed unlock lines with inpasswdsent:1 while the user was using Touch ID only.

During an episode, Touch ID unlock cycles do not heal it (3 consecutive attempts failed on 2026-07-27); a typed-password unlock healed it on the first try at 12:10:22. This is consistent with the plugin sitting in the system.login.screensaver authorization path (see #26319) and its unlock step being intermittent (see #32396 / #32913, "automatic unlock could not unlock it").

After disabling Locked Use in settings on 2026-07-27 ~12:00, the uninstall was clean on this machine (unlike #29350): the plugin bundle is gone from /Library/Security/SecurityAgentPlugins/, the right com.openai.sky.CUAService.AuthorizationPlugin.remote no longer exists (-60005), and system.login.screensaver is back to the default use-login-window-ui. We are now in a multi-week observation window: no further onsets with the plugin removed would confirm the plugin's involvement; a recurrence would exonerate it (and point at macOS 26.x itself).

Also filed with Apple as FB23809263 (macOS → Security), since a macOS 26.x keybag regression is the alternative hypothesis. Two sysdiagnoses exist (healthy state 2026-07-17, sick state 2026-07-19 01:22) and can be shared on request.

What steps can reproduce the bug?

Not reproducible on demand — the failing keybag step is intermittent. Conditions common to all 3 onsets:

macOS 26.5.x, FileVault on, Locked Use enabled (plugin installed in SecurityAgentPlugins).
Screen locks normally (e.g. display-dim auto lock); ChatGPT/Codex desktop processes active around the lock window.
User unlocks (Touch ID); loginwindow logs a password-credential unlock instead; keybag unlock does not take effect → hours-long keychain lockout until a later unlock (typed password most reliable) unlocks the keybag.

Questions for the Codex team

Does the Computer Use authorization plugin have a path where it submits a credential that unlocks the screen/session but leaves the user keybag locked (MKB error -3)? Incident #2's own logs showed exactly this pattern repeatedly while agents were driving the machine during screen lock.
Is there telemetry / a known issue matching "keychain unusable for hours after an unlock while Locked Use is enabled"?
Happy to provide the full log excerpts and sysdiagnoses.

View original on GitHub ↗

2 Comments

Astro-Han · 11 days ago

Independent reproduction on a second machine, with a tighter causal sequence linking the Locked Use authorization mechanism to the keychain/keybag failure.

Environment

macOS 26.5.2 (25F84)
Mac17,9, Apple M5 Pro, arm64
FileVault: on
ChatGPT/Codex desktop: 26.810.52044 (build 6662), bundle ID com.openai.codex
Installed authorization plugin: com.openai.sky.CUAService.AuthorizationPlugin, version 0.1.0, build 799
system.login.screensaver currently contains:

com.openai.sky.CUAService.AuthorizationPlugin.remote
use-login-window-ui

Observed incident

On 2026-08-17, a normal local password unlock completed visually, but the login keychain and Data Protection Keychain became unusable system-wide immediately afterward.

The sanitized unified-log sequence for the same unlock event was:

authd: running mechanism CodexComputerUseAuthorizationPlugin:allow
authd: succeeded authorizing right system.login.screensaver
loginwindow: screensaver authorization succeeded
secd/securityd: Data Protection Keychain still locked (-25308)
loginwindow: unlock succeeded with password; attempting to unlock login keychain
securityd: CSSMERR_CSP_INVALID_DATA
securityd: CSSMERR_DL_OPERATION_AUTH_DENIED
loginwindow: SecKeychainLogin failed

From that point onward:

Secret reads failed across unrelated keychain clients; this was not isolated to one application or sandbox.
security show-keychain-info ~/Library/Keychains/login.keychain-db rejected the correct, unchanged password with The user name or passphrase you entered is not correct.
Metadata-only keychain queries could still succeed while authenticated/secret reads failed.
The state persisted across application and process restarts.
A reboot restored the same keychain immediately. No keychain reset, deletion, password change, or credential recreation was performed.

This differs slightly from the original report: the user intentionally typed the password at the lock screen. The important observation is that CodexComputerUseAuthorizationPlugin:allow ran and screen authorization succeeded, but the keybag/keychain unlock did not complete. The failure begins in the same unlock transaction, immediately after the Codex authorization mechanism.

This also resembles Apple's acknowledged authorization-plugin bug where screensaver unlock can fail to unlock the Data Protection Keychain (FB13128730): https://developer.apple.com/forums/thread/796487. A separate macOS 26.4+ login-keychain regression is tracked as FB22448572: https://developer.apple.com/forums/thread/822120.

Could the Codex team please investigate whether the Locked Use mechanism can authorize system.login.screensaver while leaving the user's keybag or login keychain locked? Given the system-wide impact and the possibility of macOS moving an unrecoverable keychain aside after repeated failures, it may be safer to disable or bypass this authorization hook on affected macOS versions until the unlock path can guarantee keybag consistency.

I can provide a longer sanitized unified-log excerpt and the secd resource diagnostic through a private channel if useful. I am intentionally not posting the raw diagnostic publicly because it may contain private process and keychain metadata.

pool1892 · 9 days ago

Third independent reproduction, with a clean recovery sequence on the current Codex desktop build.

Environment

macOS 26.5.2 (25F84)
MacBook Pro (Mac17,6), Apple M5 Max, arm64
FileVault on
ChatGPT/Codex desktop 26.810.52044 (build 6662)
Locked Use authorization plugin build 799

Onset

At 2026-08-18 08:02:46 PDT, a screen-unlock transaction began with:

08:02:46.707 loginwindow: MKBUnlockDevice returned: -3
08:02:48.312 authd: running mechanism CodexComputerUseAuthorizationPlugin:allow
08:02:48.313 authd: Succeeded authorizing right system.login.screensaver
08:02:48.315 loginwindow: Unlock succeeded, with password, attempting to unlock the login keychain
08:02:48.335 securityd: CSSMERR_CSP_INVALID_DATA
08:02:48.340 loginwindow: SecKeychainLogin failed ... -25293

The graphical session unlocked, but authenticated Keychain operations then failed system-wide for about 3 hours 38 minutes:

security show-keychain-info ~/Library/Keychains/login.keychain-db exited 51 and rejected the correct, unchanged password.
Claude Code browser OAuth briefly reported success, but the local session disappeared immediately because the credential could not be persisted.
A credential-switching tool could locate Keychain item metadata but could not read the secret, and safely refused to overwrite its backup.
1Password could not write a new 2FA token.
securityd continuously logged CSSMERR_CSP_INVALID_DATA.

Clean recovery

At 11:40:22, Locked Use was disabled through Codex settings. The authorization-plugin bundle was removed and system.login.screensaver returned to only:

use-login-window-ui

The screen was then locked and unlocked once using the typed macOS account password. At 11:41:01:

loginwindow: SecKeychainLogin result: 0, password was supplied
loginwindow: SecKeychainLogin returned success
loginwindow: UnlockSuccess = YES

The CSSMERR_CSP_INVALID_DATA error storm stopped immediately, and security show-keychain-info now succeeds. No reboot, Keychain reset/deletion, password change, or credential recreation was performed.

This does not by itself distinguish a Codex plugin defect from a macOS 26 keybag bug, but it provides another onset where the Codex authorization mechanism successfully authorized the screen while Keychain/keybag unlock failed, plus a clean mitigation sequence: remove Locked Use, then perform a real typed-password unlock.

I can provide a longer sanitized log excerpt privately if useful; raw diagnostics are intentionally not posted because they can contain process and Keychain metadata.