Codex Desktop for macOS repeatedly triggers `syspolicyd` / `trustd` CPU and memory runaway

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

• #25703
• #25243

Powered by Codex Action

The reason syspolicyd is repeatedly writing to the WAL is because the policy cache misses for /Applications/Codex.app in macOS Gatekeeper/SystemPolicy are increasing dramatically. This magnitude is clearly abnormal, far exceeding that of other apps. The second most missed record is also an old one, com.openai.codex, with a miss_count of approximately 1,360,282.

Update: still reproducible after another fresh Codex launch.

With Codex closed and after killing syspolicyd/trustd, CPU usage returns to normal. Immediately after launching Codex Desktop 26.527.60818 (build 3437), syspolicyd jumped from ~0% to ~177% CPU again.

This is on macOS 26.5.1 (25F80), after reinstalling/updating macOS. So this does not appear to be local Gatekeeper corruption.

This looks strongly related to #25243. My case also confirms that Codex still starts/uses the Computer Use path even when visible user config has notify=[], Browser plugin disabled, keybindings=[], and global hotkeys disabled/null.

OpenAI_Codex_syspolicyd_bug_report_2026-06-01.md
This bur report was amended by Grok Build on the same Mac

Same root cause as #25882 — full mechanism analysis (syspolicyd file-descriptor exhaustion + a no-backoff/no-cap relaunch loop that re-posix_spawns the app's own main binary tens of times/sec) is written up there. Reproducing on the identical build (Codex Desktop 26.527.60818 / build 3437, Apple Silicon).

Additional reproduction from another affected macOS machine after a Codex Desktop update.

Environment:

macOS: 26.3.1(a), build 25D771280a, arm64
Codex Desktop: 26.601.20914, build 3497
Computer Use helper CFBundleVersion: 799

Observed behavior:

After the Codex update, ~/.codex/config.toml was rewritten so that notify pointed back to the volatile helper path:

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

But ~/.codex/computer-use/ only contained config.json; the app bundle was missing. On restart, macOS showed the Gatekeeper dialog:

"Codex Computer Use" is damaged and can't be opened.
You should move it to the Trash.

System logs showed syspolicyd / TCC evaluating a trashed helper copy:

~/.Trash/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

The canonical helper inside the Codex app bundle was valid:

/Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app
spctl: accepted, source=Notarized Developer ID
codesign: valid on disk, satisfies Designated Requirement

The plugin-cache helper had the same CFBundleVersion and SHA-256 as the app-bundled helper, and also passed spctl/codesign.

Workaround that stopped the Gatekeeper dialog on this machine:

1. Point notify to the helper inside /Applications/Codex.app/....
2. Recreate ~/.codex/computer-use/Codex Computer Use.app as a symlink to the bundled helper.
3. Mark that symlink immutable with chflags -h uchg so the update/startup path cannot silently replace it again.

After that, Codex Computer Use launches from /Applications/Codex.app/... and the Gatekeeper dialog no longer appears.

This looks like the updater or desktop startup path can recreate/reset the volatile ~/.codex/computer-use path and/or rewrite notify back to a path that may not contain a valid app bundle after update. The issue recurred once after a Codex update and was resolved again by restoring the stable app-bundled helper path.

Have exactly same issue

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

you can notice that at that time other files created, downloaded or airdropped also shown the same - "File is damaged and can’t be opened. You should move it to the Trash." . Codex overloading syspolicyd causes many other good files being quarantined
After updating Codex Desktop to 26.601.21317 on Apple Silicon macOS 26.5.x, the previous local workaround was reset.

~/.codex/computer-use/Codex Computer Use.app was recreated.
notify in ~/.codex/config.toml was rewritten back to the volatile ~/.codex/computer-use/.../SkyComputerUseClient path.
The Browser plugin was re-enabled.
I tested the targeted workaround suggested in this issue:

pointed notify to the stable bundled helper inside /Applications/Codex.app/.../computer-use/...;
replaced ~/.codex/computer-use/Codex Computer Use.app with a symlink to the bundled helper;
applied chflags -h uchg only to that symlink.
The symlink workaround works structurally: file access works, the helper path is stable, and the bundled/symlinked helper versions and SHA-256 match (CFBundleVersion 799).

However, syspolicyd is still not stable. It sometimes drops to about 8-9% CPU, but later spikes again to about 100-150% CPU during normal Codex use.

