›_ Codex Issues
Codex Issues / #32913

Locked use fails for manual Computer Use turn started from trusted phone/SSH connection

Open 💬 4 comments Opened Jul 14, 2026 by sdbjbjghtd-hub
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Locked use fails to temporarily unlock a dedicated Mac mini for a manual Computer Use turn started from the ChatGPT phone app through an existing trusted ChatGPT Connections/SSH remote project.

This is not a scheduled task. The remote turn starts successfully and can execute commands on the Mac, but the first Computer Use request fails with:

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

Expected behavior

A manual Computer Use turn started from a trusted connected device should temporarily unlock the Mac through Locked use, operate the approved app, and preserve the locked-screen protections.

Actual behavior

The remote turn reaches the Mac and runs normally until Computer Use accesses a desktop app. Automatic unlock then fails immediately and requires a manual unlock.

Reproduction

  1. On a dedicated Apple-silicon Mac mini, enable Computer Use, Locked use, and "keep remote control awake while plugged in."
  2. Keep the Mac powered, awake, and logged into the user session, then allow the screen to idle-lock.
  3. From the ChatGPT phone app, open the existing trusted remote project connected to the Mini through ChatGPT Connections/SSH.
  4. Send a manual prompt in an existing thread that requires Computer Use to inspect an approved macOS app.
  5. Observe the automatic-unlock failure above.

No local keyboard, pointer, or trackpad input occurs during the attempt.

Environment

  • Mac mini, Apple silicon (arm64)
  • macOS 26.5.2 (25F84)
  • ChatGPT/Codex desktop app 26.707.41301 (5103)
  • Computer Use / authorization plug-in 26.708.1000366

Local diagnostics

  • Computer Use authorization installer reports OK: installed.
  • /Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle is present.
  • Installed authorization plug-in version matches the active Computer Use payload.
  • Plug-in and service are signed by Team ID 2DC432GLL2.
  • Authorization right com.openai.sky.CUAService.AuthorizationPlugin.remote exists and evaluates CodexComputerUseAuthorizationPlugin:allow.
  • SkyComputerUseService and CUALockScreenGuardian are running.
  • The Mac is on AC power; system sleep is disabled.
  • keepRemoteControlAwakeWhilePluggedIn = true.
  • The same phone-started turn successfully executes commands on the Mini, confirming that the trusted remote project itself is reachable.
  • Around the failure window, the desktop log reports refresh_remote_control_completed ... nextConnectionCount=0, despite the phone-started remote turn continuing to execute on the host.

Suspected area

This appears consistent with the trusted remote connection context not being propagated to, or recognized by, the Computer Use Locked-use authorization handshake. The connection is sufficient to run the turn on the host, but the unlock subsystem does not recognize the Computer Use request as an eligible active trusted turn.

Please let me know which additional diagnostic logs would be useful.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32396

Powered by Codex Action

sdbjbjghtd-hub · 1 month ago

Additional migration/identity detail that may be relevant:

This machine no longer has a separate /Applications/Codex.app; the only main desktop application is /Applications/ChatGPT.app. However, that ChatGPT-branded app still reports bundle identifier com.openai.codex, and its logs/state remain under Codex-named paths. The active helper is also still named Codex Computer Use.app.

Observed identities:

  • Main app path: /Applications/ChatGPT.app
  • Main app bundle ID: com.openai.codex
  • Main app version: 26.707.41301
  • Computer Use helper: Codex Computer Use.app version 26.708.1000366
  • No duplicate legacy /Applications/Codex.app is installed or running

The user has noticed other post-migration cases where a task initially behaves as if it is running in the legacy Codex surface, then succeeds after being reminded that Codex is now folded into the fuller ChatGPT app. This does not prove causality, but it may be worth checking whether the trusted phone/SSH connection is associated with the ChatGPT surface while the Locked-use authorization handshake still validates Codex-era host/session identity.

sdbjbjghtd-hub · 1 month ago

Additional concrete evidence from the desktop logs suggests this is not simply an omitted setup/reinstall step:

  • The desktop app was updated on July 10.
  • Remote Control was explicitly enabled again on July 11.
  • Immediately after enablement, the app reconciled from 0 to 3 saved remote connections.
  • Status reads for all three then failed with Connection for host ID ... not found, and each connection was set to disconnected.
  • In the current failure window, reconciliation reports 0 remote-control connections.
  • The current Computer Use authorization plug-in is nevertheless installed, correctly registered, and version-matched with the active helper.

This points more specifically to stale or broken remote-host registry/trust state: the phone can still reach and execute the thread on the Mac through the connection/SSH path, while the desktop Remote Control manager cannot resolve the corresponding saved host and Locked use does not receive an eligible trusted-connection context. Host IDs have been omitted from this public report.

bitdepthmedia · 5 days ago

Confirming the same failure on a newer Computer Use helper build.

Environment:

  • ChatGPT desktop: 26.818.41509 (build 6962)
  • Computer Use helper and installed authorization plug-in: 26.819.1000816
  • macOS 26.5.2 (25F84), Apple silicon

Reproduction:

  1. Enabled Locked use.
  2. Verified that the installed OpenAI authorization plug-in is signed, registered in system.login.screensaver, version-matched, and byte-identical to the plug-in bundled with the active Computer Use helper.
  3. From a connected device, started a fresh active request while the Mac was manually locked and invoked a Computer History/Computer Use status operation.
  4. Received: The Mac is locked and automatic unlock could not unlock it. Ask the user to unlock the Mac manually before continuing.

Controls attempted:

  • The same operation succeeds immediately while the Mac is unlocked.
  • Disabled and re-enabled Locked use to reinstall the plug-in.
  • Restarted macOS and repeated the connected-device test while locked; the same failure occurred.
  • No local keyboard or pointer input occurred during the locked tests.

This suggests that the plug-in installation/update path is healthy, but the trusted connected-device turn still fails during the lock-screen authorization handshake.