›_ Codex Issues
Codex Issues / #26319

Codex Computer Use auth plugin adds 3-5s delay to macOS lock-screen unlock

Open 💬 0 comments Opened Jun 4, 2026 by ahmedasmar

Summary

After Codex Computer Use / Locked Computer Use installs its macOS screensaver authorization hook, local lock-screen unlock can become noticeably slow even when unlock eventually succeeds.

On this machine, both Touch ID and password unlock now take about 3-5 seconds to complete from the macOS lock screen. Local logs show the delay is in the system.login.screensaver authorization path, specifically around the Codex Computer Use authorization plug-in.

This is related to existing locked-use/auth-plugin reports such as #24013, #24086, and #24394, but this issue is specifically about the latency case: normal local unlock does not fully fail, but the Codex authorization hook adds a visible delay/spinner before unlock succeeds.

Environment

  • macOS: 26.5.1, build 25F80
  • Hardware: Apple Silicon MacBook Pro
  • Codex desktop: 26.601.21317, build 3511
  • Codex Computer Use authorization plugin:
  • path: /Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle
  • bundle id: com.openai.sky.CUAService.AuthorizationPlugin
  • version: 0.1.0
  • build: 799
  • MDM/DEP status:
  • profiles status -type enrollment reports Enrolled via DEP: No
  • MDM enrollment: No

Current authorizationdb state

system.login.screensaver contains the Codex authorization rule before the normal login-window UI rule:

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

The linked Codex rule is:

class = evaluate-mechanisms
mechanisms = CodexComputerUseAuthorizationPlugin:allow
comment = Screen-unlock branch that asks SkyComputerUseClient whether an active Computer Use login authorization is pending.

User-visible behavior

  1. Lock the Mac.
  2. Wake/unlock with Touch ID or enter the account password.
  3. Authentication succeeds, but the lock screen waits several seconds before returning to the desktop.
  4. A delayed unlock/spinner-style state is visible before the desktop appears.

This happens with both Touch ID and password, so it does not look like a Touch ID sensor problem. It looks like the shared screensaver authorization path.

Local timing evidence

Compact unified-log excerpt from one unlock attempt:

2026-06-03 17:40:24.960 loginwindow ... setUnlockDelayedTimer ... auth started with lock UI showing, set unlockDelayedTimer to 1.000000
2026-06-03 17:40:25.961 loginwindow ... Unlock Delayed timer fired
2026-06-03 17:40:25.961 loginwindow ... startUnlockDelayedAnimation

2026-06-03 17:40:28.455 authd ... engine 86: running mechanism CodexComputerUseAuthorizationPlugin:allow (1 of 1)
2026-06-03 17:40:28.603 authd ... authenticated as user <user> for right 'system.login.screensaver'
2026-06-03 17:40:28.603 authd ... Succeeded authorizing right 'system.login.screensaver'

2026-06-03 17:40:28.604 loginwindow ... Screensaver authorization succeeded
2026-06-03 17:40:28.611 loginwindow ... stopUnlockDelayedAnimation
2026-06-03 17:40:28.635 loginwindow ... sendNotificationOf kScreenIsUnlocked

The important part is that the delayed unlock animation starts at 17:40:25.961, while the Codex authorization mechanism does not run until 17:40:28.455, and unlock completes at 17:40:28.635. That is the user-visible 3-5 second delay.

Plugin load evidence

The same unlock attempt also showed Library Validation errors for the staged Codex authorization plug-in:

2026-06-03 17:40:25.194 kernel ... Library Validation failed: Rejecting '/Library/Security/SecurityAgentPlugins/StagedPlugins/CodexComputerUseAuthorizationPlugin.bundle/Contents/MacOS/CodexComputerUseAuthorizationPlugin' (Team ID: 2DC432GLL2, platform: no) for process 'SecurityAgentHel(...)' (Team ID: N/A, platform: yes), reason: mapping process is a platform binary, but mapped file is not

2026-06-03 17:40:28.450 kernel ... Library Validation failed: Rejecting '/Library/Security/SecurityAgentPlugins/StagedPlugins/CodexComputerUseAuthorizationPlugin.bundle/Contents/MacOS/CodexComputerUseAuthorizationPlugin' ... reason: mapping process is a platform binary, but mapped file is not

2026-06-03 17:40:28.452 SecurityAgentHelper-arm64 ... [com.openai.sky.CUAService.AuthorizationPlugin:authorization] AuthorizationPluginCreate called

This looks like the same failure class as #24013/#24086, but in this case local unlock eventually succeeds after the delay.

Expected behavior

Installing/enabling Locked Computer Use should not add noticeable latency to normal local lock-screen unlock.

If the Codex locked-use authorization mechanism cannot load or cannot quickly determine that no active Computer Use login authorization is pending, it should fail fast and continue to the normal use-login-window-ui path without delaying local user unlock.

Disabling Locked Computer Use / remote access should also remove or bypass the Codex mechanism from system.login.screensaver.

Actual behavior

The Codex authorization mechanism remains in system.login.screensaver and local unlock waits several seconds before succeeding.

Related issues

  • #24013 - auth plugin rejected by SecurityAgentHelper Library Validation
  • #24086 - Locked Computer Use fails with cgWindowNotFound; comments include the same Library Validation failure
  • #24394 - Codex Computer Use auth plugin breaks macOS lock-screen unlock
  • #25788 - locked-use failure can lead to unsafe fallback behavior

Request

Please treat the successful-but-slow unlock path as a bug as well, not only the hard-failure cases.

Could the Codex team confirm whether plugin build 799 is expected to be in the local macOS lock-screen unlock path on macOS 26.5/26.5.1, and whether the auth plugin can be changed to avoid blocking normal local unlock when no active Computer Use locked operation is pending?

View original on GitHub ↗