Codex Desktop: Locked Computer Use stays on loginwindow; app GUI access returns cgWindowNotFound while locked

Summary

Locked Computer Use appears to be enabled and the Computer Use helper is installed, but when the Mac is actually locked, Codex Computer Use can see only loginwindow. Attempts to access allowed desktop apps such as Chrome do not appear to trigger the temporary locked-use unlock path. Instead, app GUI access returns cgWindowNotFound or times out.

The target Chrome process and page were alive during the test. I could query and navigate Chrome through AppleScript while the macOS session was locked. That points away from a target-app/page failure and toward the locked-use GUI attach / temporary unlock path.

I am not sure whether this exact Codex surface is expected to qualify as a "connected device" locked-use turn. If it is not eligible, the current failure mode is still confusing: loginwindow remains accessible, while app access silently fails with cgWindowNotFound instead of reporting that locked-use is unavailable from this surface.

Privacy / redaction note

I intentionally removed or normalized local personal details:

• Home directory paths are written as ~.
• Raw SkyComputerUseClient command-line arguments are not included because they may contain thread context.
• GitHub account details, tokens, full process command payloads, and unrelated app/window contents are omitted.
• The public URL used for a liveness check is included only because it was a public website and not private data.

Environment at time of locked-use reproduction

• Date observed: 2026-06-03 KST
• macOS: macOS 26.x, arm64. I did not capture the exact build during the locked test.
• Codex Desktop: 26.601.21317
• Codex build: 3511
• Computer Use helper / CUA app version observed by Computer Use: 799
• Locked-use authorization plugin installed at:
• /Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle
• Bundle ID: com.openai.sky.CUAService.AuthorizationPlugin
• CFBundleVersion: 799
• Target app: Google Chrome

Current local diagnostics after updating Codex

As of 2026-06-06, the machine has since updated, so these are current diagnostics rather than the exact locked reproduction version:

• macOS: 26.5.1 build 25F80
• Architecture: arm64
• Codex Desktop: 26.602.40724
• Codex build: 3593
• Computer Use helper bundle:
• Bundle ID: com.openai.sky.CUAService
• CFBundleShortVersionString: 1.0
• CFBundleVersion: 809
• Computer Use client bundle:
• Bundle ID: com.openai.sky.CUAService.cli
• CFBundleShortVersionString: 1.0
• CFBundleVersion: 809
• Locked-use auth plugin:
• Bundle ID: com.openai.sky.CUAService.AuthorizationPlugin
• CFBundleShortVersionString: 0.1.0
• CFBundleVersion: 799

Current helper architectures match the arm64 machine:

~/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService: Mach-O 64-bit executable arm64
~/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient: Mach-O 64-bit executable arm64
/Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle/Contents/MacOS/CodexComputerUseAuthorizationPlugin: Mach-O 64-bit bundle arm64

The local helper currently passes signing/Gatekeeper checks:

~/.codex/computer-use/Codex Computer Use.app: valid on disk
~/.codex/computer-use/Codex Computer Use.app: satisfies its Designated Requirement
~/.codex/computer-use/Codex Computer Use.app: accepted
source=Notarized Developer ID

Current non-locked session state reports:

CGSSessionScreenIsLocked=nil
kCGSSessionSecureInputPID=nil

Current plugin/cache path observations:

exists  ~/.codex/computer-use/Codex Computer Use.app
missing ~/.codex/plugins/cache/openai-bundled/computer-use
exists  /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use
exists  /Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle

Current ~/.codex/config.toml references, sanitized:

notify = ["~/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient", "turn-ended"]

[mcp_servers.computer-use]
command = "~/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient"

Readable TCC DB search did not return matching rows for com.openai, Codex, or sky in either user or system TCC DB. This may be a query limitation or because the relevant authorization state is tracked elsewhere:

~/Library/Application Support/com.apple.TCC/TCC.db: no matching rows from query
/Library/Application Support/com.apple.TCC/TCC.db: no matching rows from query

