Skip to content

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

Open
Open
Codex Desktop: locked computer use cannot be enabled on macOS Intel due to native component signing errors#24207
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcomputer-use

Description

@torry21th
torry21th
opened on May 23, 2026

Summary

Codex Desktop cannot enable the locked computer use / lock-screen operation setting on an Intel Mac. The UI shows an error similar to Unable to update "Locked operation" setting when toggling the setting.

This does not appear to be a missing macOS privacy permission issue. The required TCC permissions are present, but the Codex Desktop app bundle has signing / Gatekeeper validation errors for the native computer-use components.

Environment

  • macOS: 15.7.5 (24G624)
  • Architecture: x86_64 / Intel Mac
  • Codex Desktop: 26.519.41501
  • CFBundleVersion: 3044
  • Bundle identifier: com.openai.codex
  • App path: /Applications/Codex.app

Reproduction

  1. Install Codex Desktop 26.519.41501 on macOS Intel.
  2. Grant Codex permissions in macOS Privacy & Security:
    • Accessibility
    • Screen & System Audio Recording / ScreenCapture
    • ListenEvent / input monitoring equivalent
  3. Enable Prevent sleep while running.
  4. Try to enable the locked computer use / lock-screen operation setting.

Expected behavior

The locked computer use setting should enable successfully when the required macOS permissions are granted.

Actual behavior

The setting fails to update in the UI with an error. The computer-use service appears unable to start reliably.

An earlier log around the failing toggle showed:

Failed to reconcile managed Computer Use service appshotsEnabled=true errorMessage="Failed to spawn managed Computer Use service"

Diagnostics

TCC permissions are present:

kTCCServiceAccessibility|com.openai.codex|0|2|4|0|...
kTCCServiceScreenCapture|com.openai.codex|0|2|4|0|...
kTCCServiceListenEvent|com.openai.codex|0|2|4|0|...

A normal app assessment can pass:

/Applications/Codex.app: accepted
source=Notarized Developer ID

However, deep/strict verification fails:

codesign --verify --deep --strict --verbose=4 /Applications/Codex.app

Output:

/Applications/Codex.app: invalid signature (code or signature have been modified)
In architecture: x86_64

The native computer-use components also fail validation:

codesign --verify --verbose=4 /Applications/Codex.app/Contents/Resources/native/remote-control-device-key.node
codesign --verify --verbose=4 /Applications/Codex.app/Contents/Resources/native/browser-use-peer-authorization.node
codesign --verify --verbose=4 /Applications/Codex.app/Contents/Resources/native/bare-modifier-monitor

Outputs include:

invalid signature (code or signature have been modified)
In architecture: x86_64

spctl reports an internal Code Signing subsystem error for these components:

spctl --assess --type execute --verbose=4 /Applications/Codex.app/Contents/Resources/native/remote-control-device-key.node
spctl --assess --type execute --verbose=4 /Applications/Codex.app/Contents/Resources/native/bare-modifier-monitor

Output:

internal error in Code Signing subsystem

Removing quarantine attributes did not fix the issue:

xattr -dr com.apple.quarantine /Applications/Codex.app

After reinstalling Codex Desktop and re-granting permissions, the issue still reproduces.

Notes

The native files appear to match the app bundle's CodeResources hashes, so this does not look like local post-install file modification. It may be an issue with the x86_64 Codex Desktop packaging/signing for native computer-use components in version 26.519.41501.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    computer-use
    on May 23, 2026

  2. torry21th commented on May 23, 2026

    @torry21th
    torry21th
    on May 23, 2026 – with ChatGPT Codex Connector
    Author

    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.

  3. jshaofa-ui commented on May 23, 2026

    @jshaofa-ui
    jshaofa-ui
    on May 23, 2026

    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

  4. satoshikote commented on Jun 6, 2026

    @satoshikote
    satoshikote
    on Jun 6, 2026

    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.

  5. satoshikote commented on Jun 6, 2026

    @satoshikote
    satoshikote
    on Jun 6, 2026

    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.

  6. jingjc commented on Jun 18, 2026

    @jingjc
    jingjc
    on Jun 18, 2026 – with ChatGPT Codex Connector

    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.

  7. Stanceo commented on Jun 27, 2026

    @Stanceo
    Stanceo
    on Jun 27, 2026

    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?

  8. zgx88888 commented on Jul 22, 2026

    @zgx88888
    zgx88888
    on Jul 22, 2026 – with ChatGPT Codex Connector

    Still reproducible in the latest Intel build.

    Environment:

    • ChatGPT/Codex Desktop: 26.715.72359
    • CFBundleVersion: 5718
    • macOS: 15.7.7 (24G720)
    • Architecture: x86_64 / Intel

    Current startup log:

    Failed to reconcile managed Computer Use service
errorMessage="Failed to spawn managed Computer Use service"
nodeReplEnabled=true

    Code-signing verification still fails:

    codesign --verify --strict --verbose=4 \
  "/Applications/ChatGPT.app/Contents/Resources/native/browser-use-peer-authorization.node"

codesign --verify --strict --verbose=4 \
  "/Applications/ChatGPT.app/Contents/Resources/native/remote-control-device-key.node"

    Both return:

    invalid signature (code or signature have been modified)
In architecture: x86_64

    Locked Computer Use therefore still cannot be enabled in build 5718. The same failure has persisted across multiple x64 releases.

    Could the team please confirm whether Locked Computer Use is intended to support Intel Macs? If it is supported, the x64 native components appear to need to be rebuilt/re-signed and republished.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingcomputer-use

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions