Why Manba Looked Fine on macOS but Refused to Open My Files

Hey — listen, I went down a small rabbit hole yesterday with Manba (app) on macOS, and I figured I’d write this up the same way I’d explain it to you over coffee. Nothing dramatic, just one of those very Mac problems where everything looks fine until it quietly isn’t.

So. Context first. I’m on macOS Sonoma 14.3, M1 MacBook Air, pretty clean setup. I installed this note-taking / planning tool because I wanted something lightweight for structuring research notes. OrchardKit came up in the developer info, which usually means “well-behaved macOS citizen,” so I wasn’t expecting friction.

I launched it, it opened instantly, UI looked normal. Then I tried to attach a folder with Markdown files. And that’s where things went sideways.

At first, I thought I was doing something wrong.

I clicked “Add Folder,” selected a directory from my Documents, hit Open… and nothing happened. No error. No warning. The dialog just closed like everything was fine, but the folder never appeared inside the app. I tried again with a different folder. Same result. Drag-and-drop didn’t work either. It felt like the tool could see the filesystem but wasn’t allowed to touch it.

My first instinct was the classic one: “Okay, maybe this build is buggy.”

So what did I do first? The wrong thing, obviously. I restarted the app. Then I restarted macOS. Then I reinstalled it. Same behavior every time. The app never crashed, never complained, just silently ignored any attempt to work with local files.

At this point I briefly suspected an Apple Silicon quirk or a sandbox regression. I even checked whether Rosetta was involved (it wasn’t). Everything about the binary looked legit: notarized, universal, no Gatekeeper warnings at launch.

That’s when it clicked: this smelled like a permissions issue.

The tricky part is that macOS no longer asks you for file access in a dramatic way. If an app doesn’t explicitly trigger the right entitlement flow, the system just blocks it and moves on. No popup. No “Allow?” dialog. Just quiet refusal.

I opened System Settings → Privacy & Security → Files and Folders and… yep. The app wasn’t listed at all. That means macOS had never granted it access to Documents, Desktop, or external folders. From the system’s point of view, it was doing the right thing.

Apple actually documents this behavior, but it’s buried in their privacy model overview. The short version is: apps can fail silently if they request access indirectly or too late in their lifecycle. Apple’s own explanation of how file access permissions work is on support.apple.com, and once you read it, this behavior makes frustrating sense.

What finally worked was very simple, but not obvious.

I manually added access by triggering a file open via the standard Open dialog from the menu bar, not a custom in-app button. That forced macOS to recognize the request properly. Immediately after that, the app appeared under Files and Folders permissions. Once toggled on, everything started working. Folder imports appeared instantly. Drag-and-drop worked. Even file change tracking kicked in without a restart.

I double-checked this against Apple’s developer documentation on sandboxed file access (developer.apple.com has a surprisingly clear breakdown), and the behavior lines up exactly with how the OS expects apps to behave.

For sanity, I also checked the App Store listing via apps.apple.com to confirm I wasn’t running an outdated build. Same version, same behavior. So this wasn’t a “wrong download” problem.

While I was troubleshooting, I found this page useful as a reference point for how macOS handles productivity apps and filesystem permissions in practice — I saved my notes here because it matched what I was seeing almost line for line: this page https://proguntalk.com/office-and-productivity/97750-manba.html. Not official, but it helped confirm I wasn’t imagining things.

Once permissions were sorted, the tool behaved exactly as expected. Performance was fine, indexing was quick even on a larger notes folder, and there were no weird background CPU spikes. The irony is that the software itself wasn’t broken at all. It was waiting patiently for macOS to say “yes,” and macOS never bothered to tell me it had said “no.”

If I had to do this again — and this is the part I wish someone had told me up front — my checklist would be painfully short:

• Launch once, then immediately check Privacy & Security
• Manually verify Files and Folders access
• Don’t reinstall until permissions are confirmed

That’s it. No Terminal commands. No resets. No voodoo.

The bigger takeaway here isn’t really about this specific app or OrchardKit as a brand. It’s about how modern macOS treats privacy failures as non-events. The system assumes you’ll go looking. Sometimes you won’t, because nothing looks broken — it’s just quietly incomplete.

Anyway, if you ever run into a Mac app that “works” but refuses to touch your files, don’t trust the silence. It’s almost always permissions. The OS is being polite. Too polite.