[Regression][macOS 26.5] Locked Use plugin is still rejected by SecurityAgentHelper and hangs manual Touch ID unlock
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
APEventTouchIDMatchand 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:
- Enable Settings → Computer Use → Locked use.
- Leave the normal Computer Use service running.
- Lock the Mac / allow the display to lock.
- Wake the display and use the locally enrolled Touch ID fingerprint.
- Touch ID reports a successful match.
- loginwindow begins screen-lock authentication and disables the lock-screen controls while showing a spinner.
- SecurityAgentHelper attempts to load the staged Codex authorization plug-in.
- AppleMobileFileIntegrity rejects the plug-in because a platform process is mapping a non-platform binary.
- 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.
- 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:
- Disabled Settings → Computer Use → Locked use.
system.login.screensaverwas restored to only:
``text``
use-login-window-ui
com.openai.sky.CUAService.AuthorizationPlugin.remotewas removed from the authorization chain./Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundlewas removed.StagedPluginscontained no plug-in.- A delayed read-back confirmed the plug-in was not re-registered.
- 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.
1 Comment
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:
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.screensaverahead of Apple's standarduse-login-window-uipath. 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:
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.