Field Report / Troubleshooting Log
I sat down with a pretty mundane goal: take a folder full of MKV files and batch-fix a few container flags before archiving them. Nothing fancy, no re-encoding, just clean metadata. For that, I grabbed Matroska Batch (app) — a small OrchardKit-style utility that does one thing and, in theory, does it quietly in the background.
That was the theory.
What actually happened was this: I launched the app on macOS Ventura 13.6 (Intel MacBook Pro), the window appeared, menus worked, but the moment I tried to add files… nothing. Drag-and-drop didn’t work. “Open Folder” showed the picker, but after selecting a directory the app behaved like I’d canceled. No error dialog, no warning, no crash. Just polite silence.
At first I assumed user error. Maybe it only accepts files, not folders. Tried individual MKV files. Same result. The UI reacted, but the processing queue stayed empty. Strike one.
Second attempt was the classic tech ritual: quit, relaunch, reboot macOS. Zero change. The app was stable, just strangely uninterested in my files. At this point I was suspicious because tools that deal with media containers almost always touch the filesystem more deeply than Finder expects.
Third attempt was checking Console.app. That’s where the tone shifted. Buried between unrelated system noise was a short, unhelpful line along the lines of “operation not permitted.” No stack trace. No hint which operation. Just enough to tell me this wasn’t a parsing bug — it was macOS saying “no” somewhere low-level.
That’s when permissions entered the picture.
macOS has become very particular about file access, especially for apps that aren’t from the App Store or that use older frameworks. Even if an app looks like it can browse files, it may be sandboxed into uselessness unless the right permission prompt fires. And the key detail: those prompts don’t always appear unless the app requests access in a very specific way.
Apple documents this behavior, though you kind of have to read between the lines:
https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-mchld5a35146/mac
My next move was deliberately low-tech. Instead of using the app’s “Open” dialog, I dragged an MKV file directly from Finder into the app window. That finally triggered a system prompt asking whether the tool could access files in my Documents folder. I allowed it.
Instant difference.
The file appeared in the list. Processing started. No errors. Same binary, same session — just one permission gate that hadn’t been opened before.
I repeated the test with a full directory. This time, macOS showed a broader access dialog, and after approving it, batch operations worked exactly as advertised. Metadata changes applied, files saved, no corruption, no performance weirdness. CPU usage stayed reasonable, disk I/O looked normal.
For reference, Apple’s developer-side explanation of why these prompts are so strict (and so easy to miss) is here:
https://developer.apple.com/documentation/security/protecting_user_privacy
One dead end I should mention: I briefly suspected Gatekeeper or notarization. Checked the quarantine flag, verified the signature, even skimmed Apple’s Gatekeeper docs:
https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac
That wasn’t the issue. The app launched fine. It just couldn’t see anything.
There’s also no App Store listing in this case, so all permission handling falls on how the app requests access at runtime. That’s a very OrchardKit kind of tradeoff: lightweight, functional tools that assume the user understands macOS security boundaries.
While double-checking whether this behavior was expected, I bookmarked this page because it lined up with the exact macOS quirks I was seeing and confirmed I wasn’t dealing with a broken build:
https://proguntalk.com/video/20056-matroska-batch.html
Once permissions were sorted, the tool was boring in the best way. It did the batch job, respected file timestamps, and didn’t surprise me. Performance was fine even on larger folders, and memory usage stayed flat.
If I were doing this again from scratch, knowing what I know now, I’d skip the guessing and do this immediately: launch the app once, drag a file in from Finder to force the permission dialog, then proceed normally. No reinstalling. No rebooting. No assuming the app is broken just because it’s quiet.
Lesson logged: on modern macOS, when a utility “does nothing,” it’s often doing exactly what it’s allowed to do — which may be almost nothing at all.