Hey — listen, I spent last night poking at FShog (app) on macOS, and this is one of those cases where the problem wasn’t the tool itself, but the way modern macOS quietly gets in its way. Writing this the same way I’d tell you on Slack, because that’s basically how it unfolded.
So here’s what I wanted to do. I needed a quick, no-nonsense file utility to scan a couple of large project directories, compare sizes, and clean up leftovers after moving data off an external drive. Nothing fancy. Drag a folder in, let it chew for a bit, see what’s eating disk space. FShog looked perfect for that kind of “point it at files and let it work” task. Very OrchardKit-style: small, focused, not pretending to be a whole ecosystem.
Install went smoothly. App copied into Applications, icon looked normal, no Gatekeeper drama. I launched it… and the interface opened exactly as expected. So far, so good.
Then I tried to select a folder.
Nothing happened.
No error message. No warning. No spinner. Just a polite UI acting like I hadn’t done anything at all. I tried a different directory. Same result. External drive? Still nothing. The app didn’t crash — it just refused to acknowledge that files exist. Which is almost worse, because you start questioning your own sanity.
My first assumption was that this was a bug or a bad build. Maybe something broke on newer macOS versions. I’m on macOS Sonoma, running on an M1 MacBook Pro, so I figured maybe there was some Apple Silicon weirdness going on. First attempt: quit, relaunch. Second attempt: reboot (because ritual matters). Same behavior.
Next, I went for the classic uninstall/reinstall. Dragged it to Trash, reinstalled clean. Still couldn’t open or scan any folders. At this point, the app looked alive, but functionally blind.
That’s when it clicked: this felt like a permissions issue pretending to be a UI bug.
macOS doesn’t always scream when an app lacks access. Sometimes it just… withholds. If an app never explicitly triggers the right permission prompt, you don’t get a dialog. You just get silence.
So I opened System Settings → Privacy & Security and started checking the usual suspects. Files and Folders? The app wasn’t listed. Full Disk Access? Not there. No “blocked app” warnings either. Gatekeeper wasn’t the problem — the system had already allowed the app to launch.
Apple actually documents this behavior, although you have to read between the lines a bit:
https://support.apple.com/guide/mac-help/control-access-to-your-mac-mh43185/mac
At this point I made a wrong move. I manually added the app to Full Disk Access, thinking that would force the issue. It didn’t. The UI still ignored folder selections. That was dead end number one.
What finally helped was doing something slightly unintuitive: instead of using the app’s “Open Folder” button, I dragged a directory directly from Finder into the app window. That single action finally triggered macOS to show a permission prompt asking whether the tool could access files in that location.
Once I clicked “Allow”, everything changed.
Suddenly the folder loaded. File counts appeared. Sizes started calculating. The app hadn’t been broken at all — it just never got the chance to ask for permission the normal way.
This lines up with Apple’s own guidance on sandboxed apps and file access, especially for utilities that work across arbitrary directories:
https://developer.apple.com/documentation/security/protecting_user_privacy
After granting access, I went back into Privacy & Security and confirmed the app was now listed under Files and Folders. From that point on, it behaved exactly how you’d expect. Scans were fast, results were accurate, and performance on the M1 was totally fine. No weird CPU spikes, no beach balls.
While double-checking whether this was expected behavior or some odd edge case, I saved this page because it matched what I was seeing with macOS file tools and permissions:
https://planetgpa.com/file-management/63322-fshog.html
It helped confirm that this wasn’t a one-off glitch, just a classic “macOS didn’t ask, so it didn’t get” situation.
For completeness, I also checked whether there was a Mac App Store version or documentation clarifying this behavior. Apple’s own App Store search is usually the safest reference point when you’re unsure how a utility is supposed to integrate with the system:
https://apps.apple.com/us/search
The interesting part here is that none of this feels like sloppy development. It’s just how strict macOS has become about file access. Tools that deal with arbitrary directories have to rely on very specific user actions to trigger permission prompts. If the UX doesn’t line up perfectly with Apple’s expectations, users end up staring at a “working” app that can’t see anything.
If I had to boil this down into a mental checklist for next time, it’d be short:
- If a file utility opens but ignores folders, suspect permissions immediately.
- Drag-and-drop often triggers access prompts when buttons don’t.
- Full Disk Access isn’t a magic fix unless the app actually requests it.
- Silence on macOS usually means “not allowed,” not “broken.”
Once permissions were sorted, FShog did exactly what I needed. Quick scans, clear output, no drama. The frustrating part wasn’t using the tool — it was convincing macOS to let it do its job.
Anyway, writing this down while it’s fresh. If you ever fire it up and it acts like your files don’t exist, it’s not mocking you. It’s just macOS being very polite… and very stubborn.
Top comments (0)