I also observed ordinary generated files such as PNG/PDF documents receiving com.apple.quarantine and triggering macOS "damaged and can't be opened" dialogs. Removing the quarantine attribute makes them open normally.

Additional note: I manually disabled the Browser plugin in the Codex UI, but later found it enabled again and had to disable it again. If the user disables Browser/Computer Use related functionality, Codex should preserve that setting and not silently re-enable it after restart/update.

I'm having the same exact issues for 3 days now making my Mac freeze at some point. Also not being able to open another apps with message The application "X" can't be opened. Even this is showing “Codex Computer Use.app” is damaged and can’t be opened. You should move it to the Trash." tho i don't have access to it in Europe.

Same issue here.

same issue, and only desktop causes this problem, cli is normal

Duplicate of: https://github.com/openai/codex/issues/25243

In the latest Codex version 26.602.30954,
I have tested and confirmed that the issue has now been resolved.
(MacOS Version 26.5.1 [25F80])

Fix:

1. Update Codex.
2. Run the following command to restart syspolicyd, which had been compromised by the older version of Codex.

sudo killall syspolicyd trustd

same issue, and only desktop causes this problem, cli is normal

https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.519.81530.zip, uninstall my codex and install this version works good for me

In the latest Codex version 26.602.30954, I have tested and confirmed that the issue has now been resolved. (MacOS Version 26.5.1 [25F80]) Fix: 1. Update Codex. 2. Run the following command to restart syspolicyd, which had been compromised by the older version of Codex. `` sudo killall syspolicyd trustd ``

not works for me 😢

No it isn't resolved.

> same issue, and only desktop causes this problem, cli is normal https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.519.81530.zip, uninstall my codex and install this version works good for me

it really does, syspolicyd no longer spikes

Asking Codex to fix Computer Use followed by sudo killall syspolicyd trustd, restarting Codex and re-enabling permissions for Computer Use.app worked for me.

Adding another data point from macOS 26.5 / Codex Desktop 26.602.40724 (build 3593), Europe/Slovenia.

Computer Use is not available/enabled for my region, but Codex still had this post-turn hook in ~/.codex/config.toml:

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

Symptom:

• After each assistant response, macOS showed:

"Codex Computer Use" is damaged and can't be opened. You should move it to the Trash.

• The dialog appeared immediately after the assistant response, not when explicitly requesting Computer Use.

Verification:

• /Users/<user>/.codex/computer-use/Codex Computer Use.app passes:
• spctl --assess --type execute --verbose=4 -> accepted, source=Notarized Developer ID
• codesign --verify --deep --strict --verbose=2 -> valid on disk
• No com.apple.quarantine xattr was present.
• Commenting out the notify line was not stable: after restarting Codex, Codex recreated an active notify = [...] line.
• Setting the key explicitly to an empty array fixed the immediate recurrence:

notify = []

After that:

• no SkyComputerUseClient, SkyComputerUseService, or CUALockScreenGuardian process was running;
• the Gatekeeper prompt did not appear after the next assistant response.

This suggests the issue is not just Computer Use availability or user intent. The Desktop app appears to install/restore a post-turn Computer Use notification hook even when Computer Use is region-unavailable or not requested. A robust fix may need to avoid installing/restoring this hook unless Computer Use is actually available and enabled, and should preserve explicit notify = [].

This is what worked for me:

• Note: Codex.app was installed via Homebrew to begin with.
• Uninstalled via brew uninstall --cask codex-app
• Trashed contents of ~/.codex/computer-use/
• Removed all references to computer-use and mcp_servers.node_repl in ~/.codex/config.toml
• Installed again via brew install --cask codex-app
• Started Codex.app and clicked "Install" within Settings -> Computer Use

Update: Never mind. 1 hour later, there was an update (26.602.71036 via app, not Homebrew) that reversed it all.

YYMV but this worked for me as a temporary workaround to stop syspolicyd spiking:

Remove computer use, and lock the dir so Codex can't re-download it:

rm -rf ~/.codex/computer-use/Codex\ Computer\ Use.app && chflags uchg ~/.codex/computer-use

For those who want to have a working Codex again, starting from scratch and deleting the .codex folder (or renaming it) worked for me. When I ask Codex to import the previous threads, though, I'm hitting the same problem, so better to readd all the projects and skills manually for now until this bug has been fixed.

Not ideal, but at least you can stay on the latest version.

