[Regression][macOS 26.5] Locked Use plugin is still rejected by SecurityAgentHelper and hangs manual Touch ID unlock

Open 💬 1 comment Opened Aug 19, 2026 by Kitcura-1004

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

ChatGPT/Codex App 26.814.41407 (build 6720)

Computer Use authorization plug-in: 0.1.0 (build 809)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

macOS 26.5 (25F71), Apple Silicon, FileVault enabled.

What issue are you seeing?

With Settings → Computer Use → Locked use enabled, a normal local/manual Touch ID unlock hung on the macOS lock screen.

The fingerprint was successfully recognized, but the lock screen showed a spinner for more than a minute, useful keyboard input did not recover the session, and the Mac remained locked. The only available recovery was a forced power-button restart.

This was not a Touch ID sensor failure or an invalid user password:

  • BiometricKit reported MATCH.
  • coreauthd reported unlocked:1, credential:1, resultIgnored:0.
  • loginwindow received APEventTouchIDMatch and began screen-lock authentication.
  • After the forced restart, the real login password succeeded through both the Secure Enclave credential and ShadowHash paths.
  • The original login keychain then logged keychain unlocked successful, with no keychain reset or move-aside.

Immediately after the successful Touch ID match, AppleMobileFileIntegrity rejected the Locked Use authorization plug-in twice:

Library Validation failed: Rejecting
'/Library/Security/SecurityAgentPlugins/StagedPlugins/
CodexComputerUseAuthorizationPlugin.bundle/Contents/MacOS/
CodexComputerUseAuthorizationPlugin'
(Team ID: 2DC432GLL2, platform: no)
for process 'SecurityAgentHelper'
(Team ID: N/A, platform: yes),
reason: mapping process is a platform binary, but mapped file is not

The plug-in itself passed codesign --verify --deep --strict and was signed by:

Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)

This appears to be the same underlying Library Validation failure reported in #24013, which was closed as completed and used authorization plug-in build 799. It is still present in build 809, and in this incident it blocked the user's own manual Touch ID unlock rather than only causing a remote Computer Use/Get App State failure.

What steps can reproduce the bug?

Observed sequence:

  1. Enable Settings → Computer Use → Locked use.
  2. Leave the normal Computer Use service running.
  3. Lock the Mac / allow the display to lock.
  4. Wake the display and use the locally enrolled Touch ID fingerprint.
  5. Touch ID reports a successful match.
  6. loginwindow begins screen-lock authentication and disables the lock-screen controls while showing a spinner.
  7. SecurityAgentHelper attempts to load the staged Codex authorization plug-in.
  8. AppleMobileFileIntegrity rejects the plug-in because a platform process is mapping a non-platform binary.
  9. The authorization request does not complete. After about 49 seconds, loginwindow's display-idle timer cancels the authentication and records an unlock failure. Further interaction did not restore the session.
  10. Force-restart the Mac to recover.

The failure has not been deliberately reproduced again because it can require another forced restart and risk unsaved data.

What is the expected behavior?

A local/manual Touch ID unlock must remain available even if Locked Use cannot load its authorization plug-in.

If the Locked Use plug-in is incompatible with the current macOS SecurityAgentHelper/Library Validation policy, the feature should fail closed for automatic remote unlock while immediately falling back to the standard Apple use-login-window-ui path for the local user. It must not block or indefinitely delay the user's own Touch ID or password unlock.

Additional information

Incident timeline, local time:

03:38:11.731  BiometricKit: MATCH
03:38:11.733  coreauthd: unlocked:1, credential:1, resultIgnored:0
03:38:11.735  loginwindow: APEventTouchIDMatch; authentication began
03:38:11.954  AppleMobileFileIntegrity: plug-in rejected
03:38:12.287  AppleMobileFileIntegrity: plug-in rejected again
03:39:01.163  loginwindow: authentication timed out/cancelled; unlock failed
03:42          Forced restart; no normal shutdown record
03:43:34      Real password authentication, keychain unlock, and desktop login succeeded

