Skip to content

Codex Desktop rewrites user notify hook through SkyComputerUseClient --previous-notify #28404

Open

Description

@banteg

Environment

  • macOS: 26.5, build 25F71
  • Codex Desktop: 26.609.71144, build 3952
  • Codex CLI: 0.137.0
  • Computer Use helper: 1.0, build 809
  • Platform: macOS Apple Silicon

Summary

Codex Desktop rewrites a user-owned notify command into a Computer Use wrapper on app restart. The rewritten command launches SkyComputerUseClient turn-ended first and stores the original notifier under --previous-notify.

This causes macOS Gatekeeper/codesign failures for Codex Computer Use.app even though the user only configured a normal notification script.

This appears to be a Desktop startup/plugin migration behavior, not the standalone CLI.

Original user config

Before restarting Codex Desktop, ~/.codex/config.toml contained:

notify = ["uv","run","--quiet","/Users/banteg/.codex/notify_telegram.py"]

[plugins."computer-use@openai-bundled"]
enabled = true

Actual behavior

After restarting Codex Desktop, the config was rewritten to:

notify = ["/Users/banteg/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient", "turn-ended", "--previous-notify", "[\"uv\",\"run\",\"--quiet\",\"\\/Users\\/banteg\\/.codex\\/notify_telegram.py\"]"]

After this rewrite, macOS frequently shows:

"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.

The dialog appears around Codex startup / turn completion, even when Computer Use was not explicitly requested. The original notification script is now only invoked through the Computer Use helper.

Expected behavior

Codex Desktop should not overwrite a user-owned notify command with a Computer Use wrapper on restart.

If Desktop needs a turn-ended Computer Use hook, it should use a separate internal hook mechanism rather than mutating notify, or it should at least preserve explicit user configuration and provide an opt-out.

In particular:

  • notify = ["uv", ...] should remain unchanged across Desktop restarts and updates.
  • Enabling Computer Use should not make every turn-ended notification depend on launching SkyComputerUseClient.
  • A Computer Use helper launch/signing failure should not break unrelated user notification hooks.

Additional evidence

The helper binary appears to be the same across the local runtime, plugin cache, and app bundle by SHA-256:

7727bcf3b3d648a7d28f67f394a1a114e472e63d7f1d497194945f8bede3fb58

Paths checked:

/Users/banteg/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
/Users/banteg/.codex/plugins/cache/openai-bundled/computer-use/1.0.809/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
/Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

This suggests the immediate problem is not a user-created bad notifier command. The Desktop app is actively migrating/wrapping notify through Computer Use on startup.

Workaround

Manually restoring the direct notifier stops the immediate issue until Codex Desktop is restarted again:

notify = ["uv","run","--quiet","/Users/banteg/.codex/notify_telegram.py"]

