›_ Codex Issues
Codex Issues / #26415

Codex Desktop: Locked Computer Use hangs on macOS 26.6; SkyComputerUseService spins at high CPU

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

What version of the Codex App are you using?

Codex Desktop 26.601.21317 / build 3511

What subscription do you have?

Not specified

What platform is your computer?

macOS 26.6 build 25G5028f, Apple Silicon / arm64

Component

Codex Desktop app, Computer Use, Locked Computer Use / lock-screen operation

Summary

Locked Computer Use hangs when attempting to inspect Finder while the Mac is locked. The same Computer Use path works while unlocked after a full reboot. During the locked attempt, SkyComputerUseService stays alive but spins at high CPU with a large memory footprint, and a sample shows a recursive-looking stack in SkyComputerUseService.

This does not look like a normal macOS permission/setup failure: Accessibility and Screen Recording are granted, the Computer Use authorization plugin is installed, the lock-screen authorization rule is registered, and Computer Use works while unlocked.

This is related to #24086, but not an exact duplicate: that report returns cgWindowNotFound on a Mac mini M4 + Studio Display, while this report hangs indefinitely on a MacBook Pro built-in display and shows a high-CPU recursive stack in SkyComputerUseService.

Expected behavior

When Locked Computer Use is enabled and the Mac is locked, Codex should be able to continue the Computer Use flow, either by using the lock-screen authorization path or by returning a clear error. It should not hang indefinitely or leave SkyComputerUseService spinning.

Actual behavior

get_app_state for Finder succeeds while unlocked, including screenshot and accessibility tree. After locking the screen, the same get_app_state request never returns. After about two minutes:

  • macOS confirms the session is locked.
  • SkyComputerUseService is consuming about 38% CPU.
  • SkyComputerUseService has about 1.4 GB physical footprint / about 1.5 GB RSS.
  • Killing SkyComputerUseService causes the pending MCP request to return isError: true with remoteConnection.

Clean repro after full reboot

  1. Fully reboot the Mac.
  2. Launch Codex Desktop.
  3. Confirm Computer Use works while unlocked by calling get_app_state for Finder.
  4. Lock the Mac.
  5. From a mobile/remote continuation, request the same Finder get_app_state through Computer Use.
  6. Wait more than two minutes.

Observed: the request hangs indefinitely until SkyComputerUseService is killed.

Verified local state

  • Codex Desktop: 26.601.21317 / build 3511.
  • Computer Use helper app: com.openai.sky.CUAService, version 1.0, build 799.
  • Computer Use installer status:
OK: installed
  • Locked-session state during the failed request:
IOConsoleLocked = Yes
CGSSessionScreenIsLocked = Yes
  • Computer Use worked while unlocked immediately before locking:
Computer Use state (CUA App Version: 799)
App=/System/Library/CoreServices/Finder.app/ (bundleID com.apple.finder, ...)
Window: "Desktop", App: Finder.
  • During the locked hang:
SkyComputerUseService: ~38% CPU, ~1.4 GB physical footprint

Sample evidence

The post-reboot sample shows a repeated frame in SkyComputerUseService:

Process:         SkyComputerUseService
Identifier:      com.openai.sky.CUAService
Version:         1.0 (799)
Code Type:       ARM64
OS Version:      macOS 26.6 (25G5028f)
Physical footprint:         1.4G

Thread: com.apple.root.default-qos.cooperative
...
??? (in SkyComputerUseService) load address ... + 0x58fa48
??? (in SkyComputerUseService) load address ... + 0x58fa48
??? (in SkyComputerUseService) load address ... + 0x58fa48
...

I can provide the full sample output if useful. I have not attached it initially to avoid posting a large diagnostic file publicly before maintainers ask for it.

Earlier pre-reboot signal

Before rebooting, a locked attempt had the same user-visible behavior and also produced a log storm:

SkyComputerUseService: Unable to find display with ID 1.
UIElementTree<TransformedUIElement> log0060 201 200

That earlier run produced millions of repeated log0060 201 200 entries over a few minutes. The post-reboot run reproduced the hang/high-CPU/recursive-stack behavior, but did not reproduce the same log storm.