Workaround and verification:

  1. Disabled Settings → Computer Use → Locked use.
  2. system.login.screensaver was restored to only:

``text
use-login-window-ui
``

  1. com.openai.sky.CUAService.AuthorizationPlugin.remote was removed from the authorization chain.
  2. /Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle was removed.
  3. StagedPlugins contained no plug-in.
  4. A delayed read-back confirmed the plug-in was not re-registered.
  5. Multiple manual lock-screen → Touch ID → desktop tests then succeeded.

The normal unlocked-session Computer Use service remains enabled and usable. Only Locked use was disabled.

Related issues:

  • #24013 — same Library Validation rejection on older authorization plug-in build 799; closed as completed.
  • #35553 — open report involving Locked Use and keybag/login-keychain failures.
  • #32396 — automatic Locked Use unlock failure.

Impact:

  • Local lock-screen availability failure.
  • Forced-restart requirement.
  • Risk of unsaved-data loss and filesystem/application-state damage.
  • Potential authentication/keybag interaction risk because the third-party rule precedes use-login-window-ui.

Feedback ID: 01a01b8e-2eca-7d83-afe1-fe8d7a8a7758

Full unified logs and sysdiagnose are intentionally not attached publicly because they may contain unrelated private information. Narrow, redacted log excerpts can be provided on request.

View original on GitHub ↗

1 Comment

Kitcura-1004 · 3 days ago

Maintainer triage requested: this can break the user's normal macOS authentication path

Since this report was filed, several additional open reports have described failures around the same Locked Use authorization integration:

  • #24394 — the registered Codex authorization mechanism breaks ordinary macOS lock-screen unlock.
  • #35553 — multiple independent machines experienced session-wide keychain/keybag failures immediately after the Codex authorization mechanism ran; one report documents clean recovery after disabling Locked Use and performing a normal password unlock.
  • #40168 — login Keychain replacement, application sign-outs, and lost Touch ID enrollments after restart while the Locked Use plug-in remained registered. Causation is not yet established, but the potential impact is severe.
  • #40226 — the login Keychain remains locked for the rest of the GUI session after the authorization plug-in runs.
  • #40235 — Secure Event Input remains owned by Codex after screen unlock and even after the app exits; the affected unlock also recorded a Library Validation failure and a stale/version-mismatched authorization hook.

The evidence in this issue is narrower and directly observed: Touch ID completed successfully (MATCH, unlocked:1), then SecurityAgentHelper rejected the Codex plug-in under Library Validation, loginwindow stopped making progress, and the user was forced to power-cycle the Mac. Disabling Locked Use removed the custom authorization mechanism, after which repeated normal Touch ID unlocks succeeded.

This deserves priority beyond a normal feature failure. The custom mechanism is inserted into system.login.screensaver ahead of Apple's standard use-login-window-ui path. When it fails, it can interfere with the user's own local unlock, force an unsafe restart, and create a realistic unsaved-data or application-state-loss risk. The related reports raise additional keychain/keybag and session-wide input-integrity concerns, even though a single shared root cause has not yet been proven.

Could the maintainers please:

  1. Acknowledge and severity-triage this cluster as a macOS authentication/safety issue.
  2. Confirm whether the Library Validation failure and installed app/Computer Use/authorization-plug-in version mismatches are known.
  3. Consider an immediate fail-safe mitigation: if the plug-in cannot be validated, contacted, or version-matched, remove/bypass the custom mechanism and fall back atomically to the standard local unlock path. Temporarily disabling Locked Use on affected macOS/build combinations would be safer than leaving a third-party mechanism able to block local login.
  4. Tell reporters which narrow, redacted diagnostics would be useful and where they can be provided privately.

I will not deliberately reproduce this again because doing so can require another forced restart. The existing Feedback ID and sanitized timeline are available above.