But restarting Codex Desktop rewrites it again when Computer Use is enabled, so the workaround is not stable for users who need Computer Use.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    hooksIssues related to event hooks
    configIssues involving config.toml, config keys, config merging, or config updates
    on Jun 15, 2026
  2. banteg commented on Jun 15, 2026

    @banteg
    Author
    Image

    Additional local evidence from the initial triage: the helper app does not appear to be actually corrupt.

    At the time of the first reproduction:

    • macOS: 26.5
    • Codex Desktop: 26.609.41114, build 3888
    • Computer Use helper: build 809

    Observed helper copies:

    /Users/banteg/.codex/computer-use/Codex Computer Use.app
    /Users/banteg/.codex/plugins/cache/openai-bundled/computer-use/1.0.809/Codex Computer Use.app
    /Users/banteg/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/computer-use/Codex Computer Use.app
    /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app
    

    There was no com.apple.quarantine xattr on the installed helper.

    The same helper bundle produced different assessment results depending on execution context:

    From the Codex-managed sandboxed environment:

    codesign --verify --deep --strict --verbose=4
    => invalid signature (code or signature have been modified)
    
    spctl --assess --type execute --verbose=4
    => internal error in Code Signing subsystem
    

    Outside that sandbox, assessing the same app passed:

    codesign
    => valid on disk
    => satisfies its Designated Requirement
    
    spctl
    => accepted
    => source=Notarized Developer ID
    

    That made reinstalling Codex / the plugin non-diagnostic: reinstall restores the same valid, notarized helper bytes. The user-visible dialog appears to be a misleading Gatekeeper presentation of a launch/signature-assessment context failure, not evidence that Codex Computer Use.app should actually be moved to Trash.

    This is separate from, but amplified by, the notify rewrite described above: once notify is rewritten through SkyComputerUseClient turn-ended --previous-notify ..., every turn-ended notification goes through the Computer Use helper and can trigger this misleading Gatekeeper path.

  3. rhdtl78 commented on Jun 18, 2026

    @rhdtl78

    Additional confirmation on 26.611.62324 (4028)

    I hit this again after another Codex Desktop update.

    Environment

    • Codex Desktop: 26.611.62324, build 4028
    • Computer Use helper under ~/.codex/computer-use: version 1.0, build 810
    • Date observed: 2026-06-18 KST
    • Platform: macOS / Apple Silicon

    Smoking-gun reproduction

    The global notify setting had been rewritten to:

    notify = ["/Users/kether/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient", "turn-ended"]

    I manually changed it back to:

    notify = []

    After launching/verifying the Computer Use helper once, Codex Desktop immediately rewrote it again to:

    notify = ["/Users/kether/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient", "turn-ended", "--previous-notify", "[]"]

    This happened even though the helper itself verified successfully:

    /Users/kether/.codex/computer-use/Codex Computer Use.app: valid on disk
    /Users/kether/.codex/computer-use/Codex Computer Use.app: satisfies its Designated Requirement
    /Users/kether/.codex/computer-use/Codex Computer Use.app: accepted
    source=Notarized Developer ID
    

    Local mitigation that stopped the immediate rewrite

    Setting the Computer Use plugin to disabled and restoring notify = [] stopped the immediate rewrite in this local session:

    notify = []
    
    [plugins."computer-use@openai-bundled"]
    enabled = false

    After waiting and re-checking:

    notify = []
    [plugins."computer-use@openai-bundled"]
    enabled = false
    no SkyComputerUse* processes running
    

    This strongly supports the diagnosis that the damaged-app dialog is downstream of Desktop injecting the SkyComputerUseClient turn-ended wrapper into global notify, causing the Computer Use helper to be launched on turn completion even when the user did not explicitly request Computer Use.

  4. FNDEVVE commented on Jun 24, 2026

    @FNDEVVE

    I’m hitting this too on macOS with Codex Desktop.

    What I tried:

    notify = []

    and also:

    [features]
    computer_use = false
    
    [plugins."computer-use@openai-bundled"]
    enabled = false

    plus disabling related hook/plugin features. After restart / config reconciliation, Codex rewrites the config back to:

    notify = ["/Users/fnd/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient", "turn-ended", "--previous-notify", "[]"]

    So notify = [] is not respected as “disable notify”; it gets wrapped as the previous notify value.

    Process evidence after that rewrite:

    SkyComputerUseService ... /Users/fnd/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
    

    Earlier in the same session this produced hundreds of orphaned SkyComputerUseClient processes parented by launchd, consuming several GB of RAM. Killing the orphaned clients cleared the memory pressure, but the config keeps being restored/wrapped.

    The Sky processes are from Codex Computer Use / com.openai.sky.CUAService.

    Expected behavior: if notify = [] or the Computer Use plugin is disabled, Codex should not rewrite notify to SkyComputerUseClient ... --previous-notify [], and should not launch SkyComputerUseService / SkyComputerUseClient.

  5. PaulRBerg commented on Aug 12, 2026

    @PaulRBerg

    I'm also experiencing the same bugs/annoying behaviors reported in this issue.

    Why

    Codex Desktop should not overwrite a user-owned notify command with a Computer Use wrapper on restart.

    Indeed - I'd go even further than that. The desktop app should write to its bespoke config file under ~/.codex, e.g. ~/.codex/config-desktop.toml or something like that.

    And then, that config would be merged with the user's ~/.codex/config.toml defaults, prioritizing the desktop configuration when there is a conflict.

    Created a github issue for this: #38193

    @banteg @FNDEVVE please cast your support for that by 👍 that issue

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-useconfigIssues involving config.toml, config keys, config merging, or config updateshooksIssues related to event hooks

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions