Skip to content

Codex desktop repeatedly crashes when using Computer Use. #26458

Open

Description

@jsduke246

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

Version 26.601.21317 •

What subscription do you have?

Pro ($20/mo)

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex desktop repeatedly crashes when using Computer Use.

Environment:

  • App: Codex
  • Version: 26.601.21317 (3511)
  • macOS: 26.5 (25F71)
  • Hardware: Mac14,2
  • Date: June 4, 2026

Observed pattern:

  • HighLevel connector works after reinstall.
  • Computer Use causes repeated Codex crashes.
  • Reinstalling/resetting Computer Use helper did not fix it.
  • Crash repeats after Computer Use is invoked.

Crash signature:

  • Process: Codex
  • Exception: EXC_CRASH (SIGABRT)
  • Termination: Abort trap: 6
  • Triggered thread: git
  • Stack includes: node::OOMErrorHandler(char const*, v8::OOMDetails const&)
  • Native module loaded: browser-use-peer-authorization.node
  • Also saw org.libusb.device-hotplug / UsbEventHandler threads in reports.

Local mitigation:

  • Disabled ~/.codex/config.toml notify hook:
    notify = ["/Users/jeanneduke/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient", "turn-ended"]

Likely issue:
Computer Use / browser-use authorization path appears to trigger a Node/V8 out-of-memory abort in Codex desktop 26.601.21317.

What steps can reproduce the bug?

The above message is what Codex created as the report I should submit.

What is the expected behavior?

No response

Additional information

No response