This, to me, is also an indicator that Computer Use might not be the culprit here (or at least not by itself, there's _something_ that triggers this behavior on startup).

For those who want to have a working Codex again, starting from scratch and deleting the .codex folder (or renaming it) worked for me. When I ask Codex to import the previous threads, though, I'm hitting the same problem, so better to readd all the projects and skills manually for now until this bug has been fixed. Not ideal, but at least you can stay on the latest version. This, to me, is also an indicator that Computer Use might not be the culprit here (or at least not by itself, there's _something_ that triggers this behavior on startup).

Does not work for me: https://github.com/openai/codex/issues/25243#issuecomment-4683023193

Having the exact same issue. Trying to disable computer use feels like trying to remove malware. We need clarity on this ASAP. Codex app is unusable, and the impact to the rest of my machine is unclear.

I experienced the issue too.

This looks related to the same macOS SystemPolicy / syspolicyd pressure issue I investigated in #25243.

I posted the local findings and mitigation here: https://github.com/openai/codex/issues/25243#issuecomment-4709140592

Short version from my machine: Codex Desktop was repeatedly invoking some system tools by bare command name, and a long user PATH with many mise-managed directories before the system dirs amplified the launch-time SystemPolicy/Gatekeeper work. The strongest local evidence was an exec trace showing xcode-select searched through 43 PATH entries before reaching /usr/bin/xcode-select. Adding a narrow PATH shim for the observed commands (ps, ditto, sw_vers, xcode-select, and the first user-selected git) substantially reduced sustained syspolicyd / trustd pressure after restart.

This does not fully explain the retained code_sign_clone directories, which still look like a separate cleanup/storage amplifier, but the PATH lookup behavior may be useful for reproducing or hardening this issue.

I spent some time debugging why Codex App was causing syspolicyd and trustd to spike on my Mac.

My current conclusion: it seems strongly related to Notification + Computer Use.

Even though I had Computer Use disabled in ~/.codex/config.toml:

[features]
computer_use = false

Codex App kept writing this back into the config:

notify = [".../SkyComputerUseClient", "turn-ended"]

That path belongs to Codex Computer Use. After every restart, SkyComputerUseService came back, and Codex created another temp clone under:

/var/folders/.../X/com.openai.codex.code_sign_clone

Each clone was around 1.2 GB. After a few restarts, it grew quickly. I previously saw 15 GB of these clones.

I also had a long PATH, with many user directories before /usr/bin and /bin. That seems to make the syspolicyd / trustd spike worse, probably because Codex or its helpers call some system tools by bare name.

What helped me:

• Put a small PATH shim first for:
• ps
• ditto
• sw_vers
• xcode-select
• git
• Disable Browser Use / Computer Use feature flags.
• Remove the notify = ...SkyComputerUseClient... line.
• Clean the stale clone folder manually:

rm -rf "$(dirname "$(getconf DARWIN_USER_TEMP_DIR)")/X/com.openai.codex.code_sign_clone"

After this, syspolicyd and trustd mostly stopped spiking for me.

But this is not a full fix. Codex App can still rewrite the notify line and start Computer Use again. So I think this needs an upstream fix from OpenAI:

• Don’t start Computer Use from the notification path when Computer Use is disabled.
• Respect computer_use = false everywhere.
• Clean old code_sign_clone folders automatically.
• Use absolute paths or a clean PATH for internal macOS system tools.

If you use Codex App on macOS and see syspolicyd or trustd CPU spikes, check whether SkyComputerUseService is running and whether com.openai.codex.code_sign_clone is growing.

Been running into this issue for the past week and finally debugged it today.

Symptoms were basically: Mac running hot, memory usage spiking, and some files/apps not opening because macOS said they were “damaged.” I checked Console and saw repeated syspolicyd / validation category policy activity involving Codex.

Then I ran fs_usage and saw Codex repeatedly calling posix_spawn on:

/Users/<NAME>/workspace/playground (WHY?)

This was happening many times per second.

What’s interesting is that playground is an incubator folder for me. I keep a bunch of small project subfolders in there, each with their own projects. In Codex, I had imported playground itself as the project.

After more digging, it seemed related to:

/Users/<NAME>/.codex/ambient-suggestions

I nuked that folder, deleted the playground project from Codex, killed/restarted the app, and boom, the issue was fixed.

I saw some logs related to SkyComputerUseService as well but like idk what actually was the issue i got too lazy to debug more

