Locked use is enabled but automatic unlock fails on macOS

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

26.707.31428 (build 5059)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 27.0.0 arm64 arm

What issue are you seeing?

human description: codex kept on saying that computer use wouldn't work because the mac was locked. but we have that setting enabled (see screenshot).

codex written description:

The exact error returned by Computer Use was:

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

<img width="829" height="420" alt="Image" src="https://github.com/user-attachments/assets/e18ecc36-12c3-4b89-97dd-fe50168398c2" />

Once the Mac was manually unlocked, the same Computer Use runtime immediately worked and list_apps returned running applications normally. This isolates the failure to automatic lock-screen unlock rather than general Accessibility, Screen Recording or Computer Use access.

Feedback/session ID: 019f48b9-86a4-74e3-abda-5a45bb45f6d2

What steps can reproduce the bug?

1. Open Codex Settings → Control.
2. Enable Any App.
3. Enable Locked use — Let ChatGPT use your Mac when it is locked.
4. Start a Codex task that uses Computer Use.
5. Lock the Mac.
6. Ask Codex to inspect any application using list_apps or get_app_state.

The request fails with the automatic-unlock error above. Manually unlock the Mac and repeat the same request; it succeeds.

What is the expected behavior?

With Locked use enabled, Codex should temporarily unlock the Mac through its guarded lock-screen mechanism, perform the Computer Use operation and restore the locked state. If the mechanism cannot operate on this OS build, Settings should say so and the runtime should expose the failed stage.

Additional information

Verified environment

• Codex app: 26.707.31428, build 5059
• Computer Use helper: 26.708.1000366, build 1000366
• Locked-use authorisation plug-in: build 829
• macOS: 27.0 beta, build 26A5353q
• Architecture: Apple silicon (arm64)
• Any App and Locked use were both enabled

Local diagnosis

The required helper and lock-screen authorisation plug-in are installed:

~/.codex/computer-use/Codex Computer Use.app
/Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle

The helper was built with the macOS 26.4 SDK and the authorisation plug-in with the macOS 26.1 SDK. The failure occurs on macOS 27.0 beta.

The helper contains a dedicated guarded auto-unlock path. Its diagnostic strings show that it searches the loginwindow accessibility tree for UserPasswordTextField, invokes the Codex authorisation plug-in, and verifies whether the Mac unlocked. Relevant internal failure stages include:

• loginwindow accessibility root unavailable
• password field or reveal prompt unavailable
• authorisation attempt not consumed by the plug-in
• unlock attempt completed but the Mac remained locked
• automatic-unlock attempt budget exhausted

The returned message was the generic automatic-unlock failure, not the distinct errors for physical-input suppression or a request that could not be associated with a Codex thread. That suggests the request was eligible for Locked use but the loginwindow/authorisation exchange failed.

codesign --verify and spctl also reported invalid-signature/internal Code Signing subsystem errors for the Codex app, Computer Use helper and authorisation plug-in. macOS 27 produced similar verification errors for unrelated signed applications, so this is supporting evidence rather than a confirmed root cause.

This looks like a macOS 27 compatibility regression in the lock-screen authorisation path. Ordinary Computer Use remains functional after manual unlock.

Relationship to earlier reports

• #24013 is the closest match and may be the same underlying bug. Both reports involve Apple silicon, Locked use already enabled, the authorisation plug-in installed, normal Computer Use working after manual unlock, and app-state acquisition failing only while locked. #24013 captured direct macOS 26.5 logs showing SecurityAgentHelper rejecting plug-in build 799 because of Library Validation. This report reproduces the user-visible failure on macOS 27 with plug-in build 829 and helper build 1000366, but we have not yet captured the same SecurityAgentHelper log. It may therefore be a regression of #24013, but that is not proven.
• #29216 is an earlier setup failure rather than the same runtime failure. In that report, the Locked use toggle cannot be enabled, the update immediately reports “Plugin update failed”, and the required component appears not to install. Here the toggle remains enabled and the helper and plug-in are installed; failure occurs only when a locked Computer Use request tries to run.
• #24207 is an Intel packaging/signing failure during enablement. #25243 concerns file-descriptor exhaustion from Locked use. #25719 concerns repeated syspolicyd/trustd validation load. They are adjacent subsystem reports, but their reported failure modes differ.

The most useful next diagnostic is the SecurityAgentHelper and authd log from a fresh locked-use attempt. If it shows the same Library Validation rejection as #24013, this should be treated as a macOS 27 regression of that issue rather than a separate failure.
It would help if the surfaced error identified whether failure occurred during plug-in registration, loginwindow accessibility discovery, socket connection, authorisation consumption or post-unlock verification.