Your Mac is protecting you! (but is it worth it?)

Your Mac is trying to keep you safe. That is good. But when I run Codex all day, with parallel agents, computer use, browser work and a lot of local process launches, the next question becomes interesting too: how much performance does that safety cost?

So I made a small benchmark: macos-gatekeeper-codex-benchmark. It is not a formal paper. It is a practical test from my real workflow on a MacBook Air.

What I was actually testing

On macOS, part of this protection comes from Gatekeeper and the syspolicyd process. Apple describes Gatekeeper as a technology that helps make sure only trusted software runs on a Mac. For normal use, that is mostly invisible. You download an app, macOS checks it, and you open it. If you want the deeper rabbit hole, Scott Knight's syspolicyd internals write-up is a good technical read.

My workflow is different. Codex can run multiple jobs at once, use browser/computer control, execute terminal commands, hand work to other agents and create a lot of small local process launches. That is exactly where tiny system checks can become very visible.

I did not want to disable Gatekeeper globally. That might be fast, but it is a bad default. I wanted to know whether the issue was quarantine metadata, first-run assessment of many executable paths, or something else.

The benchmark setup

The repo includes the scripts and the results. The main benchmark ran codex help repeatedly under a few conditions:

RUN_ID=baseline TOTAL=20 CONCURRENCY=5 REPS=3 CMD_TIMEOUT=8 scripts/run-codex-gatekeeper-benchmark.zsh

The second benchmark was smaller and cleaner. It used a tiny locally compiled Mach-O executable and compared one clean path, one quarantined path, many clean copies and many quarantined copies:

TOTAL=100 CONCURRENCY=10 REPS=5 CMD_TIMEOUT=5 MANY_COUNT=50 scripts/run-case-study-extras.zsh

I also tested temporary syspolicyd priority changes and a daemon restart:

renice +10 -p <syspolicyd-pid>
renice +19 -p <syspolicyd-pid>
killall syspolicyd

Those are not commands I would recommend as a normal fix. They were there to check whether they were real mitigations. They were not.

What the numbers said

The easiest way to read the benchmark is not through the internal test names. It is this:

The normal, trusted Codex install was fast. Repeatedly launching the real Codex binary that macOS had already seen stayed basically instant for my workflow. In the small burst test, 20 launches finished in a fraction of a second.

The slow part was different: creating a lot of new executable paths and asking macOS to run them right away. When I copied the Codex binary into many fresh locations and launched those copies in parallel, the first run jumped from “blink and it is done” to roughly 11 seconds. That is the part you feel as the machine suddenly dragging.

The tiny executable test made the same point in a cleaner way: a tiny trusted helper could be launched 100 times almost instantly, while the same kind of helper with quarantine attached did not really get through the run before the timeout. New clean files were better than quarantined files, but the first run could still be noticeably slower until macOS assessed them once. I also tried the tempting system-level fixes, like lowering syspolicyd priority and restarting it, but they did not solve the real problem. The better fix is more boring: keep trusted tools clean, avoid unnecessary executable path churn, and warm up new generated tools before throwing a lot of parallel agents at them.

What I am not taking from this

I am not taking the lesson as "disable Gatekeeper". Actually the opposite. I did not run spctl --master-disable, and I do not want this to become a generic performance trick.

The better rule is narrower:

xattr -p com.apple.quarantine /path/to/trusted/tool
xattr -d com.apple.quarantine /path/to/trusted/tool

That only makes sense for tools I actually trust and understand. Not random downloads. Not a global cleanup.

The other practical rule is about path churn. If a workflow creates many executable files, do not immediately spawn all of them at high concurrency. The first run may be slower because macOS is assessing new paths. Warming them at lower concurrency can be better than letting a large agent run make the system feel stuck.

What I will probably do

I will probably keep everything on. The reason is simple: I can offload a lot of the pressure. If Codex is doing heavier work, I can hand jobs from my workstation MacBook Air to my Mac mini or to my Linux server. That is a better tradeoff for me than weakening security on my main laptop.

But for performance maxers, this is an interesting thing to look into. Not because they should turn off protection, but because they can find the specific places where macOS keeps checking things that are already trusted inside their own workflow.

The full benchmark, scripts and raw results are here: github.com/vvitovec/macos-gatekeeper-codex-benchmark. You can also see more of my practical build work on my projects page.

If you work with coding agents, automation or custom build tools on a Mac, it is worth checking whether your bottleneck is really just CPU. Sometimes it is the security layer doing exactly what it is supposed to do. Just very often.