Two mitigations that took syspolicyd from 169% CPU / ~6 GB RAM to ~0% on my machine

Sharing what worked in my environment. These reduce the per-exec assessment cost rather than removing a trigger, so they're complementary to the computer-use/notify removal already discussed here. They are not a fix — the root cause is still app-side (unsigned helper / code_sign_clone re-assessment).

Environment

• macOS 26.5.1 (25F80), Apple Silicon
• Codex Desktop 26.611.61753 (build 4008)
• Confirmed I have the same volatile hook in ~/.codex/config.toml:

notify = [".../SkyComputerUseClient", "turn-ended", ...]

What I observed

• With Codex running, syspolicyd pegged at ~169% CPU and grew to ~6–7 GB RAM (leaking). spctl -a returned Too many open files.
• sample syspolicyd showed the hot queue was DispatchQueue: syspolicyd.executions.mig, and the cost was dominated by logging: _os_log paths ≈147 samples vs qtn_proc_init_with_pid ≈14 vs yara =1.

Mitigation 1 — disable the INFO logging amplifier (no security trade-off)

com.apple.syspolicy ships at INFO level on macOS 26 (the override plist only appears once you change it), so every exec syspolicyd processes gets fully formatted + emitted. Dropping it to default removed the dominant cost:

sudo log config --status --subsystem com.apple.syspolicy      # showed: INFO PERSIST_DEFAULT ...
sudo log config --subsystem com.apple.syspolicy --mode "level:default"

Reversible with --mode "level:info". This is just log verbosity — it does not change any security enforcement.

Mitigation 2 — exempt Codex from on-exec Gatekeeper/YARA (has a security trade-off)

System Settings → Privacy & Security → Developer Tools → add /Applications/Codex.app, enable, then fully quit & relaunch Codex. This skips the Gatekeeper/YARA assessment for processes Codex spawns (the com.apple.security.syspolicy.yara queue went to 0 afterwards). ⚠️ This disables a security check for binaries Codex launches — opt in knowingly.

After both + one sudo killall syspolicyd to clear the leaked state: 169% CPU / ~6 GB → 0% CPU / 27 MB, stable while actively using Codex.

Caveats

• These lower the cost per assessment; they don't stop the triggers (notify hook, code_sign_clone, PATH). Combine with the computer-use removal + chflags uchg lock from earlier in this thread.
• I did not verify this against the fd-exhaustion/relaunch loop in #25882 — my machine wasn't in that state.
• The real fix still needs to come from the app side (properly signed/notarized helper, avoid re-assessing a 1+ GB code_sign_clone per launch).

Additional data point from macOS 26.5.1 showing this still reproduces on a newer Codex Desktop build.

Environment

• macOS: 26.5.1 (25F80)
• Codex Desktop: 26.611.61753 (CFBundleVersion 4008)
• Bundled Codex binary: codex-cli 0.140.0-alpha.19
• Homebrew Codex CLI: codex-cli 0.140.0
• Architecture: Apple Silicon / arm64
• Related issues: #27662, #28071

Symptoms observed

The machine heats up while Codex Desktop is open, but the CLI does not show the same behavior. A process sample during the bad state showed:

syspolicyd                       ~124% CPU
WindowServer                     ~54% CPU
/Applications/Codex.app          ~42% CPU
Codex GPU service                ~26% CPU
Codex app-server                 ~8% CPU

A later sample after the system had cooled somewhat still showed Codex-related and SystemPolicy activity:

WindowServer                     ~36-38% CPU
syspolicyd                       ~15% CPU
Codex GPU service                ~14-17% CPU
Codex app-server                 ~6-10% CPU

pmset -g assertions did not show Codex holding a sleep assertion, so this does not look like the older caffeinate / display-sleep issue.

Evidence from Codex logs

The current Codex Desktop logs contain 47,902 occurrences of:

failureReason=spawnFailed

These are concentrated in git.command.complete entries with:

requestKind=review-summary
source=review_model
subcommand=hash-object
command="git -c core.hooksPath=/dev/null -c core.fsmonitor= hash-object --no-filters -- <path>"

The hot paths are a large local repository with many generated report files. This suggests the Desktop review-summary path is spawning many per-file git hash-object commands and then failing under resource pressure. The CLI does not appear to trigger this same desktop review-summary behavior.

SystemPolicy evidence