Current process summary, sanitized and summarized rather than pasted raw:

SkyComputerUseService_count=1
SkyComputerUseClient_mcp_count=15
syspolicyd_cpu=7.1
trustd_cpu_total=5.9

A larger sample a few minutes earlier showed syspolicyd around 16.8% CPU, trustd around 6.0% CPU, and 18 SkyComputerUseClient mcp processes. Raw command-line arguments are omitted/redacted.

Reproduction steps used

1. Enable Computer Use in Codex settings.
2. Enable locked computer use.
3. Confirm the locked-use authorization plugin exists under /Library/Security/SecurityAgentPlugins/.
4. Lock the Mac.
5. Confirm the session is actually locked using CGSessionCopyCurrentDictionary:

CGSSessionScreenIsLocked=1
kCGSSessionSecureInputPID=400

1. Use Computer Use against loginwindow.

Observed: loginwindow is visible and accessible. Computer Use sees the lock screen, focused user, password field, and Touch ID/password prompt.

1. Use Computer Use against Chrome:

mcp__computer_use.get_app_state({ app: "com.google.Chrome" })

Observed repeatedly:

Computer Use server error -10005: cgWindowNotFound

1. Try alternate app/control paths while locked.

Observed:

• mcp__computer_use.get_app_state({ app: "Finder" }) timed out after 120s.
• Chrome DevTools list_pages timed out after 120s.
• mcp__computer_use.get_app_state({ app: "loginwindow" }) remained responsive.
• mcp__computer_use.press_key({ app: "com.google.Chrome", key: "super+l" }) also failed with cgWindowNotFound.

1. Verify Chrome was alive independently while the session was locked.

AppleScript could query and navigate the active Chrome tab. For example, it loaded a public URL:

https://toss.im/apps-in-toss

and returned the expected page title:

앱인토스 - 토스에 미니앱 출시하고 수익 만들기

1. Restart SkyComputerUseService and retry.

Observed: service PID changed after restart, but Computer Use still returned cgWindowNotFound for Chrome while locked.

Expected behavior

If locked Computer Use is enabled and an active trusted Computer Use turn accesses an allowed desktop app while the Mac is locked, Codex should temporarily unlock the desktop behind its local-use protections and allow GUI inspection/control of the target app.

If this surface is not eligible for locked use, Codex should report that clearly instead of returning cgWindowNotFound for the app while loginwindow is still visible.

Actual behavior

• Computer Use can inspect only loginwindow while locked.
• Chrome/Finder GUI access does not trigger visible locked-use temporary unlock behavior.
• Chrome returns cgWindowNotFound; Finder can time out.
• The target Chrome process and page are alive and scriptable outside the Computer Use GUI path.
• Current post-update diagnostics also show multiple long-lived SkyComputerUseClient mcp helper processes and measurable syspolicyd / trustd CPU activity.

Related issues that may overlap

This issue may be a distinct symptom of the same macOS Computer Use helper / Gatekeeper / process lifecycle area:

• #25243: Too many files opened system error due to Locked use in Codex.app.
• #25719: macOS syspolicyd / trustd runaway related to Codex Computer Use helper validation.
• #25744: Codex for macOS accumulates Computer Use / MCP helper processes and unreaped children.
• #25882: Codex macOS app relaunch loop exhausting syspolicyd file descriptors.
• #25809: plugin / Computer Use attach instability after restart.
• #21846 and #24207: Computer Use helper signing / registration failures, although my current local helper passes codesign and spctl.

Notes

I did not enter any password or attempt to bypass macOS authentication manually. The goal was to test the documented locked-use flow and distinguish whether the Mac was truly locked from whether the target app was alive.

If the intended product boundary is that locked-use only works from a narrower connected-device flow, a clearer diagnostic would help: something like locked computer use is not available from this session/surface instead of cgWindowNotFound for every non-loginwindow app.