Locked use still fails on macOS 26.6.2 after refreshing authorization plug-in to build 1000968

Summary

Locked use repeatedly fails on macOS 26.6.2 even after re-enabling it and updating the installed authorization plug-in to match the Computer Use helper. Native app discovery works after a manual unlock.

This reproduces the symptom in #32396 on macOS 26.6.2 rather than the macOS 27 beta described there.

Environment

• Desktop app: 26.908.40834, build 8881.
• macOS: 26.6.2, build 25G83, arm64.
• Computer Use helper: 26.902.1000968, build 1000968.
• Installed authorization plug-in after refreshing Locked use: build 1000968.

Reproduction

1. Enable native Computer Use access and Locked use.

2. Lock the Mac and ask Codex to list native applications.

3. The request waits approximately 26 seconds and fails with:

   The Mac is locked and automatic unlock could not unlock it. Ask the user to unlock the Mac manually before continuing.

4. Manually unlock and repeat native app discovery. It succeeds.

5. Disable and re-enable Locked use, complete setup, lock the Mac, and repeat. It still fails.

macOS reported CGSSessionScreenIsLocked=Yes before and after the latest attempt. The successful unlocked test followed a manual unlock; it was not an automatic-unlock success.

Troubleshooting

• Enabling Accessibility and restarting the desktop app did not resolve this.
• Before refreshing Locked use, the installed authorization plug-in was build 1000926 while the helper bundled 1000968.
• Refreshing updated the installed plug-in to 1000968, but the failure persisted. The mismatch was not the sole cause.
• Before the refresh, the installed plug-in and helper passed codesign --verify --deep --strict outside the agent sandbox.
• Before the refresh, system.login.screensaver included com.openai.sky.CUAService.AuthorizationPlugin.remote and use-login-window-ui. The custom right referenced CodexComputerUseAuthorizationPlugin:allow.

Diagnostic evidence and limits

An earlier system-log sequence reported an error loading the Codex authorization plug-in:

not valid for use in process: mapping process is a platform binary, but mapped file is not

Immediately afterward, it included:

AuthorizationPluginCreate called
Login authorization socket response=DENY
allowed=NO

Because the plug-in subsequently ran, and this sequence may correspond to the manual unlock, the load error is not established as the cause of the automatic-unlock failure.

For the fresh test after updating the plug-in, a time-bounded query of macOS unified logs for the plug-in and lock/unlock events returned no matching entries. This does not prove the plug-in was never invoked. The exact failing stage remains unknown.

Related issues

• #32396: same visible error on macOS 27 beta.
• #24013: related authorization plug-in Library Validation rejection. Similar log text appears locally, but a shared root cause is not confirmed.

Could the team investigate macOS 26.6.2 with helper/plug-in build 1000968 and expose whether the failure occurs during loginwindow discovery, authorization exchange, or post-unlock verification?

Reproduce the failure on macOS 26.6.2 with Computer Use helper and authorization plug-in build 1000968, then inspect the available macOS unified logs and authorization-plugin behavior around the locked request. Compare the loginwindow discovery, authorization exchange, and post-unlock verification stages; done means identifying the failing stage or narrowing it with reliable evidence.