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
SkyComputerUseClientcommand-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.1build25F80 - 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
- Enable Computer Use in Codex settings.
- Enable locked computer use.
- Confirm the locked-use authorization plugin exists under
/Library/Security/SecurityAgentPlugins/. - Lock the Mac.
- Confirm the session is actually locked using
CGSessionCopyCurrentDictionary:
CGSSessionScreenIsLocked=1
kCGSSessionSecureInputPID=400
- 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.
- Use Computer Use against Chrome:
mcp__computer_use.get_app_state({ app: "com.google.Chrome" })
Observed repeatedly:
Computer Use server error -10005: cgWindowNotFound
- Try alternate app/control paths while locked.
Observed:
mcp__computer_use.get_app_state({ app: "Finder" })timed out after 120s.- Chrome DevTools
list_pagestimed 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 withcgWindowNotFound.
- 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:
앱인토스 - 토스에 미니앱 출시하고 수익 만들기
- Restart
SkyComputerUseServiceand 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
loginwindowwhile 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 mcphelper processes and measurablesyspolicyd/trustdCPU 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 openedsystem error due to Locked use in Codex.app. - #25719: macOS
syspolicyd/trustdrunaway 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
syspolicydfile descriptors. - #25809: plugin / Computer Use attach instability after restart.
- #21846 and #24207: Computer Use helper signing / registration failures, although my current local helper passes
codesignandspctl.
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.
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