Why this looks like a bug rather than local settings

  • Finder get_app_state succeeds while unlocked after a clean reboot.
  • The Mac is truly locked during the failure.
  • The Computer Use authorization plugin reports installed.
  • The helper process is alive and reachable before lock.
  • No configuration profiles are installed.
  • Lock Screen setting was changed to require password immediately, and the failure still reproduces.
  • The failure occurs as a hung request with high CPU and a recursive SkyComputerUseService stack, not as a TCC denial or missing-plugin error.

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 1 month ago

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

  • #25788

Powered by Codex Action

heyobravo · 1 month ago

Adding Codex app /feedback ID for internal correlation: 019e932c-a888-7df0-9f8a-936d3c3742b0

heyobravo · 1 month ago

Update after today's Codex/Computer Use update: this still reproduces on Codex Desktop 26.602.30954 / build 3575 with Computer Use 1.0 (809) on macOS 26.6 (25G5028f).

Retest result:

  • Unlocked Finder get_app_state succeeds on Computer Use 809.
  • Locked Finder get_app_state still times out after 120 seconds.
  • macOS confirmed the session was actually locked: IOConsoleLocked = Yes, CGSSessionScreenIsLocked = Yes.
  • SkyComputerUseService again spun hot during the hang: about 35.7% CPU with 1.3G physical footprint.
  • The recursive-looking stack is still present, but the repeated app frame changed from the earlier build 799 offset +0x58fa48 to build 809 offset +0x5f20b4.
  • This run did not reproduce the earlier log0060 201 200 / Unable to find display with ID 1 log storm.

I captured a new full sample during the build 809 repro and can provide it if useful. I have not attached it initially to avoid posting a large diagnostic file publicly before maintainers ask for it.

heyobravo · 1 month ago

Update after Codex Desktop 26.602.71036 / build 3685:

Computer Use helper is still 1.0 (809), but the locked failure mode changed materially.

Additional context: the Mac under test is running macOS 27 developer beta 1.

Retest result:

  • Unlocked Finder get_app_state succeeds.
  • Locked Finder get_app_state no longer hangs or spins SkyComputerUseService.
  • It now fails immediately with: Computer Use server error -10005: cgWindowNotFound.
  • macOS confirms the session is locked: IOConsoleLocked = Yes, CGSSessionScreenIsLocked = Yes.
  • Retried after waiting 5 seconds and 15 seconds for the black-screen-to-lock-screen transition; both retries still returned cgWindowNotFound.
  • SkyComputerUseService remains healthy afterward, around 0.0-0.1% CPU and about 50-65 MB RSS.
  • No log0060 storm or “Unable to find display” log in these runs.

So the runaway CPU/memory hang appears resolved or avoided in this app build, but Locked Computer Use still fails while locked.

heyobravo · 1 month ago

Reporter-side update after additional local troubleshooting.

Environment now:

  • Codex Desktop 26.609.30741 / build 3808
  • Computer Use service/client/Guardian/auth plugin all 1.0 build 809
  • macOS 27.0 developer beta 1 / build 26A5353q

I found and corrected two local mismatches before retesting:

  • The installed CodexComputerUseAuthorizationPlugin.bundle was still build 799 while the bundled Computer Use bits were build 809. I refreshed it using the bundled installer, and the installed auth plugin is now build 809.
  • defaults read com.apple.screensaver askForPasswordDelay was 14400 even though the GUI had shown “Immediately” earlier. I set askForPassword=1 and askForPasswordDelay=0, then rebooted.

I also tested the hidden Guardian app permission hypothesis:

  • Manually added CUALockScreenGuardian.app / com.openai.sky.CUAService.guardian to Accessibility and Screen & System Audio Recording in System Settings.
  • TCC now shows auth_value=2 for Accessibility and ScreenCapture for both com.openai.sky.CUAService and com.openai.sky.CUAService.guardian. The main service also has Full Disk Access.

Retest result after reboot and those permission changes:

  • Unlocked Finder get_app_state succeeds.
  • While locked, get_app_state("loginwindow") succeeds and can read the lock screen/password field, so locked UI access is not completely unavailable.
  • While locked, Finder get_app_state still times out after 120s.
  • macOS confirms the session is locked: IOConsoleLocked = Yes, CGSSessionScreenIsLocked = Yes.
  • After the timeout, SkyComputerUseService is hot again at roughly 39% CPU, with sample physical footprint around 1.2G.
  • Sample summary: SkyComputerUseService 1.0 (809), macOS 27.0 (26A5353q), key thread in completeTask(swift::AsyncContext*, swift::SwiftError*) on com.apple.root.default-qos.cooperative, with repeated recursive-looking frames at service image offset 0x5f20b4 (load address ... + 0x5f20b4).

