Codex Desktop: locked computer use cannot be enabled on macOS Intel due to native component signing errors

Additional related symptom: the Appshot hotkey (DoubleCommand, pressing both Command keys simultaneously) also fails on the same machine/version.

The hotkey registration and keypress detection work, so this does not appear to be a keyboard shortcut conflict:

Registering appshot hotkey hotkey=DoubleCommand
Registered appshot hotkey hotkey=DoubleCommand
Appshot hotkey pressed hotkey=DoubleCommand
Dispatching appshot hotkey target=existing-chat windowId=1
[electron-message-handler] Appshot shortcut received
[electron-message-handler] Appshot shortcut found target bundleIdentifier=com.mitchellh.ghostty frontmostWindowElapsedMs=6 name=Ghostty
[electron-message-handler] Appshot capture request created ... source=hotkey
[electron-message-handler] Appshot capture start request sent ... source=hotkey

The failure occurs when the Computer Use capture worker tries to spawn the managed Computer Use service:

[computer-use-capture-handler] Codex Computer Use capture worker failed errorMessage="Failed to spawn managed Computer Use service" ... requestId=...
[electron-message-handler] Appshot capture update received ... updateType=failed
[electron-message-handler] Appshot capture settled ... hadAxText=false hadScreenshot=false ... status=failed

The UI toast for this case is:

Unable to attach appshot

This seems to be the same underlying managed Computer Use service startup failure as the locked computer use setting issue.

Proposed Solution: Computer Use macOS Intel Signing Fix

Root Cause

The locked computer use native helper component is not signed as a universal binary. On Intel Macs, Gatekeeper rejects the component because it lacks the x86_64 architecture slice and/or required entitlements (com.apple.security.cs.disable-library-validation, com.apple.security.automation.apple-events).

Fix

Rebuild helper as universal binary with correct entitlements:

codesign --force --sign "$DEVELOPER_ID" --entitlements helper.entitlements \
  --options runtime --timestamp \
  "Codex.app/Contents/Library/LaunchServices/com.openai.codex.computer-use-helper"
lipo -info helper  # Verify: x86_64 arm64

Impact

• Severity: High - locked computer use unavailable on Intel Macs
• Scope: All Intel Mac users of Codex Desktop

Testing

1. Verify helper binary contains both x86_64 and arm64 slices
2. Enable locked operation on Intel Mac - verify no signing error

Full solution: solutions/codex-24207-computer-use-macos-intel-signing-fix.md

I can reproduce this on a newer Intel build too, but I think there’s a more specific signing/provisioning mismatch hiding under the floorboards here.

Setup:

Codex Desktop: 26.602.40724
CFBundleVersion: 3593
macOS: 26.5.1
Arch: x86_64 / Intel

At least on my box, this does not look like the native bits are simply missing the Intel slice.

These are x86_64 and pass codesign:

/Applications/Codex.app/Contents/Resources/native/browser-use-peer-authorization.node
/Applications/Codex.app/Contents/Resources/codex

Both Codex.app and /Applications/Codex.app/Contents/Resources/codex declare this entitlement:

com.apple.security.application-groups =
2DC432GLL2.com.openai.sky.CUAService

But when I dumped the embedded provisioning profile, that App Group is not there.

security cms -D -i /Applications/Codex.app/Contents/embedded.provisionprofile > /tmp/codex_profile.plist
/usr/libexec/PlistBuddy -c "Print :Entitlements" /tmp/codex_profile.plist

Output:

keychain-access-groups = 2DC432GLL2.*
com.apple.application-identifier = 2DC432GLL2.com.openai.codex
com.apple.developer.team-identifier = 2DC432GLL2

No com.apple.security.application-groups.

Then macOS starts yelling this when Locked Use is toggled:

Entitlement com.apple.security.application-groups=(
    "2DC432GLL2.com.openai.sky.CUAService"
) is ignored because of invalid application signature or incorrect provisioning profile

So I don’t think this is only “Intel helper bad” or “missing TCC permission”. The binary asks for the sky.CUAService App Group, but the embedded profile does not bless that App Group. trustd sees the mismatch, ignores the entitlement at runtime, and the Computer Use / Locked Use flow falls over.

The fix probably needs to happen in the Intel packaging/signing pipeline: ship the build with an embedded provisioning profile that actually includes:

com.apple.security.application-groups =
2DC432GLL2.com.openai.sky.CUAService

or make the Intel Computer Use path stop depending on that App Group.

Basically: the entitlement is in the binary, but not in the papers. macOS checks the papers, sees the mismatch, and kills the vibe.

This looks related but not identical to what I’m seeing on Intel. In this arm64 report, the helper/plugin seems installed and signed, then the failure happens at locked-session GUI attach time. On Intel, I’m seeing the failure earlier: trustd ignores the sky.CUAService App Group entitlement because the embedded provisioning profile does not include that app group.

I can reproduce this on a newer Intel macOS build as well.

Environment

• macOS: 15.7.7 (24G720)
• Architecture: x86_64 / Intel Mac
• Codex Desktop: 26.611.62324
• CFBundleVersion: 4028
• Bundle identifier: com.openai.codex
• App path: /Applications/Codex.app

UI state

In Codex Settings > Computer Use, I only see:

• Google Chrome control, enabled
• Locked Computer Use / lock-screen operation, disabled
• "Always allowed apps": none

The full Computer Use app/plugin does not appear to be available, and the Locked Computer Use toggle cannot be enabled.

Diagnostics

Deep/strict verification still fails on this newer x86_64 build:

$ codesign --verify --deep --strict --verbose=4 /Applications/Codex.app
/Applications/Codex.app: invalid signature (code or signature have been modified)
In architecture: x86_64

The native components also fail validation:

$ codesign --verify --verbose=4 /Applications/Codex.app/Contents/Resources/native/remote-control-device-key.node
/Applications/Codex.app/Contents/Resources/native/remote-control-device-key.node: invalid signature (code or signature have been modified)
In architecture: x86_64

$ codesign --verify --verbose=4 /Applications/Codex.app/Contents/Resources/native/browser-use-peer-authorization.node
/Applications/Codex.app/Contents/Resources/native/browser-use-peer-authorization.node: invalid signature (code or signature have been modified)
In architecture: x86_64

$ codesign --verify --verbose=4 /Applications/Codex.app/Contents/Resources/native/bare-modifier-monitor
/Applications/Codex.app/Contents/Resources/native/bare-modifier-monitor: invalid signature (code or signature have been modified)
In architecture: x86_64

This looks like the same Intel macOS signing/Gatekeeper issue originally reported here, but still present in Codex Desktop 26.611.62324 / build 4028.

I’m seeing the same issue on an Intel Mac.

Codex Desktop is updated to the latest version as of June 27, 2026. Chrome Computer Use appears connected, but Locked Computer Use cannot be enabled. The toggle fails with “Unable to update Locked operation setting.”

All relevant macOS permissions are already enabled:

• Accessibility
• Screen Recording
• Full Disk Access
• Files/Folders access

I restarted Codex and rebooted the Mac, but the issue persists.

This does not look like a missing TCC permission. It looks like the Intel / x86_64 native component issue described here.

Can OpenAI confirm whether Locked Computer Use is officially supported on Intel Macs, and what the minimum macOS version is?