**Kubiki (app) on macOS: When a Quiet Utility Works Only After You Fix File Permissions**

I ran into **Kubiki (app)** while cleaning up a Mac that had slowly turned into a graveyard of half-used productivity tools. You know the type: small utilities that promise to make everyday tasks smoother, often built by tiny teams, often perfectly fine—until macOS decides otherwise. I found this one through an OrchardKit-style catalog of Mac software and thought it was worth a quick test. “Quick” turned out to be optimistic. --- ### What I wanted to do The task was mundane. Install the tool, open it, let it work with a couple of local files, and see if it earned a permanent spot on my machine. No cloud sync, no system hacks, no background daemons. Just a local utility doing local things. The test machine was a MacBook Pro with an M1 chip, running macOS Sonoma 14.3. Fairly clean system, no MDM profiles, nothing exotic. Installation went smoothly. Dragged the app into `/Applications`, launched it, window appeared. No Gatekeeper warning, no notarization drama. At that point I was feeling quietly optimistic. --- ### What broke (without saying a word) The optimism lasted until I tried to actually *use* it. Any action that involved opening or saving files simply didn’t work. The UI reacted—buttons pressed, menus opened—but the core functionality might as well have been unplugged. No error dialogs. No “permission denied.” Just silence. That’s the worst kind of failure on macOS: the one where nothing *looks* wrong, but nothing useful happens either. --- ### First attempt: assume the app is buggy My first assumption was the obvious one. Maybe it’s an early build. Maybe something didn’t ship correctly. I quit and relaunched. Same behavior. I rebooted the Mac (because rebooting is the universal confession ritual). Still nothing. I even tried different folders, including a fresh directory on the Desktop, just in case something odd was going on with my home folder. No change. At this point it *felt* like a broken utility. But the consistency of the failure was suspicious. The app wasn’t crashing. It wasn’t hanging. It was being politely ignored by the operating system. --- ### Second attempt: Gatekeeper, the usual suspect Next stop was Gatekeeper. I right-clicked the app, chose **Open**, approved the dialog, launched again. macOS was clearly fine with executing the binary. Apple’s own explanation of this part of the process lives here: [https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac](https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac) Still, file access was dead. That’s when it finally clicked: launching wasn’t the problem. **Permissions** were. --- ### What actually worked macOS doesn’t always ask for file access permission when it should. If an app doesn’t trigger the request at the right moment, the OS defaults to “no” and doesn’t bother explaining itself. So I went straight to **System Settings → Privacy & Security** and started checking manually. Sure enough, the app wasn’t listed under **Files and Folders**. It wasn’t under **Full Disk Access** either. macOS had never prompted me, which meant it had never granted anything. I manually added the app to the Files and Folders section and allowed access to Documents and Desktop. I didn’t restart the Mac. I didn’t even quit the app. I tried the same action again. This time, it worked immediately. Files opened. Changes saved. The tool suddenly behaved like a normal macOS citizen. Apple documents this behavior here, though it understates how quiet the failure mode is: [https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-mchl1a0b6b8f/mac](https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-mchl1a0b6b8f/mac) [https://developer.apple.com/documentation/security/protecting-user-privacy](https://developer.apple.com/documentation/security/protecting-user-privacy) The short version: if the permission dialog never appears, you still lose. --- ### A quick trust check before leaving permissions on Before I committed to leaving file access enabled, I wanted to be sure I wasn’t granting privileges to something sketchy. I bookmarked this page while checking context around the tool, mostly to confirm what it was supposed to do and why it behaved the way it did on macOS systems: [https://planetgpa.com/office-and-productivity/14508-kubiki.html](https://planetgpa.com/office-and-productivity/14508-kubiki.html) That background made the decision feel reasonable instead of impulsive. --- ### After permissions: boring, which is good Once access was granted, the app settled down and did exactly what it claimed to do. CPU usage stayed low. Memory footprint was modest. No background processes hanging around after quitting. I kept Activity Monitor open out of habit; nothing suspicious showed up. That’s usually the best compliment you can give a small utility. I also checked whether there was a Mac App Store version, since sandboxed builds often avoid this entire class of problems. Nothing obvious yet, but Apple’s official search is here if that changes: [https://apps.apple.com/us/search?term=Kubiki](https://apps.apple.com/us/search?term=Kubiki) --- ### How I would do it next time If I were setting this up again on another Mac, I wouldn’t waste time guessing. I’d do it in this order: Install the app. Launch it once. Immediately open **Privacy & Security**. Grant file access manually. Then test functionality. No reinstalls. No reboots. No blaming the developer. --- ### Final note from the field This wasn’t an installation issue, and it wasn’t a broken release. It was macOS enforcing privacy rules in the least communicative way possible. For small OrchardKit-style productivity tools that work entirely with local files, this pattern keeps repeating. If something launches fine but “does nothing,” assume the OS is blocking it quietly. Once you know where to look, the fix takes seconds. Before that, it can burn an hour and your patience along with it.