Unified logs showed repeated macOS security evaluation activity from Codex, along with syspolicyd messages like:

UNIX error exception: 24
Failed to generate SecStaticCode for <private> error: 100024
failed to call driver: 0x3

This matches the EMFILE / SystemPolicy failure class described in this issue and in #27662.

Local config state

Before mitigation, ~/.codex/config.toml contained a Desktop-installed notification hook:

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

But the local ~/.codex/computer-use directory only contained:

~/.codex/computer-use/
~/.codex/computer-use/config.json

There was no Codex Computer Use.app bundle at that path. Browser plugin was also enabled.

A stale clone directory also existed and was large:

/private/var/folders/.../X/com.openai.codex.code_sign_clone  7.1G

Mitigation applied locally

I backed up ~/.codex/config.toml, then changed only:

notify = []

[plugins."browser@openai-bundled"]
enabled = false

I did not kill Codex, restart the app, or delete code_sign_clone yet because there were active desktop/app-server sessions. Immediate post-change sampling still showed some Codex/SystemPolicy activity, so a full app restart may be required for the config change to fully apply.

Suggested fixes

• Do not install or restore the SkyComputerUseClient notify hook when the helper bundle is missing, Computer Use is unavailable, or the user has disabled it.
• Preserve explicit notify = [] and disabled Browser/Computer Use settings across app restarts and updates.
• Add concurrency limits and backoff to Desktop review-summary git hashing; avoid spawning one git hash-object per file where a batched or persistent approach would work.
• On spawnFailed, EMFILE, or SystemPolicy errors, stop retrying aggressively and surface a diagnostic instead.
• Avoid repeated SystemPolicy assessment of Codex's main executable or large code_sign_clone bundles; clean stale clone directories automatically.
• For internal macOS tool calls, use absolute paths or a minimal deterministic PATH to reduce Gatekeeper/SystemPolicy work.

This issue is so severe that it may be physically damaging to the batteries in macbooks. This bug is one of the only things that has ever caused the fans to spin up on my m4 max. There's a lot of heat and the normally 6 hour battery drains in 45 mins, which is not good for battery health.

Yeah this is causing my mac to overheat big time. Have we heard anything from the codex team on this?

This fixed it for me: https://github.com/openai/codex/issues/25243#issuecomment-4738785578

Have you tired adding Codex Desktop as a "Developer Tool" in System Settings (under Privacy & Security)?

Have you tired adding Codex Desktop as a "Developer Tool" in System Settings (under Privacy & Security)?

Does not fix for me, on any of 3 different machines.

> Have you tired adding Codex Desktop as a "Developer Tool" in System Settings (under Privacy & Security)? Does not fix for me, on any of 3 different machines.

How are you using Codex Desktop? Are you just chatting with it, or trying advanced features like Computer Use?

> Does not fix for me, on any of 3 different machines. How are you using Codex Desktop? Are you just chatting with it, or trying advanced features like Computer Use?

Literally just starting it up, a few seconds in, it spikes. It most certainly has something to do with Computer Use b/c when the binary/package is removed, it definitely happens when it's loaded, and doesn't when it is removed.

But, Computer Use is one of the major reasons to use the Codex app IMO/use case, otherwise I just use the codex CLI, would really like to find a way to make Computer Use work, and I can confidently say it is related to that.

> > Does not fix for me, on any of 3 different machines. > > > How are you using Codex Desktop? Are you just chatting with it, or trying advanced features like Computer Use? Literally just starting it up, a few seconds in, it spikes. It most certainly has something to do with Computer Use b/c when the binary/package is removed, it definitely happens when it's loaded, and doesn't when it is removed. But, Computer Use is one of the major reasons to use the Codex app IMO/use case, otherwise I just use the codex CLI, would really like to find a way to make Computer Use work, and I can confidently say it is related to that.

If you're using Computer Use, try adding the app at /Users/[yourusername]/.codex/computer-use/Codex Computer Use.app as a Developer Tool.

Same issue here with the latest update

[macOS] ChatGPT Desktop repeatedly attempts to launch its own executable, exhausting syspolicyd

Privacy note

This report is intentionally sanitized. It contains no account identifiers, usernames, authentication tokens, prompts, task or thread identifiers, project names, private URLs, IP addresses, home-directory paths, or raw diagnostic archives.

Product and environment

