openai / openai/codex

Locked Use fails on macOS 26.6.2: SecurityAgentHelper rejects Codex authorization plugin

Open
#45,668 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug computer-use remote
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What version of the Codex App are you using (From “About Codex” dialog)?

26.908.70816

What subscription do you have?

Plus

What platform is your computer?

macOS 26.6.2 (25G83), Apple Silicon

What issue are you seeing?

Locked Use does not automatically unlock the Mac for a Computer Use task started from a connected device.

Computer Use works while the Mac is unlocked. When the Mac is locked, a new @Computer task from the connected device detects the locked state but asks me to unlock the Mac manually.

Environment:

  • macOS: 26.6.2 (25G83), Apple Silicon
  • ChatGPT/Codex App: 26.908.70816 (build 9275)
  • Installed authorization plugin: 26.913.1001067 (build 1001067)
  • Bundled authorization plugin: 26.913.1001067 (build 1001067)
  • Installed/bundled plugin SHA-256: identical
  • Plugin TeamIdentifier: 2DC432GLL2
  • codesign --verify --deep --strict: succeeds

The authorization plugin is installed at:

/Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle

The authorization mechanism is registered as:

com.openai.sky.CUAService.AuthorizationPlugin.remote
→ CodexComputerUseAuthorizationPlugin:allow

During a reproduction, unified logs show that the authorization flow reaches authd and SecurityAgentHelper, but SecurityAgentHelper fails while loading the plugin:

"mapping process is a platform binary, but mapped file is not"

authd subsequently attempts:

CodexComputerUseAuthorizationPlugin:allow

There is no log evidence that the plugin code itself returns allow or deny; it appears to fail during loading.

I also observed repeated trustd warnings about the CUAService app-group entitlement being ignored due to signature/provisioning-profile conditions. However, containermanagerd reports the corresponding group-container access as approved.

SkyComputerUseService remains operational and completes its network request successfully (HTTP 202).

No authorizationdb, SIP, Library Validation, plugin signature, or other macOS security settings were manually modified.

What steps can reproduce the bug?
  1. Enable Computer Use and Locked Use in the ChatGPT/Codex macOS app.
  2. Verify Screen Recording and Accessibility permissions are granted.
  3. Keep the ChatGPT/Codex desktop app running.
  4. Connect another device for remote Computer Use.
  5. Lock the Mac with Control-Command-Q.
  6. Do not provide any local keyboard, mouse, or trackpad input.
  7. From the connected device, start a NEW Computer Use task after the Mac is already locked.
  8. Send a simple task such as:
    "@Computer open Finder and show the Downloads folder."
  9. Computer Use detects that the Mac is locked, but responds that the Mac must be manually unlocked.
  10. Inspect unified logs around the attempt.

Observed log behavior:

  • authd begins the authorization flow.
  • SecurityAgentHelper-arm64 attempts to dlopen the Codex authorization plugin.
  • macOS reports:
    "mapping process is a platform binary, but mapped file is not"
  • authd attempts mechanism:
    CodexComputerUseAuthorizationPlugin:allow
  • No successful execution/allow result from the plugin is observed.
What is the expected behavior?

A Computer Use task started from an authorized connected device after the Mac is locked should invoke the Locked Use authorization mechanism and temporarily unlock the Mac as documented, allowing the Computer Use task to proceed without requiring a manual unlock.

Additional information

This appears related to #44940.

Notably, my installed authorization plugin and the plugin bundled with the app are already the same version/build (26.913.1001067 / 1001067) and have identical SHA-256 hashes, so this reproduction does not appear to be caused by an outdated or stale installed plugin.

The plugin is correctly installed, registered, OpenAI-signed, and signature verification succeeds.

I can provide sanitized unified-log excerpts around the failed authorization attempt if useful.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the locked Computer Use flow and inspect unified logs around SecurityAgentHelper-arm64 loading /Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle. Compare the behavior with related issue #44940 and verify the registered CodexComputerUseAuthorizationPlugin:allow mechanism. Done means an authorized connected-device task temporarily unlocks the Mac without manual input.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos
Domain
operating-systems, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.