Listen, I spent last night tinkering with AzkaOS (app) on macOS, and I figured I’d just write this the same way I’d explain it over Slack. Not a tutorial, not a teardown — just “here’s what broke, here’s why, and here’s what finally fixed it.”
Context first. This build sits in the OrchardKit ecosystem, and I was testing it as a local utility — nothing fancy, just pointing it at a folder with configs and letting it do its thing. Machine is a MacBook Air M2, macOS Sonoma 14.3, clean user account, default security settings. I install the app, launch it, UI comes up instantly, looks healthy… and then it can’t see any files.
Not “wrong files.” Not “unsupported format.” Just nothing. Empty panels, no errors, no prompts asking for access. It behaved like my disk was completely empty, which was impressive in a very unhelpful way.
What I tried first (and why it didn’t work)
My first instinct was to assume I messed up the path. Maybe sandboxing, maybe relative vs absolute paths. I moved the same folder into Documents, then into Desktop, then into Downloads. Same result. The app UI refreshed, spinner blinked, and… still zero files.
Next attempt was the classic restart-and-retry maneuver. Relaunched the app. Rebooted macOS. Even reinstalled the tool just to clear my conscience. Still nothing. At this point I was suspicious that the build itself was broken, but the lack of any visible error felt odd. Most broken apps at least complain.
I also checked Activity Monitor to see if it was hanging or choking on I/O. Nope. CPU barely moved. Memory flat. The app thought everything was fine.
The moment it clicked
What finally tipped me off was opening System Settings > Privacy & Security, not because I expected anything specific, but because I’d been burned before by macOS being too quiet. And there it was: under Files and Folders, AzkaOS wasn’t listed at all.
That’s the key detail. On modern macOS, an app doesn’t always get auto-listed in Files & Folders permissions unless it explicitly requests access in a way the system recognizes. If it doesn’t, the OS doesn’t prompt you — it just denies access silently. No dialog, no warning, no red text. Just an empty result set and a developer wondering why reality stopped existing.
Apple actually documents this behavior, but you have to know what to search for. This support page explains how macOS handles file access permissions at a high level:
https://support.apple.com/en-us/HT210596
And the developer-side explanation (which is more honest about how strict this is now) lives here:
https://developer.apple.com/documentation/security/app_sandbox
Once I connected those dots, the behavior made sense. The app wasn’t crashing. It wasn’t misconfigured. It simply didn’t have permission, and macOS wasn’t going to volunteer that information.
What actually worked
The fix was simple, but not obvious.
I manually added the app to Full Disk Access. System Settings → Privacy & Security → Full Disk Access → toggle on. macOS asked for confirmation, I approved it, relaunched the app… and suddenly all my files were right where they were supposed to be. No code changes. No reinstall. No reboot.
After that, I dialed it back. Removed Full Disk Access, then re-ran the app and triggered file selection through its UI instead of preloading paths. This time macOS did prompt for folder access, and once granted, everything worked normally. That told me the issue wasn’t “needs full disk forever,” it was “first access path matters.”
Somewhere in the middle of this, I bookmarked this page because it lined up nicely with how macOS treats third-party tools and file access on newer releases, and it helped confirm I wasn’t chasing a phantom bug:
. Not groundbreaking, just reassuring when you’re second-guessing yourself at 11 PM.
For completeness, I also checked whether there was a Mac App Store version of the app, mostly out of curiosity. If you ever need to do that, the safest option is the official search rather than guessing a direct listing:
The App Store build (when available) tends to handle permission prompts more gracefully because it’s forced to play by sandbox rules from the start. The standalone build gives you more flexibility, but also more ways to trip over macOS security.
What I’d do differently next time
If I were starting from scratch, knowing what I know now, I’d save myself a lot of noise with a short mental checklist:
If an app can’t “see” files but doesn’t error, check Privacy & Security before blaming the app.
Don’t expect macOS to prompt automatically — sometimes it just refuses quietly.
Trigger file access through native dialogs first; it helps the OS register intent.
Once permissions were sorted, the tool behaved exactly as expected. No performance issues, no random freezes, no weird edge cases. It was never unstable — it was just boxed out by the OS.
So yeah, that was my evening. Not dramatic, not heroic, but a good reminder that modern macOS security is polite to a fault. When something looks broken but feels calm, it’s often because the system already decided “no” and didn’t feel like explaining why.