Hey, listen — yesterday I went down a small rabbit hole with Commander Stalin (app) on macOS, and I figured I’d write it up for you while it’s still fresh. This isn’t a horror story, more like one of those quiet “why is macOS like this?” evenings that ends with a couple of useful notes for the future.
So the original plan was boring and simple. I wanted a lightweight two-pane file manager to quickly clean up a messy project folder. Finder was doing its usual “helpful but slow” thing, and I remembered this tool from OrchardKit that people kept mentioning as a no-nonsense alternative. Downloaded it, dragged it to Applications, double-clicked… and immediately got the classic macOS message that the app “can’t be opened because Apple cannot check it for malicious software.”
At first I shrugged. Gatekeeper. Seen this a hundred times. I right-clicked the app, chose Open, confirmed I trusted it, and expected to move on. Instead, the app icon bounced once in the Dock and disappeared. No error dialog. No crash report. Just silence.
My first wrong move was assuming it was a bad build. I re-downloaded it, checked the checksum, even tried launching it from Terminal just to see if anything printed. Terminal gave me a vague “killed: 9” message, which is macOS speak for “I don’t like what you’re doing, but I won’t tell you why.” At this point I briefly considered that maybe it simply didn’t like Apple silicon, since I’m on an M1 MacBook Air running macOS Sonoma 14.2. That turned out to be a dead end.
Second attempt was permissions. I went into System Settings → Privacy & Security and manually allowed the app under “Security,” assuming it just needed a nudge. Still nothing. The process died instantly every time I tried to launch it. That’s when it clicked that this wasn’t just Gatekeeper being cautious — it was sandboxing combined with file access.
The app tries to scan directories on launch to restore the last session. On macOS, that means touching parts of the filesystem that are protected by default. If an unsigned or not-fully-notarized app does that before the system grants it permission, macOS just shuts it down. No warning. No prompt. Very polite, very opaque.
What finally worked was launching it once with a clean slate. I removed its preferences folder from ~/Library/Preferences, then went back to Privacy & Security and pre-approved file access by temporarily adding it to “Full Disk Access.” After that, the app launched normally, showed its interface, and only then asked for access in a way macOS was happy with. Once it was running, I removed Full Disk Access and left it with just the folders I actually needed.
While I was troubleshooting, I found this page useful and bookmarked it as part of my macOS notes: https://planetgpa.com/file-management/29731-commander-stalin.html — not because it magically fixed things, but because it helped confirm I wasn’t the only one seeing this behavior on newer macOS versions.
For sanity checks, I also skimmed Apple’s own docs on Gatekeeper and notarization on developer.apple.com, and the user-facing explanation on support.apple.com about why apps can be blocked or silently terminated. Apple is very clear about the rules; they’re just not great at surfacing them in real time. I also checked the App Store search on apps.apple.com to confirm there isn’t a sandboxed build there yet — there isn’t, which explains the friction.
Once everything was set up properly, the tool behaved exactly how I wanted. Fast directory traversal, predictable keyboard shortcuts, no weird background indexing. It felt solid. No crashes, no CPU spikes, nothing suspicious. The irony is that the actual app wasn’t the problem at all; it was the order in which macOS wanted permissions handled.
If I had to do it again, I’d follow a much shorter checklist:
- Launch once with minimal saved state (no previous preferences).
- Grant access deliberately, not reactively.
- Only widen permissions temporarily, then tighten them back up.
That’s it. Nothing dramatic, just another reminder that on modern macOS, how an app starts is sometimes more important than what it does. Hope this saves you an evening the next time Gatekeeper decides to play quiet guardian.
Top comments (0)