Additional methodology/app-target check:

  • Started from an unlocked session and confirmed normal Computer Use access to Calculator and TextEdit.
  • Then locked the Mac during the same active assistant turn and waited for macOS to report IOConsoleLocked = Yes / CGSSessionScreenIsLocked = Yes.
  • Locked Calculator get_app_state failed immediately with Computer Use server error -10005: cgWindowNotFound.
  • Locked TextEdit get_app_state also failed immediately with Computer Use server error -10005: cgWindowNotFound.
  • Locked loginwindow get_app_state still succeeded and returned a lock-screen screenshot/UI tree.
  • Locked Finder get_app_state then hung for the full 120s and left SkyComputerUseService spinning again, about 38% CPU with sample physical footprint around 1.1G.
  • The Finder-triggered sample again showed the same recursive-looking service image offset 0x5f20b4 under completeTask(swift::AsyncContext*, swift::SwiftError*).

Conclusion from my side: the stale auth plugin, password-delay setting, reboot state, missing Guardian Accessibility/ScreenCapture permissions, and Finder-specific targeting do not appear to explain the locked-session failure. Normal user-session apps behind the lock screen fail fast with cgWindowNotFound; Finder appears to be a separate hang/runaway path on top of that broader locked-app failure. Happy to provide the full samples privately if useful.

heyobravo · 1 month ago

Reporter-side update after Codex Desktop 26.611.61049 / build 3996 and Computer Use build 810.

Environment now:

  • Codex Desktop 26.611.61049 / build 3996
  • Computer Use app/service 1.0 build 810
  • CUALockScreenGuardian.app build 810
  • Bundled CodexComputerUseAuthorizationPlugin.bundle build 810
  • Installed CodexComputerUseAuthorizationPlugin.bundle build 810
  • macOS 27.0 developer beta 1 / build 26A5353q

Important setup note: immediately after this Codex update, the installed auth plugin was still build 809 while the bundled Computer Use bits were build 810. Before retesting, I refreshed the installed auth plugin using the bundled installer. It reported success, and the installed plugin now matches build 810.

Local settings/permission state before this retest:

  • askForPassword = 1
  • askForPasswordDelay = 0
  • system.login.screensaver includes com.openai.sky.CUAService.AuthorizationPlugin.remote and use-login-window-ui.
  • TCC rows show auth_value=2 for:
  • kTCCServiceAccessibility / com.openai.sky.CUAService
  • kTCCServiceScreenCapture / com.openai.sky.CUAService
  • kTCCServiceSystemPolicyAllFiles / com.openai.sky.CUAService
  • kTCCServiceAccessibility / com.openai.sky.CUAService.guardian
  • kTCCServiceScreenCapture / com.openai.sky.CUAService.guardian

Retest method:

  • Restarted SkyComputerUseService after refreshing the auth plugin.
  • Started Calculator and TextEdit while unlocked.
  • Confirmed unlocked Calculator and TextEdit get_app_state both succeed on Computer Use build 810.
  • Locked the Mac during the same active assistant turn, then waited about 45 seconds.
  • macOS confirmed the locked state: IOConsoleLocked = Yes, CGSSessionScreenIsLocked = Yes.

Locked retest result:

  • Locked Calculator get_app_state failed fast with Computer Use server error -10005: cgWindowNotFound.
  • Locked TextEdit get_app_state failed fast with Computer Use server error -10005: cgWindowNotFound.
  • Locked loginwindow get_app_state succeeded and returned the lock-screen screenshot/UI tree, including the password field.
  • Locked Finder get_app_state now also failed fast with Computer Use server error -10005: cgWindowNotFound.
  • After the locked Finder failure, SkyComputerUseService stayed healthy: roughly 0.0-0.1% CPU and about 75-90 MB RSS in the checks I ran after the test.

Interpretation from my side:

  • The core functional issue remains: user-session apps behind the lock screen are still unreachable while the Mac is locked.
  • The lock-screen UI itself remains reachable, so Computer Use is not completely blind while locked.
  • The earlier Finder-specific 120s timeout / hot SkyComputerUseService / recursive 0x5f20b4 runaway path appears fixed or at least avoided in the current app/helper combination. Finder now behaves like Calculator and TextEdit: fast cgWindowNotFound rather than a service hang.
  • Since the installed auth plugin, bundled auth plugin, Computer Use app, and Guardian are now all build 810, this retest should not be affected by the stale-plugin mismatch that existed briefly after the update.
