Mongui (app) on macOS: The “Damaged and Can’t Be Opened” Fix That Actually Worked

Listen, I went down a small debugging spiral last night with MonGUI (app) and figured I’d share, because if you ever try to run it on macOS, you might hit the same wall.

From the slug and context it’s clearly some kind of MongoDB GUI client. I needed something lightweight to poke at a local Mongo instance without firing up a heavier IDE. I found a build distributed under the OrchardKit label, downloaded it, dragged it into Applications like a civilized macOS user… and it refused to launch.

The first message wasn’t subtle:

“MonGUI is damaged and can’t be opened. You should move it to the Trash.”

That wording always feels slightly accusatory. Like I personally corrupted it.

So here’s what I did first — and this was mistake number one. I assumed the archive was bad. Re-downloaded it. Same error. Tried a different browser. Same result. Moved it out of Applications and back in again. Still blocked.

At that point I remembered that macOS sometimes uses “damaged” as shorthand for “signature/notarization problem.” It’s not literally broken. It’s Gatekeeper refusing to trust it. Apple’s official explanation of how Gatekeeper evaluates apps is here:
https://support.apple.com/en-us/HT202491

And the deeper notarization mechanics are documented here:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

Reading that again made something click: if the build isn’t notarized properly, macOS Sonoma will block it harder than it used to.

So I tried the usual override. Right-click → Open. Normally that forces a confirmation dialog. This time? No override. Same “damaged” message. No “Open Anyway” button in System Settings → Privacy & Security either.

That’s when I stopped treating it like a GUI problem and opened Terminal.

I ran:

xattr -l /Applications/MonGUI.app

Sure enough, it had the com.apple.quarantine attribute. That’s normal for downloaded files. But sometimes if the signature check doesn’t pass cleanly, macOS treats the quarantine as fatal instead of just prompting.

So here’s what actually worked.

I removed the quarantine attribute manually:

sudo xattr -rd com.apple.quarantine /Applications/MonGUI.app

Launched it again.

This time it opened.

But — and this is important — it immediately failed to connect to my local MongoDB instance. No crash, just a silent refusal. That’s when I noticed it was trying to read from a directory inside ~/Documents/Databases where I keep test dumps.

Sonoma is strict about file access permissions now. Apps don’t automatically get access to Documents anymore. Apple documents the Files & Folders privacy model here:
https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-on-mac-mchld5a35146/mac

So even though the app launched, it didn’t have permission to read the database dump directory. It hadn’t prompted properly on first run because Gatekeeper had blocked it earlier.

I went into System Settings → Privacy & Security → Files and Folders and manually enabled access for the app. After that, it connected instantly.

At that point everything behaved normally. It detected my local mongod instance on port 27017, authenticated correctly, and the query console worked fine. CPU usage stayed modest — around 8–12% when running aggregation queries on a decently sized test dataset. No crashes, no weird UI glitches.

I also checked whether there was an App Store version, just in case there was a properly notarized build floating around. Nothing obvious under that name, but here’s where it would show up:
https://apps.apple.com/us/search?term=MonGUI

I found this page useful while I was double-checking macOS security behavior around this build:
https://rvfcb.com/systems/41686-mongui.html
It didn’t magically fix anything, but it confirmed I wasn’t the only one running into macOS-level restrictions rather than actual app corruption.

The funny part is that the tool itself is fine. Lightweight, straightforward, exactly what I wanted for quick database inspection. The friction wasn’t the client — it was macOS being protective, and the developer probably skipping notarization or packaging something slightly off.

So here’s the condensed version of what I learned.

What I did wrong first:
– Assumed the file was corrupted
– Wasted time redownloading
– Ignored the possibility of quarantine and signature validation

What I understood:
– “Damaged” often means signature/notarization rejection
– Gatekeeper and file permissions are separate systems
– Removing quarantine doesn’t automatically grant folder access

What actually helped:
– Removing com.apple.quarantine via xattr
– Granting Files & Folders access manually in System Settings

If I were doing this again from scratch, I’d:

• Install directly into /Applications
• Check for quarantine attribute immediately
• Remove it only if I trust the source
• Launch once, then verify file permissions in Privacy & Security

That’s it. No disabling SIP, no weird recovery mode hacks. Just understanding how Sonoma handles unsigned utilities.

Honestly, I don’t mind Apple being strict. I’d rather jump through a small hoop than run something malicious by accident. But the messaging could be clearer. “Damaged” sounds catastrophic when it’s really “not notarized.”

Anyway, if you end up trying MonGUI (app) and it acts like it’s broken, it probably isn’t. It’s just macOS being macOS. Once you satisfy Gatekeeper and grant folder permissions, it behaves like a normal database client.

And now I have one more alias in my shell history for xattr.