Locked Use authorization plugin leaves the login keychain permanently locked for the rest of the session

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

26.818.41509

What subscription do you have?

pro 5x

What platform is your computer?

Environment | | | |---|---| | macOS | 26.5.2 (25F84), Apple Silicon | | FileVault | On | | ChatGPT.app | 26.818.41509 (6962) | | Installed authorization plugin | 799 (CFBundleShortVersionString 0.1.0) | | Plugin bundled in ChatGPT.app installer | 1000816 (26.819.1000816) | | ~/.codex/computer-use/Codex Computer Use.app | 1000816 | | Plugin installed on | 2026-05-29 |

What issue are you seeing?

Locked Use authorization plugin leaves the login keychain permanently locked for the rest of the session

Summary

The Computer Use / Locked Use authorization plugin (com.openai.sky.CUAService.AuthorizationPlugin) installs itself as the first mechanism in the system.login.screensaver authorization rule. On my machine this ends with the legacy login keychain (login.keychain-db) locked and unrecoverable for the entire login session: loginwindow reports a successful password unlock, but the credential it forwards to SecKeychainLogin is rejected with -25293 (errSecAuthFailed). From that point on, every subsequent screen unlock takes a different code path that never attempts a keychain unlock at all.

The practical result is that every app relying on the login keychain (Chrome/Edge "Safe Storage", Electron apps, Office, CLI tools storing tokens) silently loses credential access and asks the user to sign in again — repeatedly, forever, until reboot.

I also found a clear version skew: the plugin actually installed under /Library/Security/SecurityAgentPlugins/ is build 799, while the copy bundled inside the current ChatGPT app (and the installer that ships with it) is build 1000816. The installer's own status subcommand reports OK: installed and does not detect this.

Impact

• All apps using the legacy login keychain lose stored credentials access and re-prompt for login after every screen unlock.
• The condition persists for the whole session. Only a full reboot plus a real password login at the login window restores it.
• security show-keychain-info ~/Library/Keychains/login.keychain-db returns error 51 for the rest of the session.
• Easy to misdiagnose as keychain corruption. The obvious "fix" found in most support threads — resetting the login keychain — destroys all stored credentials and does not address the cause.

Evidence

1. The authorization rule is modified, plugin first

$ security authorizationdb read system.login.screensaver
rule    = ["com.openai.sky.CUAService.AuthorizationPlugin.remote", "use-login-window-ui"]
k-of-n  = 1
created  = 736611419.328243   (2024-05-05, stock)
modified = 801745631.421675   (2026-05-29, when the plugin was installed)

The installer correctly saved the pristine rule beforehand:

/Library/Application Support/CodexComputerUseAuthorizationPlugin/backups/
  system.login.screensaver.20260529-190711.plist
  → rule = ["use-login-window-ui"], created == modified

2. Version skew, not reported by status

installed:  /Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle
            CFBundleVersion 799,     CodeDirectory size=377 hashes=4+3
bundled:    .../Codex Computer Use Installer.app/Contents/Resources/
              CodexComputerUseAuthorizationPlugin.bundle
            CFBundleVersion 1000816, CodeDirectory size=665 hashes=13+3

The two Mach-O binaries have different SHA-256 hashes; both are validly signed by Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2).

$ CodexComputerUseAuthorizationPluginInstallerTool status <RESOURCE_DIR>
OK: installed

No version comparison is performed, so a stale plugin from May keeps serving an August service build indefinitely.

3. loginwindow has two distinct outcomes for the same method

Healthy (2026-08-21 19:45:10), before the failure began:

-[LWScreenLockAuthentication _authSuccessUsingPassword:forUser:]
  | Unlock succeeded, with password, attempting to unlock the login keychain
-[LWKeychainSupport unlockLoginKeychainFromScreenLock:pwd:]
  | SecKeychainLogin returned success
  | returning; 1

Broken (2026-08-22 22:07:40 onward), 125 occurrences since 2026-08-15:

-[LWScreenLockAuthentication _authSuccessUsingPassword:forUser:]
  | Screen saver unlocked by admin, did NOT unlock the user's keychain

4. The transition event — this is the core defect

2026-08-22 22:02:44.384  -[LWKeybagSupport nullKeybagUnlockForScreenLock]
                         | MKBUnlockDevice returned: -3, so will return NO
2026-08-22 22:02:46.743  -[LWScreenLockAuthentication _authSuccessUsingPassword:forUser:]
                         | Unlock succeeded, with password, attempting to unlock the login keychain
2026-08-22 22:02:46.846  [LWError] -[LWKeychainSupport unlockLoginKeychainFromScreenLock:pwd:]
                         | ERROR | Unable to unlock the keychain from screen unlock,
                           SecKeychainLogin returned -25293
