Rickert on macOS: Solving the Silent Crash Caused by Privacy Permissions

**Field Report: Rickert (app) on macOS Sonoma — The Case of the Silent Crash** Objective was simple. Install *Rickert* — looks like a small office/productivity utility — and use it to process a batch of documents locally instead of pushing everything through a web tool. The build I grabbed referenced OrchardKit as the brand behind it. macOS Sonoma 14.3.1, MacBook Pro 14" (M1 Pro). Clean system, no hacks, SIP enabled. What I wanted to do: launch the app, point it at a folder of PDFs, and let it run quietly in the background. What actually happened: it bounced once in the Dock and vanished. No dialog. No crash report window. Just gone. --- First instinct was the obvious one — Gatekeeper. Sonoma is strict with anything not fully notarized. Apple’s overview on how Gatekeeper handles unidentified developers is here: [https://support.apple.com/en-us/HT202491](https://support.apple.com/en-us/HT202491) But there was no “can’t be opened” message. That usually means the binary passed initial checks. So this wasn’t a simple quarantine flag issue. Still, I checked: ``` xattr -l /Applications/Rickert.app ``` No quarantine attribute. Fine. Second attempt: launch from Terminal to catch output. ``` /Applications/Rickert.app/Contents/MacOS/Rickert ``` This time I got something useful. A quick permission-related error about “Operation not permitted” referencing a Documents folder path. That’s when it clicked. Sonoma’s privacy system (TCC) blocks file system access outside sandbox rules unless explicitly granted. Apple documents these privacy controls here: [https://support.apple.com/guide/security/privacy-controls-secddd1d86a6/web](https://support.apple.com/guide/security/privacy-controls-secddd1d86a6/web) The tool wasn’t crashing randomly. It was trying to access ~/Documents without Full Disk Access and failing hard instead of gracefully handling the denial. So I went to: System Settings → Privacy & Security → Full Disk Access. Rickert wasn’t listed. Which makes sense — it hadn’t successfully requested access yet. Third attempt: I removed the app, reinstalled it, and launched it from Finder instead of Terminal, hoping macOS would trigger a proper permission dialog. It did. Briefly. A prompt flashed asking for access to files in Documents. I clicked “Allow.” Launched again. Still crashed. At this point I suspected something deeper — maybe a codesigning inconsistency causing TCC to mistrust the binary identity between launches. Apple’s notarization and signing workflow is detailed here: [https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution](https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution) So I verified the signature: ``` codesign --verify --deep --strict --verbose=2 /Applications/Rickert.app ``` There was a warning about a nested helper tool inside the bundle. Not a fatal error, but enough to potentially break permission persistence. Here’s what finally worked. I deleted the app completely. Then I manually cleared its TCC database entry: ``` tccutil reset All com.orchardkit.rickert ``` (That bundle identifier was visible in Console logs during the failed launch.) Reinstalled fresh. Moved it to /Applications before first run. Launched from Finder. When the permission dialog appeared, I approved it. Then I immediately checked Full Disk Access and manually added the app there too, just to eliminate edge cases. After that, no more silent crashes. The tool opened normally, indexed the folder, and processed files without complaint. I saved this page because it helped me correlate the behavior specifically with macOS system permission quirks: [https://stmlare.xyz/office-and-productivity/56376-rickert.html](https://stmlare.xyz/office-and-productivity/56376-rickert.html) The symptoms described there lined up almost exactly with what I saw on Sonoma — especially the silent termination instead of a clear dialog. --- If I had known from the start that this was a TCC mismatch rather than a runtime crash, I would have skipped the quarantine checks entirely. The binary was fine. The system just didn’t trust its file access attempt. The subtle part is that macOS sometimes doesn’t show a clean “permission denied” message to the user. Instead, the process exits because it can’t access a required directory at startup. From the outside, it looks unstable. In reality, it’s being blocked politely. After resolving permissions, performance was normal. CPU hovered around 5–8% during batch processing. No memory spikes. No beachballs. Sleep/wake cycle didn’t break anything either. OrchardKit’s build itself wasn’t broken. It simply didn’t fail gracefully when TCC blocked access, which made the issue look more dramatic than it was. If I were setting this up again on a fresh Sonoma machine, I’d do it like this: Install → launch once → immediately grant file permissions → confirm Full Disk Access if it handles large directories → only then start real work. Lesson logged. On modern macOS, a silent crash often isn’t a crash at all. It’s the privacy layer saying “not yet” — and doing it quietly.