macOS shows “Malware Blocked” alert for Codex helper on Codex App 26.519.41501

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

• #23822
• #23195
• #23308
• #23649

Powered by Codex Action

I have the same issue, both with cli and desktop app

<img width="1228" height="461" alt="Image" src="https://github.com/user-attachments/assets/33d2c499-d1b3-4005-88f8-eb85644d0f13" />

I have the same issue!

<img width="558" height="294" alt="Image" src="https://github.com/user-attachments/assets/8ea9cc41-6ded-41bc-b5e6-a5e29bc5f38e" />

Same.

Same issue here.

<img width="532" height="544" alt="Image" src="https://github.com/user-attachments/assets/fd971148-6afa-4960-a8d7-7ca310848deb" />

Same hints.

It's a fake wbesite.

Same here after updating codex on terminal

Same here and I haven't updated codex cli in a couple of months.

not sure about the cause but redownloading at least installed a build that is not flagged by Apple.

It's a fake wbesite.

No it's not. It's MacOS. This isn't Windows

Got this as well today, I checked the codesign and it seems like the legitamite com.openai.sky.CUAService

Got this today, asked another agent to investigate what triggered the protection, here is the finding (setup specific):

Here's the full chain, grounded in what the logs actually showed.

Timeline

Jun 30, 15:36:22  syspolicyd: GK evaluateScanResult: 2   ← Gatekeeper verdict = DENY (malware)
Jun 30, 15:36:25  syspolicyd: "Terminating process due to Malware rejection" ×8
Jun 30, 15:37:01–34  more GK scans + rejections, ids surface:
                    id: liboxc_parser_napi.dylib
                    id: liboxc_resolver_napi.dylib
Jun 30, 15:37:xx  macOS moves the flagged copy to Trash, shows the alert you saw

Chain of events

1. Another agent invoked codex to review code. Codex, as part of a review, ran this repo's lint gate — oxlint (oxlint --type-aware is the gate here, per your CLAUDE.md).
2. oxlint/oxc ship as native binaries, not JS. They're Rust tools distributed as prebuilt Node addons — @oxlint/binding-darwin-arm64, @oxc-parser/binding-darwin-arm64, @oxc-resolver/binding-darwin-arm64. The .node files are Mach-O dylibs whose internal install-names are literally liboxc_parser_napi.dylib and liboxc_resolver_napi.dylib — the exact names that appear in the rejection log.
3. Those binaries carry the quarantine bit + are only ad-hoc signed. pnpm downloads them from npm over the network, so they inherit com.apple.quarantine, and they have no Apple Developer ID / notarization ticket. That combination forces Gatekeeper (syspolicyd) to run a full XProtect signature scan every time the binary is executed, rather than trusting a notarization ticket and moving on.
4. XProtect's signature matched — falsely. Your XProtect signature DB (v5347) contained a Yara rule whose byte pattern collides with something in the oxc Rust binary. Gatekeeper returned evaluateScanResult: 2 (deny/malware). This is a signature false-positive, not compromised code.
5. macOS enforced the verdict. syspolicyd killed every process trying to load the binary (Terminating process due to Malware rejection, ~24 times as oxlint spawned parser/resolver workers and retried), moved the offending copy to Trash, and popped the "…contains malware, moved to Trash" system alert. The codex lint run failed as collateral.

Root cause

Apple XProtect shipped an over-broad malware signature that false-matches oxc/oxlint's ad-hoc-signed Rust native .node binaries. The trigger was simply codex running the linter, which loaded those binaries and forced a Gatekeeper scan.

Three conditions had to line up — and all three are properties of how oxc is packaged, none of them your machine being compromised:
- No notarization → Gatekeeper scans the binary itself instead of trusting a ticket.
- Quarantine bit (npm download) → the scan happens on execution.
- Broad XProtect Yara rule → false match on Rust-compiled bytes.

Why it's provably a false positive (not real malware)

The decisive tell is which subsystem flagged it:
- Gatekeeper open-time scan (syspolicyd) said malware → this is the signature-matching path that produces false positives.
- XProtect Remediator — the actual background anti-malware scanner that hunts real infections — reported 0 detections in 30 days.

Real malware trips Remediator. A packaging false-positive only trips the open-time Gatekeeper signature check. You got the second, not the first — plus a clean Trash, clean quarantine DB, no rogue LaunchAgents, and no third-party AV.

Why it "healed" itself

oxlint --version runs fine now and all bindings are present, so the flagged copy was already replaced. Most likely one of: a fresh pnpm install re-extracted the binding from the content-addressable store; the store copy (no quarantine bit) survived while only a quarantined worktree copy got trashed; or once Gatekeeper cached the cdhash assessment, later loads stopped being rescanned. Either way, if it recurs and actually breaks lint, pnpm install re-extracts the binary and clears it.

result: Root cause — codex ran the repo's oxlint gate, which loads oxc/oxlint's ad-hoc-signed, quarantine-flagged Rust native .node binaries (liboxc_parser/resolver_napi.dylib); XProtect signature DB v5347 has an over-broad Yara rule that false-matches them, so Gatekeeper (syspolicyd) returned a malware verdict, killed the process, and trashed the file with a system alert. It's an Apple XProtect packaging false-positive, not an infection — the real AV scanner (XProtect Remediator) shows 0 detections and the toolchain already recovered.

Confirming this on the codex-CLI (npm), with a deterministic reproduction and the exact binary path the original report was unsure about.

Environment: @openai/codex@0.125.0 (via npm install -g) · macOS 26.5.1 (25F80), Apple Silicon arm64 · Node v20.19.6 · XProtect 5347 / Remediator 157.

Trigger (deterministic): the vendored native CLI binary at …/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/codex/codex — a 181 MB Mach-O 64-bit executable arm64. macOS fires "Malware Blocked and Moved to Trash — 'codex' was not opened because it contains malware" and deletes it on first execution.

Downstream symptom: because macOS trashes the binary, every subsequent codex command (including codex --version, codex login status, codex exec) fails with Error: spawn …/codex ENOENT, even though the file was present a moment earlier. Reinstalling restores it; the next exec trashes it again.

Verified it's a signing gap: codesign -dv reports no signature and spctl -a -t exec returns "invalid API object reference" → the shipped codex-darwin-arm64 binary is unsigned and unnotarized, which is what XProtect is flagging (almost certainly a false positive).

Repro:

1. npm install -g @openai/codex@0.125.0 on macOS 26.x arm64.
2. Run any codex command → malware dialog, binary trashed.
3. All later codex calls fail with spawn … ENOENT.

Ask: codesign + notarize the macOS native binaries. Ad-hoc self-signing isn't viable against an XProtect (malware) verdict, and disabling XProtect isn't acceptable, so this needs a signed/notarized release (and/or coordinating with Apple to clear the signature).