2026-08-22 22:02:46.846  | returning; 0
2026-08-22 22:02:46.846  | Unlock succeeded, with password, attempting to unlock the keybag
                           UnlockSuccess = NO;
2026-08-22 22:07:40.101  | Screen saver unlocked by admin, did NOT unlock the user's keychain

loginwindow believes a password authentication succeeded and takes the correct branch, but the credential handed to SecKeychainLogin is rejected with errSecAuthFailed. The data-protection keybag unlock fails in the same window (MKBUnlockDevice -3, UnlockSuccess = NO). Every unlock after this point falls through to the "admin" branch, which never attempts a keychain unlock at all.

5. Downstream failures follow within ~100 ms

On 2026-08-23, all 9 occurrences of did NOT unlock the user's keychain were followed by securityd CSSMERR_CSP_INVALID_DATA (-2147415994) within 0.08–0.16 s:

12:18:02.987  did NOT unlock  →  12:18:03.189  CSSMERR_CSP_INVALID_DATA
12:46:47.622  did NOT unlock  →  12:46:47.729  CSSMERR_CSP_INVALID_DATA
14:31:37.273  did NOT unlock  →  14:31:37.383  CSSMERR_CSP_INVALID_DATA
...  (9/9)

Affected clients observed: iCloudHelper (101 hits in 6 h), parsec-fbf, sharingd, akd, plus every Chromium/Electron app using Safe Storage.

Note: the same log line on 2026-08-21 (12:08, 20:03) produced zero keychain errors, because the keychain was still unlocked from an earlier real-password login. The line alone is necessary but not sufficient — the failure requires the keychain to have been locked with no working path to re-unlock it.

What I ruled out

• Keychain file corruption. login.keychain-db is structurally intact: valid kych magic, schema size consistent with file length (4-byte trailer), 103 key blobs, DbBlob present at the tail. Its SHA-256 has been stable for hours while errors kept accumulating.
• Password mismatch. The account password has never been changed (passwordLastSetTime = account creation date).
• Keychain auto-lock settings. Parsed from the DbBlob: idleTimeout = 0x7fffffff, lockOnSleep = 0. The keychain does not lock on sleep or timeout.
• Environment issues. A freshly created test keychain completes create → lock → unlock → write → read normally in the same session, so securityd and the crypto path are healthy.
• Second user account. Only root and the primary user are admins.

What I could not determine

• I found no log entries showing the plugin explicitly returning DENY, and no SecurityAgentHelper Library Validation rejection of the plugin, though both have been reported elsewhere. I can neither confirm nor rule these out.
• I cannot tell from outside whether build 1000816 fixes this, since the installed plugin was never upgraded on this machine.
• The exact reason SecKeychainLogin received a credential it rejected at 22:02:46 is not visible from OS logs alone; it requires plugin-side instrumentation.

Suggested fixes

1. Make the installer detect and repair version skew. status should compare the installed bundle's CFBundleVersion against the shipped one and report a mismatch instead of OK: installed; the service should refuse to engage the authorization branch when the versions disagree.
2. Fail safe rather than fail silent. When the plugin's unlock path cannot supply a credential that satisfies SecKeychainLogin, it should fall back to the stock use-login-window-ui mechanism so loginwindow performs a normal password unlock, rather than leaving the session in a state where the keychain can never be reopened.
3. Do not let a failed unlock poison the rest of the session. After the first SecKeychainLogin failure, every later unlock silently skips the keychain entirely. A retry or an explicit user-visible error would make this diagnosable.
4. Document the authorization plugin. It modifies a system authorization rule and installs into /Library/Security/SecurityAgentPlugins/. Neither the public docs nor the in-app UI mention this, which makes the failure extremely hard to trace.

Workaround

Uninstall via the shipped tool (it restores the saved pristine rule, removes the bundle, and clears the manifest), then reboot and log in with a real password:

sudo "<ChatGPT.app>/.../Codex Computer Use Installer.app/Contents/Resources/CodexComputerUseAuthorizationPluginInstallerTool" \
  uninstall "<same RESOURCE_DIR>"

Do not reset the login keychain — the file is fine and resetting it destroys all stored credentials without fixing anything.

What steps can reproduce the bug?

1. macOS 26.5.x with FileVault on, and a login keychain in normal use.
2. Enable Locked Use / Computer Use so the authorization plugin is installed into /Library/Security/SecurityAgentPlugins/.
3. Let the Mac lock the screen, then unlock it via the plugin-mediated path.
4. Run security show-keychain-info ~/Library/Keychains/login.keychain-db — error 51.
5. Any app using Safe Storage now re-prompts for sign-in and cannot persist credentials.

What is the expected behavior?

_No response_

Additional information

_No response_