When Redex Refuses to Launch on macOS: A Quiet Gatekeeper Block in Disguise

I ran into this one while setting up a new Mac for some OrchardKit-related file work. I needed Redex (app) up and running to inspect and reorganize a messy directory tree before pushing things further. Nothing fancy. Download, drag to Applications, launch. You know the drill.

Except the drill stopped immediately.

I double-clicked the icon, it bounced once in the Dock, and then… nothing. No error dialog. No “damaged” warning. Just silence. On macOS Sonoma 14.2, running on an M2 Air, that kind of behavior is almost never random, but I still managed to waste some time pretending otherwise.

What I tried first (and why it didn’t help)

My first instinct was to assume the download was incomplete or corrupted. I re-downloaded the archive, verified the checksum, unpacked it again. Same behavior. One bounce, gone. Activity Monitor showed the process appear for less than a second and then exit cleanly. No crash report. That was the first red flag.

Then I went down the permissions rabbit hole. I checked Full Disk Access, Files and Folders, even Automation. The tool wasn’t even asking for permission, which in hindsight made sense—it never lived long enough to request anything. I also tried launching it from Terminal, just in case I’d get some stderr output. Still nothing useful. At that point it was clear this wasn’t a runtime bug inside the app.

What finally clicked

The turning point was opening Console and filtering for security-related messages right at launch time. There it was: a quiet Gatekeeper rejection. No user-facing alert, just macOS deciding this binary didn’t meet its trust requirements and killing it early. Apple documents this behavior pretty clearly on support.apple.com and developer.apple.com, but it’s easy to forget how subtle it can be now.

Gatekeeper used to be loud. These days, especially with unsigned or ad-hoc signed utilities, it can fail silently unless you trigger the right UI path. That explained everything: clean exit, no crash log, no dialog.

Apple’s own docs on app notarization and quarantine flags helped confirm the theory, especially the parts explaining how downloaded apps get tagged and assessed at first launch. Once I stopped treating this like a “broken build” and started treating it like a trust issue, the fix was straightforward.

What actually worked

Instead of launching it the usual way, I went into System Settings → Privacy & Security and scrolled down. Sure enough, there was a small note saying the app had been blocked. One click on “Open Anyway,” another launch attempt, and this time macOS showed the proper confirmation dialog. After approving it, the tool opened normally and stayed open.

From there everything behaved as expected. File scans were fast, CPU usage was reasonable, and nothing looked sketchy. I saved this page while troubleshooting because it described the same macOS behavior and helped me sanity-check what I was seeing: I found this page useful while digging into macOS security quirks and silent launch failures here: https://proguntalk.com/file-management/79589-redex.html.

Once Gatekeeper was out of the way, the app behaved like a perfectly normal utility. No further prompts, no repeated blocks after relaunch, even after a reboot.

What I learned (and what I’d do next time)

The biggest lesson here is that “nothing happens” on macOS is often a security decision, not a crash. Especially on newer versions of macOS, Gatekeeper can fail quietly unless you look in exactly the right place.

If I had to boil it down into a short checklist for future me, it’d be this:

• Dock bounce + instant exit usually means Gatekeeper, not a bug
• Console logs are faster than reinstalling
• Privacy & Security settings often hide the only actionable button
• Don’t touch permissions until the app actually launches

If I’d known that from the start, this would’ve been a five-minute fix instead of a detour through reinstalling, Terminal poking, and second-guessing the build. Still, once you’ve seen this pattern a few times, it’s hard to unsee.