Codex Computer Use auth plugin caused a 17-minute macOS lock-screen unlock stall

What version of the Codex App are you using?

Codex Desktop 26.616.71553 / CFBundleVersion 4265

What subscription do you have?

Not specified.

What platform is your computer?

• macOS 26.5.1 build 25F80
• Darwin 25.5.0 arm64 arm
• Apple Silicon Mac

Component

Codex Desktop / Computer Use / Locked Computer Use authorization plugin on macOS.

Summary

After Codex Computer Use installed its macOS lock-screen authorization plugin, local macOS lock-screen unlock could stall for a very long time after entering the correct password.

In the observed incident, the lock screen showed the spinner for about 17.5 minutes after password entry. The password was eventually accepted and the desktop unlocked. Local unified logs show the delay in the system.login.screensaver authorization path. Removing the Codex Computer Use authorization rule from system.login.screensaver fixed local lock/unlock immediately in a same-run test.

This looks related to #24394 and #26319, but this report includes a much longer successful-but-stalled unlock path and same-run workaround verification.

Installed authorization plugin

The plugin is installed at:

/Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle

Plugin Info.plist:

CFBundleIdentifier = com.openai.sky.CUAService.AuthorizationPlugin
CFBundleShortVersionString = 0.1.0
CFBundleVersion = 799

AuthorizationDB state before workaround

Before the workaround, system.login.screensaver contained the Codex rule before the normal login-window UI rule:

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

The linked Codex rule was:

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

User-visible behavior

1. Lock the Mac.
2. Enter the account password at the macOS lock screen.
3. The password field accepts input, but the UI stays on the lock screen spinner for more than 10 minutes.
4. In this incident, unlock eventually succeeded after about 17.5 minutes.

This happened twice on the same day before the workaround.

Local log evidence from the stalled unlock

Sanitized excerpt from the relevant unified logs:

2026-06-23 19:02:04.867 loginwindow ... loginPressed
2026-06-23 19:02:04.891 authd ... evaluates 1 rights ... "system.login.screensaver" ... engine 474
2026-06-23 19:02:05.869 loginwindow ... _setProgressIndicatorHidden ... hidden: 0

... lock screen spinner remained visible ...

2026-06-23 19:19:34.368 authd ... engine 474: running mechanism CodexComputerUseAuthorizationPlugin:allow (1 of 1)
2026-06-23 19:19:34.636 authd ... authenticated as user <user> for right 'system.login.screensaver'
2026-06-23 19:19:34.636 authd ... Succeeded authorizing right 'system.login.screensaver'
2026-06-23 19:19:34.640 loginwindow ... Screensaver authorization succeeded
2026-06-23 19:19:34.822 loginwindow ... Unlock succeeded, with password
2026-06-23 19:19:34.999 loginwindow ... _setProgressIndicatorHidden ... hidden: 1
2026-06-23 19:19:45.643 authd ... Successfully removed staged plugin: /Library/Security/SecurityAgentPlugins/StagedPlugins/CodexComputerUseAuthorizationPlugin.bundle

The important part is that system.login.screensaver evaluation began at 19:02:04, the spinner appeared at 19:02:05, and the flow did not continue until CodexComputerUseAuthorizationPlugin:allow ran at 19:19:34. The normal password-based unlock then completed immediately.

Checks that point away from a previous local maxfiles issue

This machine previously had a separate maxfiles/syspolicyd problem, but this incident did not look like the same root cause:

launchctl limit maxfiles
maxfiles 60000 unlimited

There were also load contributors at the time, such as WindowServer / syspolicyd CPU and low disk free space, but the direct stall point in this incident was the system.login.screensaver authorization chain containing the Codex plugin.

Workaround applied

I backed up the current rule, then changed system.login.screensaver to remove only the Codex rule and leave the system login-window UI rule:

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

after:
  use-login-window-ui

I did not delete the plugin bundle. I only removed it from the lock-screen unlock path.

Read-back verification after the workaround:

security authorizationdb read system.login.screensaver
...
rule = (
  use-login-window-ui
)

The diff was limited to removing this entry from system.login.screensaver:

com.openai.sky.CUAService.AuthorizationPlugin.remote

Same-run verification after workaround

After applying the workaround, I locked the Mac and unlocked it again. Unlock succeeded immediately.

Post-test log excerpt:

2026-06-23 19:37:30.153 authd ... engine 521: running mechanism builtin:reset-password,privileged (2 of 3)
2026-06-23 19:37:30.154 authd ... engine 521: running mechanism builtin:authenticate,privileged (3 of 3)
2026-06-23 19:37:30.226 authd ... authenticated as user <user> for right 'system.login.screensaver'
2026-06-23 19:37:30.226 authd ... Succeeded authorizing right 'system.login.screensaver'
2026-06-23 19:37:30.226 loginwindow ... Screensaver authorization succeeded

A read-back filter also confirmed the active rule contained only:

use-login-window-ui

and did not contain:

com.openai.sky.CUAService.AuthorizationPlugin.remote
CodexComputerUseAuthorizationPlugin

Expected behavior

Codex Computer Use / Locked Computer Use should not block normal local macOS lock-screen unlock after the user enters the correct password.

If the Codex authorization plugin cannot quickly determine that no active Computer Use login authorization is pending, it should fail fast or bypass itself so local unlock can continue.

Disabling or removing locked-use behavior should also remove/bypass the Codex mechanism from system.login.screensaver.

Actual behavior

With com.openai.sky.CUAService.AuthorizationPlugin.remote registered in system.login.screensaver, local password unlock stalled on the spinner for about 17.5 minutes before succeeding. Removing that rule from system.login.screensaver made the next lock/unlock test complete immediately.

Related issues

• #24394 - Codex Computer Use auth plugin breaks macOS lock-screen unlock
• #26319 - Codex Computer Use auth plugin adds 3-5s delay to macOS lock-screen unlock
• #24013 - Locked Computer Use authorization plug-in rejected by SecurityAgentHelper Library Validation
• #29350 - Computer Use plugin / syspolicyd / macOS stability report