›_ Codex Issues
Codex Issues / #28404

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

Open 💬 5 comments Opened Jun 15, 2026 by banteg
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28100
  • #28184

Powered by Codex Action

banteg · 2 months ago

<img width="260" height="280" alt="Image" src="https://github.com/user-attachments/assets/a707570d-2b15-458e-a0d9-02eafc58e804" />

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.

rhdtl78 · 2 months ago

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.

FNDEVVE · 2 months ago

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.

PaulRBerg · 15 days ago

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: https://github.com/openai/codex/issues/38193

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