Repository navigation
Codex Desktop rewrites user notify hook through SkyComputerUseClient --previous-notify #28404
Description
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 = trueActual 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
github-actions commentedon Jun 15, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
banteg commentedon Jun 15, 2026
Additional local evidence from the initial triage: the helper app does not appear to be actually corrupt.
At the time of the first reproduction:
Observed helper copies:
There was no
com.apple.quarantinexattr on the installed helper.The same helper bundle produced different assessment results depending on execution context:
From the Codex-managed sandboxed environment:
Outside that sandbox, assessing the same app passed:
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.appshould actually be moved to Trash.This is separate from, but amplified by, the
notifyrewrite described above: oncenotifyis rewritten throughSkyComputerUseClient turn-ended --previous-notify ..., every turn-ended notification goes through the Computer Use helper and can trigger this misleading Gatekeeper path.rhdtl78 commentedon Jun 18, 2026
Additional confirmation on 26.611.62324 (4028)
I hit this again after another Codex Desktop update.
Environment
26.611.62324, build4028~/.codex/computer-use: version1.0, build8102026-06-18KSTSmoking-gun reproduction
The global
notifysetting had been rewritten to:I manually changed it back to:
notify = []After launching/verifying the Computer Use helper once, Codex Desktop immediately rewrote it again to:
This happened even though the helper itself verified successfully:
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:After waiting and re-checking:
This strongly supports the diagnosis that the damaged-app dialog is downstream of Desktop injecting the
SkyComputerUseClient turn-endedwrapper into globalnotify, causing the Computer Use helper to be launched on turn completion even when the user did not explicitly request Computer Use.FNDEVVE commentedon Jun 24, 2026
I’m hitting this too on macOS with Codex Desktop.
What I tried:
notify = []and also:
plus disabling related hook/plugin features. After restart / config reconciliation, Codex rewrites the config back to:
So
notify = []is not respected as “disable notify”; it gets wrapped as the previous notify value.Process evidence after that rewrite:
Earlier in the same session this produced hundreds of orphaned
SkyComputerUseClientprocesses parented bylaunchd, 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 rewritenotifytoSkyComputerUseClient ... --previous-notify [], and should not launchSkyComputerUseService/SkyComputerUseClient.PaulRBerg commentedon Aug 12, 2026
I'm also experiencing the same bugs/annoying behaviors reported in this issue.
Why
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.tomlor something like that.And then, that config would be merged with the user's
~/.codex/config.tomldefaults, 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
fix: recognize the Codex desktop app's --previous-notify wrapper