Locked Computer Use fails after idle display lock while manual lock works

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

26.803.61601 (6396)

What subscription do you have?

ChatGPT Pro (20x)

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Locked Computer Use consistently fails after macOS locks automatically because of display idle, even though Computer Use was working normally immediately before the lock.

The reported error is:

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

After this happens, all Computer Use operations fail, including app-independent operations such as listing running apps. The failures continue until I manually unlock the Mac.

This is specific to the idle-lock transition. If I manually lock the same Mac and then request a Computer Use operation, Locked Computer Use successfully performs its temporary unlock and can access Finder.

No local keyboard, mouse, or trackpad input occurred during the failing attempts.

What steps can reproduce the bug?

1. On an Apple Silicon Mac mini, enable Computer Use and Locked Computer Use.
2. Unlock the Mac and start a Codex task that uses Computer Use.
3. Verify that Computer Use can access an approved app such as Finder.
4. Leave the Mac without physical keyboard or pointer input and allow the display-idle policy to lock the session automatically.
5. After the idle lock occurs, request any Computer Use operation, such as listing apps or inspecting Finder.
6. Observe that automatic unlock waits and then fails with:

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

1. Retry Computer Use. Subsequent requests fail immediately until the Mac is manually unlocked.
2. As a control test, manually unlock the Mac, manually lock it again, and request the same Computer Use operation. In this case, Locked Computer Use works normally.

Affected session ID:
019fef6d-8785-7c60-bcdf-6981ea75fbe2

Feedback ID:
019fef6d-8785-7c60-bcdf-6981ea75fbe2

Token limit and context-window usage do not appear relevant. The failure is tied to the macOS lock transition and has reproduced across separate sessions.

What is the expected behavior?

When Locked Computer Use is enabled, Computer Use should be able to perform its protected temporary unlock after either a manual lock or an automatic idle lock.

An active Computer Use task should continue after the Mac idle-locks without requiring the user to manually unlock it, provided that no local keyboard or pointer input has interrupted the trusted Locked Use session.

Additional information

Environment details:

• Hardware: Mac mini M4, model identifier Mac16,10
• macOS: 26.6.1 (25G76)
• Architecture: arm64
• Codex App: 26.803.61601 (build 6396)
• Computer Use helper: 26.804.1000633 (build 1000633)
• Locked Computer Use: enabled
• Computer Use works normally while the session is unlocked
• Manual locking does not reproduce the failure

Relevant unified-log sequence from a reproduction on August 11, 2026 (UTC+8):

• 14:34:21.924: The SkyComputerUseService UserIsActive assertion timed out after 10 minutes.
• 14:34:32.875: loginwindow started an automatic lock with kLWLockFromDisplayDim (reason 5).
• 14:34:33.046: loginwindow completed loading the lock-screen UI.
• 14:34:33.067: CUALockScreenGuardian began the Locked Use attempt.
• 14:34:33.068: loginwindow began initializing the authentication services that allow automatic unlock, approximately 1 ms after the Guardian attempt began.
• 14:34:53.312: The Guardian attempt completed unsuccessfully after approximately 20 seconds.
• No corresponding authd authorization-mechanism or OpenAI authorization-plugin invocation appeared during this attempt.
• Later Computer Use requests at approximately 14:36:39 and 14:37:14 failed immediately.

This timing suggests a race between CUALockScreenGuardian and loginwindow authentication-service initialization during an idle-triggered lock.

The Computer Use service remained running and successfully communicated with its backend during the failure window, so this does not appear to be a proxy or general network-connectivity failure.

This may be related to #32913, but the trigger and diagnostics are different. In #32913, the Mac is already idle-locked before a new Computer Use turn is started from a trusted phone/SSH connection, and the suspected issue is propagation of the trusted remote context.

In this case, Computer Use is already active and working when macOS automatically locks. The failure begins during the lock transition itself. Manually locking the same Mac does not reproduce the problem.