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

Start with the unified-log onset around 2026-07-27 10:48:29, the /Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle path, and the system.login.screensaver authorization entry point. Compare the healthy and sick sysdiagnoses and the post-removal observation window; done means determining whether the plugin causes the failed keybag unlock or whether macOS 26.x remains the alternative.

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 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:

1. macOS 26.5.x, FileVault on, Locked Use enabled (plugin installed in SecurityAgentPlugins).
2. Screen locks normally (e.g. display-dim auto lock); ChatGPT/Codex desktop processes active around the lock window.
3. 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

1. 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.
2. Is there telemetry / a known issue matching "keychain unusable for hours after an unlock while Locked Use is enabled"?
3. Happy to provide the full log excerpts and sysdiagnoses.