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: and the 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 . 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.