Why macOS Refused to Run WIT — and What Finally Fixed I

Listen, I went down a bit of a rabbit hole last night with The WIT Programming Language (app) on macOS, and I’m writing this the same way I’d message you on Slack after figuring out why something dumb was broken.

I wanted to poke at WIT locally — nothing heroic, just compile a couple of examples and see how the language feels. Fresh-ish macOS Sonoma 14.2, MacBook Pro on M1 Pro, normal user account, developer tools already installed. I’d seen WIT mentioned alongside some OrchardKit-related tooling and finally had an evening to try it.

Download went fine. Binary looked clean. I ran it.

And macOS immediately went: nope.

Not even dramatically. Just the classic “can’t be opened” behavior where the OS pretends it’s protecting you but refuses to explain itself.

At first, I assumed I’d messed something up.

I double-clicked the executable in Finder and got the usual warning that the app couldn’t be opened because Apple can’t check it for malicious software. Okay, expected. I right-clicked → Open, thinking I’d get the override dialog.

Nothing. No “Open Anyway” button. No follow-up. Just silence.

So I tried running it from Terminal instead, because Terminal never lies, right?

./wit

Same thing. Immediate exit. No output. Exit code zero, which is honestly insulting. That’s when I made the first wrong call: I re-downloaded everything.

I grabbed the archive again, unpacked it manually, even moved it into /Applications because sometimes Gatekeeper behaves differently there. Still blocked. Same behavior. At this point I briefly wondered if the binary was corrupted or missing a dependency, but otool didn’t show anything obviously broken.

What finally clicked is that this wasn’t a crash or a runtime failure. It was macOS deciding the app didn’t deserve to run and not bothering to tell me clearly.

Apple actually documents this, though you only remember that after losing half an hour. Gatekeeper can block execution before an app gets a chance to display anything, especially if it’s a standalone CLI-style binary distributed outside the App Store. Their official explanation lives here:
https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac

So I checked the extended attributes.

xattr -l wit

There it was: com.apple.quarantine.

Removing it:

xattr -dr com.apple.quarantine wit

After that, the tool finally launched. No fanfare. Just… worked.

Or so I thought.

The next failure was sneakier. WIT started, printed its version, then failed when trying to read files from my working directory. No permission prompt, just errors about denied access. This is the part where macOS’s privacy model becomes aggressively unhelpful.

On modern macOS, even command-line tools can be restricted from accessing user directories unless they’re explicitly allowed. And sometimes the OS won’t ask — it just blocks.

The fix wasn’t inside the tool at all. It was in System Settings.

Privacy & Security → Full Disk Access.

I had to manually add the WIT binary there. Relaunch after that, and suddenly file access was fine. Builds ran. Examples compiled. No more mysterious failures.

Apple’s breakdown of how file and folder permissions work (and why tools behave like this now) is here:
https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-mchld5a35146/mac

Once everything was unblocked, WIT behaved exactly how you’d expect a language toolchain to behave. No hidden background services, no weird helpers sticking around in Activity Monitor. It’s very much “do your job and exit,” which I appreciate.

I also checked whether there was an App Store–distributed version, just to see if Apple treats it differently. There’s an official search entry under the same name, but not the exact build I was using:
https://apps.apple.com/us/search?term=WIT%20Programming%20Language

Which explains why the standalone binary trips more alarms — it’s unsigned and not notarized. Apple’s developer docs on notarization spell this out pretty clearly:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

While debugging, I found this page useful as a reference point for what I was dealing with and bookmarked it for later:
https://rvfcb.com/developer/79595-the-wit-programming-language.html

So, what actually helped — and what didn’t.

What didn’t help:
– Re-downloading the archive multiple times
– Moving the binary around hoping Finder would behave differently
– Assuming it was an M1 vs Intel issue (it wasn’t)

What did help:
– Removing the quarantine attribute manually
– Granting explicit disk access in Privacy & Security

If I were doing this again, I’d do it in this order, without the detours:

1. Download the tool
2. Check and remove com.apple.quarantine if it’s there
3. Add the binary to Full Disk Access before running anything
4. Then start debugging actual problems

macOS security isn’t wrong here, but it’s incredibly quiet. And silence is what makes you think the app is broken when it’s really the OS standing in the doorway with crossed arms.

Anyway — that’s the story. WIT itself seems fine once macOS stops pretending it’s radioactive. Just thought I’d save you the same hour of head-scratching if you try it.