• Application: ChatGPT Desktop for macOS, with Codex integrated
• ChatGPT version: 26.707.91948 (5440)
• Bundled Codex app-server version: 0.144.5
• Operating system: macOS 26.5.2
• Architecture: Apple Silicon (arm64)
• Installation path: /Applications/ChatGPT.app

Summary

While ChatGPT Desktop remains open, its long-running main Electron process repeatedly reaches Node/libuv uv_spawn / posix_spawn. At the same time, macOS records a very large number of failed policy assessments targeting ChatGPT's own main executable:

/Applications/ChatGPT.app/Contents/MacOS/ChatGPT

The assessment flood causes the macOS Gatekeeper daemon, syspolicyd, to exhaust its per-process file descriptors and emit EMFILE (errno 24, â^@^\Too many open filesâ^@^]). Once this occurs, unrelated applications become very slow to launch or cannot launch at all.

Restarting syspolicyd while ChatGPT remains open provides only temporary recovery because the new daemon is immediately flooded again.

User impact

• Chrome, Telegram, and other unrelated applications become very slow to open or fail to open.
• Gatekeeper verification fails system-wide with â^@^\Too many open files.â^@^]
• syspolicyd rapidly consumes CPU and hundreds of megabytes of memory.
• The issue is not caused by Wi-Fi or general network connectivity.
• Recovery requires fully quitting ChatGPT and restarting syspolicyd.

This is effectively a local system-wide denial of service caused by an unbounded desktop-app launch/retry loop.

Reproduction

1. Launch ChatGPT Desktop normally from /Applications.
2. Leave the application running with Codex available. No repeated manual app launching is required.
3. Observe AppleSystemPolicy events for ChatGPT's main executable.
4. After the event rate becomes sustained, try opening an unrelated application.
5. Observe syspolicyd errors 100024 and UNIX error exception: 24.
6. Restarting only syspolicyd does not provide lasting recovery while ChatGPT remains open.

A narrowly filtered observation command is:

log stream --style compact --info --debug \
  --predicate '(eventMessage CONTAINS "/Applications/ChatGPT.app/Contents/MacOS/ChatGPT") OR (process == "syspolicyd" AND (eventMessage CONTAINS "100024" OR eventMessage CONTAINS "UNIX error exception: 24"))'

Measured evidence

During a diagnostic window of approximately 3 minutes 45 seconds spanning a syspolicyd restart:

• 14,470 AppleSystemPolicy denial events targeted ChatGPT's main executable.
• 15,701 UNIX error exception: 24 events were recorded.
• 15,665 error: 100024 events were recorded.
• The restarted syspolicyd process had already reached approximately 434 MB resident memory and approximately 25% CPU.
• Docker-related matching policy events: 0.
• Other locally developed application matching policy events: 0.
• Simulator generated additional assessments later, but it did not initiate the ChatGPT launch storm.

In a separate exact six-second window used for process sampling:

• ChatGPT-main policy denials: 480.
• Bundled Codex executable policy denials/provenance failures: 0.

The sequential, distinct attempted PIDs show that these are real process attempts rather than duplicate logging of one event.

Representative sanitized system messages:

kernel (AppleSystemPolicy): Security policy would not allow process: <PID>, /Applications/ChatGPT.app/Contents/MacOS/ChatGPT
syspolicyd: UNIX error exception: 24
syspolicyd: Failed to generate SecStaticCode for <redacted> error: 100024

Runtime process attribution

A five-second live sample of the long-running ChatGPT main process repeatedly captured the following path:

ChatGPT main
  -> ChromeMain
  -> v8::Script::Run
  -> Node/V8 process wrapper
  -> uv_spawn
  -> posix_spawn
  -> __posix_spawn

__posix_spawn appeared at the top of 27 samples during that five-second capture. During the matching log window, macOS recorded 480 denied attempts targeting ChatGPT's main executable and none targeting the bundled Codex executable.

The sample proves that the ChatGPT main Electron/Node process is actively issuing child-process spawns. The sample format does not retain the child arguments, so the target attribution is based on exact-window correlation with AppleSystemPolicy rather than a directly captured argv record.

Packaged-code investigation

The shipped app.asar and unpacked resources were inspected read-only.

Findings:

