macOS Locked Computer Use exits before password field appears after display-sleep lock

Open 💬 1 comment Opened Aug 6, 2026 by danieltty

Summary

Locked Computer Use intermittently cannot unlock macOS after a display-sleep lock, although automatic unlocking works when the session was locked directly.

The lock-screen guardian checks the accessibility tree and exits with didUnlock=false immediately before loginwindow exposes the password field.

Environment

  • ChatGPT desktop app: 26.730.61639 (6234)
  • Computer Use service: 26.803.1000621 (1000621)
  • macOS: 27.0 (26A5388g)
  • Architecture: arm64
  • Hardware: Mac mini
  • Computer Use service remained running throughout the incident

Steps to reproduce

  1. Enable Locked Computer Use.
  2. Leave macOS awake while allowing the display to sleep naturally.
  3. Let loginwindow create a display-dim lock.
  4. Start a Computer Use request remotely.
  5. Computer Use wakes the logical display but reports that automatic unlock failed and asks for a manual unlock.

Expected behavior

After waking the display, Locked Computer Use should wait for loginwindow to finish presenting the password field and then perform its normal authorized unlock flow.

Actual behavior

The guardian finishes before the password field becomes available. It does not submit Return and the authorization plugin is never invoked.

A fresh observed sequence was:

  • 14:36:11.313 — display wake begins
  • 14:36:11.320 — guardian begins accessibility/UI collection
  • 14:36:11.349 — guardian exits normally with didUnlock=false
  • 14:36:11.369 — loginwindow exposes the usable password field

The password field appeared approximately 20 ms after the guardian exited.

The same behavior occurred on multiple attempts. There was no credential rejection: no key submission occurred and the SecurityAgent authorization mechanism was not invoked.

Lock-state difference

Successful automatic unlocks woke from:

  • kLWLockFromDirectLock (8)

Failures woke from:

  • kLWLockFromDisplayDim (5)

This explains why Locked Computer Use worked earlier while the physical monitor was off, but later stopped working after natural display sleep created a different loginwindow transition.

Additional diagnostic evidence

The bundled SystemLockScreenController is constructed with:

  • Overall timeout: 10 seconds
  • Poll interval: 250 ms
  • Submit delay: 500 ms
  • Verification delay: 2 seconds

The lock monitor has 1.5-second settle and 3-second fallback delays.

However, the failing path exits after roughly 29 ms, so it appears to return before those retry/settle timings are applied.

Suggested fix

When macOS is locked but UserPasswordTextField is temporarily absent, treat that state as transitional rather than as a completed unlock failure:

  1. Wait up to 1–2 seconds for the password field.
  2. Poll every 50–100 ms or observe the appropriate accessibility notification.
  3. Continue with the authorized unlock after the field appears.
  4. Do not count an attempt until a key submission/authentication attempt actually occurs.

The observed case would have succeeded with even one short retry because the field appeared only 20 ms after the guardian exited.

View original on GitHub ↗

1 Comment

Skywt2003 · 17 days ago

I can confirm the same issue on a newer Computer Use build and on macOS 26.6.1 stable.

Environment:

  • Mac mini M4 (Mac16,10), arm64
  • macOS 26.6.1 (25G76)
  • Codex App 26.803.61601 (6396)
  • Computer Use 26.804.1000633 (1000633)

The same lock-state distinction is reproducible:

  • Manual/direct lock: Locked Computer Use works.
  • Idle display lock (kLWLockFromDisplayDim (5)): automatic unlock fails and requires a manual unlock.

In my reproduction, Computer Use was already active and working when the idle lock occurred. The relevant timing was:

  • 14:34:32.875 — loginwindow began kLWLockFromDisplayDim (5).
  • 14:34:33.046 — lock-screen UI loading completed.
  • 14:34:33.067 — CUALockScreenGuardian began the Locked Use attempt.
  • 14:34:33.068 — loginwindow began initializing the authentication services, approximately 1 ms after the Guardian attempt began.
  • About 20 seconds later, the unlock attempt failed.
  • No corresponding authd authorization-mechanism or OpenAI authorization-plugin invocation appeared.
  • Subsequent Computer Use requests failed immediately until I manually unlocked the Mac.

This appears to be the same transitional loginwindow race described here, although the newer build waits about 20 seconds before reporting failure instead of exiting after approximately 29 ms.

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