Codex Got Blocked by macOS. I Reinstalled Instead of Bypassing It.

#ai #devtools #security #macos

I got the macOS dialog nobody wants to see: Codex was blocked as “malware” and moved to the Trash.

That sounds dramatic. In practice, the useful reaction is not panic and not blind bypassing. It is boring tool hygiene: understand why macOS is blocking the binary, remove the stale install, reinstall from an official source, and verify the version you are actually running.

What happened

The warning appeared on an older Codex install on macOS. Apple’s security layer treated the binary as untrusted and moved it away before launch. That does not automatically prove that the local machine is infected, but it also is not a warning I want to dismiss with a random terminal incantation.

The current context matters. OpenAI published security updates for macOS apps after supply-chain incidents involving developer tooling. In the TanStack npm response, OpenAI said it rotated code-signing certificates as a precaution and required macOS users to update OpenAI apps. The same post says OpenAI found no evidence of customer data exposure, no evidence that OpenAI products were altered, and no evidence of malicious software being signed with OpenAI certificates.

That distinction is the whole point. The user-facing alert says “malware” because macOS is enforcing trust decisions around signed software. The practical fix is to stop running the stale signed artifact and move to a currently signed release from the official channel.

What I did

I treated the warning as real until proven otherwise. I did not try to force-open the existing binary. I removed the old install path, cleaned up the command that was being resolved by my shell, and reinstalled Codex from the official source.

For the CLI, OpenAI’s current docs show the standalone installer flow:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

If you use npm or another package manager, the same principle applies: remove the old package, reinstall cleanly, then check which binary your shell resolves. The part people often skip is verification. After reinstalling, I want to know that codex points to the expected path and that the version is current.

A simple sanity check looks like this:

which codex
codex --version

If the path still points into an old global install, a stale Bun/npm directory, or something already moved to Trash, the reinstall did not fix the thing you are actually launching.

What I would not do

I would not tell people to just remove quarantine attributes as the first move. There are cases where xattr is a valid local repair step, but using it as the default answer trains the wrong reflex. If a developer tool that can read and edit your repo gets blocked, the first question should be provenance, not convenience.

Where did this binary come from? Was it installed from the official Codex channel? Is the version at or above the safe/current line OpenAI published? Is there another codex earlier in PATH?

Only after those questions are boring should you think about local macOS metadata oddities.

The bigger lesson

AI coding tools are now part of the developer supply chain. They sit close to source code, credentials, shell access, package managers, and deployment scripts. That makes boring operational habits more important, not less important.

Pin what matters. Reinstall from official sources. Keep old global packages from shadowing newer installs. Verify paths. Read vendor security notes before turning a warning into a workaround.

The useful part is remembering why the simple fix is the right one: trust should come from source, signature, version, and reproducible install path, not from wanting the tool to launch right now.

Sources: