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

Start by locating the bundled SystemLockScreenController and the lock-screen guardian path that handles UserPasswordTextField, then reproduce the kLWLockFromDisplayDim transition while tracing accessibility collection. Done means the guardian waits for the password field on this path, proceeds through the authorized unlock flow, and does not report failure before an authentication attempt.

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.