• No direct app.relaunch() call exists.
• No visible spawn(process.execPath) self-launch call exists.
• The only direct open -n <app> path belongs to the installer-from-DMG flow. It is inactive when running from /Applications.
• The desktop bootstrap uses requestSingleInstanceLock() and exits duplicate instances. However, the kernel performs policy assessment before a duplicate can reach this JavaScript guard, so the guard cannot prevent the assessment flood.
• The bundled Codex app-server is launched as /Applications/ChatGPT.app/Contents/Resources/codex, not as the ChatGPT GUI executable.
• The local stdio app-server transport does not use the websocket reconnect loop.
• ChatGPT's own desktop logs showed only three bundled app-server launches during the day, which cannot explain tens of thousands of GUI executable assessments.
• The legacy ChatGPT Sparkle updater was successfully disarmed, and no stale updater job was active.

The strongest remaining code boundary is therefore a closed Electron/Owl/native/LaunchServices requester that repeatedly asks macOS to launch the ChatGPT GUI. The exact private callback cannot be named from the shipped static package.

An administrator Endpoint Security capture was attempted with a ChatGPT-only path filter. It produced no exec or fork events for the rejected children, consistent with AppleSystemPolicy rejecting them before normal exec notification and application logging. Internal instrumentation immediately before each launch request is likely required to identify the precise callback and arguments.

Signing and installation integrity

• The running ChatGPT, bundled Codex, and active helper processes are kernel-valid, signed, and hardened-runtime processes.
• The main application contains a stapled notarization ticket.
• The installed ChatGPT executable, bundled Codex executable, and app.asar were byte-for-byte identical to the same files in OpenAI's current official DMG for this version.
• The same exhausted trust stack temporarily failed verification for Apple system binaries and unrelated signed applications, so those verification errors were a consequence of the wedged security daemons rather than evidence that ChatGPT had been locally modified.

Reinstalling the same current build is therefore unlikely to resolve the issue.

Secondary process-management defects observed

These should be investigated separately but do not match the primary high-rate GUI launch storm:

1. Computer Use capture code retries Apple Event error -10014 recursively without a delay, deadline, or attempt limit. No matching Computer Use retry messages or helper policy events were present in the primary reset window.
2. Some optional Computer Use notification clients and Node REPL helpers remained alive after their expected work completed, indicating a separate child-reaping/lifecycle problem.

Expected behavior

• ChatGPT's main GUI executable should be launched once.
• Features that need to contact the existing instance should use persistent IPC rather than launching another GUI process.
• A denied or failed launch must not be retried indefinitely.
• syspolicyd should remain near idle when no application is intentionally being launched.

Suggested application fixes

1. Replace repeated GUI launch requests with IPC to the existing ChatGPT instance.
2. Make all launch paths single-flight.
3. Add exponential backoff, jitter, a hard attempt limit, and a circuit breaker.
4. Log the target executable, sanitized arguments, launch reason, requester, and retry count immediately before every spawn/open request.
5. Do not rely solely on requestSingleInstanceLock() because it runs after macOS has already assessed the new process.
6. Await and reap every helper child; apply timeouts and kill-on-drop behavior.
7. Replace the Computer Use -10014 immediate recursion with a permission-state event or a bounded delayed retry.

Temporary recovery

Fully quit ChatGPT first, then allow macOS to restart syspolicyd:

sudo killall syspolicyd

Closing the ChatGPT window is insufficient if the desktop process remains active.

Related public reports

• https://github.com/openai/codex/issues/25882
• https://github.com/openai/codex/issues/25243

I have the same problem

I have the same problem

Me too

It's still happening. Please!

Save my hardware

+1

+1

+1 on this

I'm on version 26.715.31925 and don't seem to be getting the issue anywhere near as much as I was before updating. Previous to this version, my M2 Pro was almost unusable with syspolicyd taking every ounce of CPU it could get.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 Windows

+1

+1

+1
I can literally run Xcode + iPhone 17 pro simulator, Safari with 15+ tabs open, Mathematica, and NEVER got my computer to crash or got that laggy. But the new Codex app made my computer crash 2 times already. And I do have 8gb M1 air. Even in the CLI sometimes I get some thermal throttle and ridiculous resource usage, but noting compares to the app.

+1

+1

+1

+1

• 1

Hey pls fix, this is super frustrating

+1

+1

+1

+1

+1

+1

Guys, stop with the +1 posts and use the 👍 on the issue instead. Thanks!

About how reliable is the codex extension for vscode? I've heard lots of issues for both the codex desktop app and CLI, i'm hoping the vscode extension doesn't inherit these issues.