Activity

  1. added
    appIssues related to the Codex desktop app
    on Jun 4, 2026
  2. github-actions commented on Jun 4, 2026

    @github-actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. Cloisterwood commented on Jun 4, 2026

    @Cloisterwood

    Yes, this appears to be the same underlying crash signature as #26079: Codex Desktop 26.601.21317, triggered thread git, SIGABRT, node::OOMErrorHandler. My issue may add a reproduction clue: it occurs after invoking Computer Use, and my crash reports include browser-use-peer-authorization.node. I’m okay closing my issue as a duplicate if you want to track the core Node/V8 git-worker OOM in #26079, but I recommend noting the Computer Use/browser-use trigger there.

  4. pengusto commented on Jun 4, 2026

    @pengusto

    I’m seeing a very similar issue after updating to Codex 26.602.30954.

    Environment:

    • Codex version: 26.602.30954 • Released Jun 4, 2026
    • macOS: Tahoe 26.5
    • Hardware: Apple Silicon M4 Pro
    • Frequency: popup appears roughly every 4 minutes

    Error message:

    “Codex Computer Use.app” is damaged and can’t be opened. You should move it to the Trash.

    The popup appears repeatedly, even when I’m not manually launching Computer Use. This started after the latest Codex update.

  5. aifirstd3v commented on Jun 5, 2026

    @aifirstd3v

    The Computer Use app does not currently feel reliable or stable enough, probably because it has to interact with macOS Gatekeeper and the hardened security model in a very complex way.

    The main OpenAI developer responsible for the Codex Computer Use app on macOS needs to be highly experienced, deeply familiar with macOS internals, and extremely careful. A system that can potentially take full control of a user’s machine must be engineered with exceptional precision. To work properly with macOS’s strong security model, the implementation needs to integrate organically with Gatekeeper, code signing, notarization, TCC permissions, and hardened runtime behavior. In short, this kind of feature requires real mastery of macOS, not just ordinary desktop app development.

    Dear OpenAI Dev Team:

    And please, do not ship features before they have been thoroughly tested across a wide variety of real-world environments. Releasing something prematurely and losing user trust is far more damaging than delaying a feature for a little longer. What matters most right now is reliability and confidence in the product, not the rapid addition of minor features that many users may not even need immediately. It would be much better to prioritize stability, eliminate these kinds of bugs and issues, and ensure a consistently dependable experience before expanding functionality further.


    I hit what looks like the same family of issues with the intermittent macOS Gatekeeper dialog:

    "Codex Computer Use.app" is damaged and can't be opened. You should move it to the Trash.
    This file was downloaded on an unknown date.

    In my case this did not look like an actually corrupted helper bundle.

    Environment / observed state:

    • Apple Silicon macOS
    • Codex.app version observed after the latest update: 26.602.30954
    • Codex build: 3575
    • Computer Use helper version: 809
    • Helper bundle identifier: com.openai.sky.CUAService

    Important paths observed:

    • Bundled source helper:

      • /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app
    • Per-user Computer Use install target:

      • ~/.codex/computer-use/Codex Computer Use.app
    • Previous / timestamped local copy:

      • ~/.codex/computer-use/Codex Computer Use.app 13-51-16-627.app
    • Temporary bundled marketplace path:

      • ~/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/computer-use/Codex Computer Use.app
    • Runtime code-sign clone paths:

      • /private/var/folders/.../X/com.openai.codex.code_sign_clone/code_sign_clone.*/Codex.app.bundle/.../Codex Computer Use.app

    What I verified:

    • The bundled source helper inside /Applications/Codex.app/.../computer-use/ passed:

      • codesign --verify --deep --strict
      • spctl --assess --type execute
    • The local timestamped helper copy also passed codesign and spctl.

    • The helper binaries had the same expected OpenAI Developer ID signature.

    • No quarantine xattr was observed.

    • SkyComputerUseService hashes matched between the bundled source and the local copy.

    The local state mismatch I found:

    ~/.codex/config.toml had a notify hook pointing to the canonical path:

    ~/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient

    But at that point the canonical ~/.codex/computer-use/Codex Computer Use.app did not exist. Only a timestamped copy existed:

    ~/.codex/computer-use/Codex Computer Use.app 13-51-16-627.app

    As a temporary test, I created a symlink from the canonical path to the timestamped copy. That made the expected path valid, and codesign / spctl still passed.

    After restarting Codex and going to Settings > Computer Use > Install, Codex replaced the symlink with a real app bundle directory at:

    ~/.codex/computer-use/Codex Computer Use.app

    The timestamped copy remained. The new canonical bundle passed codesign and spctl, and the notify target under the canonical path existed.

    After that, Computer Use worked successfully against Zed.app:

    • SkyComputerUseService was running.
    • SkyComputerUseClient was running.
    • get_app_state(app="Zed") succeeded.
    • The accessibility tree and screenshot were returned.
    • A click on Zed's File menu succeeded.

    My interpretation:

    This looks less like a bad download or broken notarization ticket, and more like a per-user Computer Use install-state / helper lifecycle / Gatekeeper interaction issue.

    The issue may become visible intermittently because the relevant helper is not always launched at Codex startup. It may happen later when:

    • opening Settings > Computer Use
    • pressing Install
    • launching the per-user helper
    • launching a nested helper such as SkyComputerUseClient.app
    • running the turn-ended notify hook
    • attaching to the first target app
    • performing the first screenshot / accessibility operation
    • validating a code_sign_clone runtime copy
    • TCC / Screen Recording / Accessibility checks happen

    The most useful thing for maintainers may be to clarify and harden the expected lifecycle:

    1. Treat ~/.codex/computer-use/Codex Computer Use.app as the canonical per-user install target, or document the intended target.
    2. Ensure Codex startup and plugin refresh resync this target from the bundled app if it is missing or stale.
    3. Avoid leaving config.toml notify hooks pointing to a missing canonical helper path.
    4. Validate parent and nested helper apps consistently.
    5. Clean up stale SkyComputerUseService, SkyComputerUseClient, node_repl, and stdio app-server helper processes after use.
    6. Clean up inactive /private/var/folders/.../com.openai.codex.code_sign_clone/code_sign_clone.* directories after quit.
    7. Avoid triggering repeated syspolicyd / trustd validation loops for helpers that are already signed and notarized.

    This may explain why a reinstall alone did not help, but rerunning the Computer Use installer after the canonical per-user path was missing appeared to stabilize the system.

  6. cohaaan commented on Jun 8, 2026

    @cohaaan

    is this fixed?

  7. Cloisterwood commented on Jun 8, 2026

    @Cloisterwood
  8. cohaaan commented on Jun 9, 2026

    @cohaaan
  9. mrgoonie commented on Jun 13, 2026

    @mrgoonie

    workaround: sudo xattr ~/.codex/computer-use/Codex\ Computer\ Use.app

  10. Ahmet-Dedeler commented on Jun 13, 2026

    @Ahmet-Dedeler

    same issue

    Image
  11. mrgoonie commented on Jul 14, 2026

    @mrgoonie
    Image

    it happens again...

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-useperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions