Listen, I was tinkering last night with Centaurus Platform (app) on my Mac, the one OrchardKit mentioned on their site, and I finally figured out why it kept crashing on launch.
I wasn’t even doing anything fancy. I just wanted to get it running locally to manage a couple of internal dashboards and some file-based workflows. Installed it, dragged it into Applications, double-clicked… and boom. The icon bounced once in the Dock and disappeared. No error dialog. Nothing helpful. Just that silent macOS “nope.”
At first I assumed it was the usual Gatekeeper thing. You know the “can’t be opened because Apple cannot check it for malicious software” message. Apple’s Gatekeeper documentation is pretty clear about how that works:
https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df/web
But that wasn’t the case. There was no warning. It technically opened, then immediately crashed.
What I did first (and this was my mistake) was start poking around randomly. I re-downloaded the DMG. Reinstalled. Cleared the app from Applications and re-copied it. Restarted the Mac for good measure. Zero difference.
Then I checked the App Store just in case there was a sandboxed or notarized build there:
https://apps.apple.com/us/genre/mac/id39
No official listing for Centaurus Platform. So this was definitely the direct download version.
After that, I opened Console and filtered by the app name while launching it again. That’s when I finally saw something useful: it was failing on startup because it didn’t have permission to access Documents and Desktop. macOS was silently denying access, and instead of prompting properly, the app just crashed.
That’s when it clicked. Sonoma tightened a lot of privacy defaults. If an app isn’t properly prompting for Full Disk Access or Files and Folders permissions, it can just die without explaining itself.
So what I understood at that point: this wasn’t a corrupted app, not a broken binary. It was macOS privacy controls blocking file access, and the app wasn’t handling that gracefully.
The actual fix was simple once I knew what to look for.
I went to:
System Settings → Privacy & Security → Files and Folders
Centaurus Platform wasn’t even listed. That meant macOS had already blocked it before giving a proper dialog. So I manually added it under:
Privacy & Security → Full Disk Access
Enabled the toggle. Relaunched.
And just like that, it stayed open.
No crash. The UI loaded. Projects appeared. Everything normal.
I also found this page useful while digging through details about this build and how it integrates with macOS: https://technotafastore.xyz/office-and-productivity/65562-centaurus-platform.html — mostly to confirm I was using the expected desktop version and not some outdated fork.
After getting it stable, I went one step further. I removed it from Full Disk Access and tested more granular permissions instead. Turns out it only actually needs access to specific folders it indexes. So a cleaner setup was:
-
Launch the app.
-
When macOS prompts for folder access, approve the specific directories.
-
Only use Full Disk Access if it still crashes.
One more thing I discovered (and this one’s subtle): if you previously denied access, macOS sometimes won’t re-prompt. In that case, you have to reset permissions with:
tccutil reset All com.centaurus.platform
Then relaunch so it can ask again.
Apple’s developer documentation on app sandboxing and privacy explains why this happens:
https://developer.apple.com/documentation/security/app_sandbox
It’s very protective, which is good. But from a user perspective, it feels like the app is broken when it’s really just being blocked.
Another thing I tried before figuring this out — and this didn’t help — was running it from Terminal to catch stderr output. It did show a permissions-related message, but nothing actionable. The root cause was still TCC (Transparency, Consent, and Control) denying file access.
After I stabilized permissions, performance was fine. No more sudden exits. CPU usage normal. No memory spikes. So the “crash” was really just macOS refusing file reads at launch.
If I had to summarize the quick checklist for next time, it would be:
-
Check Console immediately when an app silently closes.
-
Look under Privacy & Security before assuming corruption.
-
Reset TCC if permissions were denied earlier.
-
Only grant Full Disk Access if absolutely necessary.
I honestly lost about an hour because I treated it like a bad install instead of a permissions issue. Classic wrong assumption. I kept thinking “maybe it’s not notarized properly,” when in reality it was macOS doing exactly what it’s designed to do.
Anyway, if you run into the same thing with Centaurus Platform on Sonoma or Ventura, don’t waste time reinstalling five times like I did. Go straight to privacy settings. It’s almost always that now.
And yeah, OrchardKit probably assumes users are comfortable tweaking permissions, but macOS has gotten stricter every year. It’s not 2018 anymore where everything just launches.
Now that it’s working, it’s actually pretty solid. Just needed the system to stop protecting me from it.