›_ Codex Issues
Codex Issues / #33471

Locked Computer Use cannot be interrupted through Apple Screen Sharing despite “Press any key or click to unlock”

Open 💬 0 comments Opened Jul 16, 2026 by liujin231011

What version of the Codex App are you using?

  • ChatGPT/Codex Desktop: 26.707.72221 (build 5307)
  • Computer Use helper: 26.710.1000387 (build 1000387)

What subscription do you have?

Not specified.

What platform is your computer?

Computer Use host

  • Mac mini (Mac14,3), Apple M2, 24 GB
  • macOS 26.5.2 (25F84)

Screen Sharing client

  • MacBook Pro (MacBookPro18,1), Apple M1 Pro
  • macOS 26.5.1 (25F80)
  • Apple Screen Sharing 6.1 (760.4)

Component

Codex Desktop app, Computer Use, Locked Computer Use, CUALockScreenGuardian, Apple Screen Sharing.

Summary

When Computer Use is active on a headless Mac mini, Apple Screen Sharing shows the Locked Computer Use overlay:

ChatGPT is Using Your Mac Press any key or click to unlock

However, keyboard and mouse input sent through Apple Screen Sharing does not interrupt Computer Use or reveal the normal macOS password screen. The Screen Sharing toolbar's Control Screen toggle is on, but clicking the shared screen or pressing Return produces no UI state change.

This is particularly problematic for a headless Mac mini: the UI promises that any key or click will unlock it, but the only available remote keyboard/mouse path is ignored, leaving the user without a visible recovery action in Screen Sharing.

The Locked Computer Use overlay itself appears intentional. The issue is the remote interruption/recovery path and the wording that does not distinguish physical HID input from Apple Screen Sharing input.

What steps can reproduce the bug?

  1. Use a Mac mini as a headless Codex/Computer Use host.
  2. Connect to it from another Mac with Apple's built-in Screen Sharing app.
  3. Start or continue a Codex task that invokes Computer Use.
  4. Observe the remote host display switch to the ChatGPT is Using Your Mac overlay.
  5. Confirm Control Screen is enabled in Screen Sharing.
  6. Click the overlay and press keyboard keys such as Return.
  7. Observe that the overlay remains and no normal password/unlock UI appears.

In the observed session, both attempts produced no accessibility-tree or visual state change.

What is the expected behavior?

One of the following:

  1. Apple Screen Sharing keyboard/mouse input should interrupt Locked Computer Use, matching the displayed promise; or
  2. the overlay should explicitly say that a physical keyboard/mouse is required and provide a visible remote Stop/Take Over path; or
  3. Apple Screen Sharing should show a deterministic error explaining why remote interruption is unsupported.

A headless Mac should not enter a soft-lockout state with an instruction that cannot be fulfilled through the active control channel.

What actually happened?

  • The Locked Computer Use overlay remained visible.
  • Apple Screen Sharing reported the remote Mac as locked.
  • Remote click and Return input had no effect.
  • CUALockScreenGuardian, the task's cua_node kernel, and its app-server were still running.
  • The main ChatGPT/Codex app had not crashed.
  • The session had been active for about 25 minutes when inspected.

This did not look like a Codex main-process crash. It looked like an input-source/revocation mismatch: Locked Computer Use continued operating, while Apple Screen Sharing could observe the overlay but could not revoke control.

Runtime evidence

Around the failure/recovery window, macOS unified logs repeatedly reported display errors from ChatGPT and SkyComputerUseService:

ChatGPT: invalid display identifier <private>
ChatGPT: Invalid new timing data reported for display 0x0000000c.
SkyComputerUseService: Invalid new timing data reported for display 0x0000000c.
SkyComputerUseService: Received delta ... AppKit will assert if these are also invalid

These messages may be related to the Screen Sharing/virtual-display transition; I am not claiming they are the proven root cause.

The signed helper binary also exposes the symbol/string lockScreenGuardianDetectedPhysicalInput, which is consistent with the observed difference between physical input and Screen Sharing-generated input.

Recovery workaround

Because SSH was available, I terminated only the active Computer Use session processes and then the associated CUALockScreenGuardian. The normal macOS password screen immediately returned. The main ChatGPT/Codex app and unrelated tasks remained running; a full reboot was not required.

For users without SSH or physical input, the current state may require a hard reboot.

Related issues

  • #26415 — Locked Computer Use hangs/high CPU. Related component, but this report is about Apple Screen Sharing takeover input being ignored while the task remains alive.
  • #32913 — trusted phone/SSH locked-use auto-unlock failure. Related recovery area, but a different trigger and failure.
  • #20556 — Computer Use and ScreenCaptureKit interaction causing unresponsive input. Adjacent macOS display/input behavior, but not the same reproduction.

I can provide a redacted screenshot and a narrowly filtered unified-log excerpt if maintainers need them.

View original on GitHub ↗