JPersist on macOS: When Gatekeeper Blocks the Launch (and How I Fixed It)

Hey,

So, I spent half of yesterday messing around with JPersist (app) from OrchardKit, and I figured I’d write this down while it’s still fresh. What was supposed to be a quick install-and-test turned into a classic macOS “why won’t you open” situation.

The goal was simple: install JPersist on my M2 Mac mini (macOS Sonoma 14.2), hook it up to a local project folder, and see how it handles persistent data storage for a small internal tool. Nothing fancy. Downloaded the build, dragged it to /Applications, double-clicked… and macOS hit me with:

“JPersist can’t be opened because Apple cannot check it for malicious software.”

Alright. Standard Gatekeeper stuff. I’ve been here before.

First thing I tried was the polite method: right-click → Open. Sometimes that’s enough to get the system to show the “Open Anyway” option and remember it. This time, it let me click Open… the dock icon bounced once… and then it vanished. No window. No crash dialog. Just silent refusal.

At that point, I assumed maybe the download was corrupted. Deleted it. Re-downloaded from the OrchardKit page. Same behavior. So not a bad archive.

Then I went slightly nuclear and temporarily disabled Gatekeeper with:

sudo spctl --master-disable

Launched again. Still nothing. That’s when I realized this wasn’t just a surface-level Gatekeeper block. It was likely quarantine attributes on internal binaries inside the app bundle. macOS can let the outer .app open but still block helper executables if they’re not properly notarized.

Apple actually explains this behavior pretty clearly in their Gatekeeper documentation here: https://support.apple.com/en-us/HT202491 and more technically in the notarization overview at https://developer.apple.com/documentation/security/notarizing_macos_software. Dry reading, but it matched exactly what I was seeing.

So I switched to Terminal and removed the quarantine flag from the app:

xattr -d com.apple.quarantine /Applications/JPersist.app

Tried launching again. This time the window actually appeared. Progress. But as soon as I attempted to initialize a workspace, the app froze and then quit. So I had half a fix.

That’s when I remembered the subtle but important detail: you need to remove quarantine recursively. The main bundle isn’t the only thing that carries the flag; embedded binaries do too.

So the real command was:

sudo xattr -r -d com.apple.quarantine /Applications/JPersist.app

That -r flag is doing all the heavy lifting here.

After that, the app launched cleanly and stayed open. No more bounce-and-vanish routine. I also had to go into System Settings → Privacy & Security and explicitly allow it under the “Open Anyway” section. Once approved, it behaved normally on launch.

But that wasn’t the end.

When I tried connecting it to a folder inside Documents, I got a vague “Access denied” message. No system prompt popped up. macOS sometimes doesn’t automatically trigger the permission dialog for non-App Store software.

So I went to System Settings → Privacy & Security → Files and Folders, and sure enough, JPersist was listed but had no access enabled. I toggled Documents and Desktop access, relaunched the app, and suddenly workspace initialization worked perfectly.

I found this page useful while debugging the macOS security side of things — it walks through the quirks around this particular build and helped confirm I wasn’t missing something obvious: https://stmlare.xyz/office-and-productivity/90521-jpersist.html. It lined up with what I was seeing on Sonoma.

Just to double-check whether I could avoid the whole quarantine mess, I looked for an official Mac App Store version here: https://apps.apple.com/search?term=JPersist. If you can install through the App Store, macOS handles signing and sandboxing more smoothly. In this case, the direct OrchardKit build was newer, so I stuck with that and documented the fix for future me.

Performance-wise, once it was actually running, the tool was solid. No weird CPU spikes on Apple Silicon, no excessive memory usage. Indexing a medium-sized project folder (~2 GB of mixed files) completed without drama. The problem was never stability — it was macOS security layers getting in the way.

So here’s the short checklist I wish I had started with:

• Move the app to /Applications first.
• Run sudo xattr -r -d com.apple.quarantine /Applications/JPersist.app.
• Launch once and approve it in Privacy & Security.
• Manually grant Documents/Desktop access before setting up a workspace.
• Avoid the built-in updater until you’re sure quarantine flags aren’t reintroduced.

If I had done that from the start, the whole thing would have taken five minutes instead of an hour of trial and error.

It’s funny — macOS security is doing exactly what it’s designed to do, and I actually appreciate that. But when you’re working with independent developers like OrchardKit who distribute outside the App Store, you have to know how the OS enforces notarization and quarantine behind the scenes. Otherwise, you end up staring at a dock icon bouncing once like it’s mocking you.

Anyway, now it runs cleanly on Sonoma, survives reboots, and opens projects without permission errors. The fix wasn’t complicated — just slightly hidden behind one tiny -r flag and a couple of privacy toggles.

Next time I see “cannot be opened” or a mysterious silent exit, I’m going straight to recursive xattr removal before I even try anything else. Saves time. Saves sanity.