heyobravo · 1 month ago

Retested after Codex Desktop 26.616.30709 / build 4108 with Computer Use, Guardian, and installed auth plugin all refreshed to build 829: locked Calculator/TextEdit/Finder still fail fast with Computer Use server error -10005: cgWindowNotFound, while locked loginwindow still succeeds. The earlier Finder 120s hang/runaway SkyComputerUseService path did not recur in this retest, but locked user-session app access remains broken.

heyobravo · 11 days ago

Some good news and some bad news.

tl;dr locked computer use is working now! But it did something that is not so great, security-wise.

—

Security-relevant update after today's merged ChatGPT/Codex release: Locked Computer Use is now functionally working, but this retest exposed a serious guardian/relock failure.

Environment:

  • ChatGPT/Codex app 26.707.30751, build 5018
  • Computer Use and CUALockScreenGuardian 26.708.1000362, build 1000362
  • macOS 27.0 (26A5378j)
  • Screen-lock policy independently verified as immediate: screenLock delay is immediate, askForPassword=1, askForPasswordDelay=0

Observed sequence:

  1. I manually locked the Mac and verified IOConsoleLocked=Yes and CGSSessionScreenIsLocked=Yes.
  2. Computer Use started CUALockScreenGuardian, and the physical display showed “Codex is Using Your Mac.” The guardian overlay was visibly duplicated several times.
  3. User-session automation now worked behind the guardian: Calculator accepted a real click, TextEdit and Finder were accessible, Finder returned in 212 ms, and Dictionary launched fresh while locked.
  4. I did not touch the Mac at all. I was interacting only from my phone.
  5. The guardian then disappeared on its own and exposed the authenticated desktop with no password or Touch ID prompt.

This was not caused by the old password-delay setting; the immediate-password policy was confirmed immediately after the incident. The observed timing suggests a possible teardown/relock failure: the user session was auto-unlocked behind the guardian, then the guardian disappeared without the real macOS lock being restored. That is an inference, not a confirmed root cause.

Additional observations:

  • The prior cgWindowNotFound and Finder hang are resolved in this build.
  • SkyComputerUseService stayed near 52 MB RSS, but used roughly 20-22% CPU while the guardian was active.
  • The duplicated guardian display correlated with 609 repeated VTDecompressionSessionDecodeFrameWithOptions / kVTParameterErr log events.
  • I captured a photo, a focused unified-log archive, and a written timeline. I am not posting the photo/log archive publicly, but can provide them privately to maintainers.
  • OpenAI Support case: 10467799
  • Feedback ID: 019e932c-a888-7df0-9f8a-936d3c3742b0

Because the Mac became physically accessible while unattended, I am treating Locked Access as unsafe to use until this is investigated.

heyobravo · 7 days ago

Update after installing the latest ChatGPT/Codex and Computer Use builds: I can no longer reproduce either the original locked-use failure or the guardian/relock security regression, and I am happy to consider this fixed on my machine.

Environment:

  • ChatGPT/Codex 26.707.62119, build 5211
  • Computer Use and CUALockScreenGuardian 26.710.1000387, build 1000387
  • macOS 27.0 (26A5378j)
  • Immediate authentication remains enforced: askForPassword=1, askForPasswordDelay=0

Fresh controlled retest:

  • Unlocked Finder control succeeded in 415 ms.
  • After locking the Mac during the same active turn, the guardian appeared normally with a single "ChatGPT is Using Your Mac" display.
  • Finder remained accessible behind the guardian, returned in 468 ms, and accepted a real interaction by opening the Go menu.
  • At Computer Use completion, macOS restored a genuine locked state (IOConsoleLocked=Yes); the physical display returned to the normal lock screen/screensaver.
  • Pressing the Right Arrow key produced the normal password prompt rather than exposing the desktop.
  • The test produced no cgWindowNotFound, UIElementTree ... log0060 201 200, or prior video-decompression error signatures.

This was one controlled retest, but it completed the full functional and relock/authentication flow cleanly. Locked Computer Use is now working as expected on this configuration.