Hey,
I was tinkering last night with LangCheck (app) on my MacBook Pro (M1 Pro, Sonoma 14.4), and it turned into one of those “this should’ve taken five minutes” sessions. Since you’re also juggling tools inside OrchardKit, I figured I’d share what actually happened so you don’t waste the same hour I did.
So the idea was simple: install this lightweight writing/grammar utility, hook it into a couple of text fields, and see how it behaves across Notes and a browser. It’s in the office/productivity category, so I expected it to request Accessibility permissions for system-wide text access. Totally normal for that type of tool.
Install went fine. Drag to Applications, launch, clean interface. It asked me to enable Accessibility access so it could analyze text in other apps. Standard stuff.
I went to System Settings → Privacy & Security → Accessibility and toggled it on.
Came back to the app.
It still said: “Accessibility access required.”
That’s where things started getting weird.
First thing I did (and this was my mistake) was just toggle it off and on again. Didn’t help. Then I quit and reopened the app. Still not recognized. It behaved as if macOS hadn’t granted anything.
At that point I assumed the permission didn’t stick properly. Apple’s documentation on managing Accessibility and privacy permissions is here: https://support.apple.com/en-us/HT210632
Everything looked correct in the panel. The checkbox was enabled.
So I rebooted. Old habit. After restart, same message.
Now I started suspecting TCC (the Transparency, Consent, and Control system). Sometimes when an app changes its signature between builds or you move it after granting access, macOS treats it as a different binary.
And yes — I had initially launched it from Downloads before moving it into Applications. That matters more than people think.
I removed it from the Accessibility list entirely, then re-added it manually using the “+” button instead of relying on the automatic prompt.
Still didn’t register inside the tool.
That’s when I opened Terminal and checked the extended attributes:
xattr -l /Applications/LangCheck.app
There it was: com.apple.quarantine.
Which means the first time it ran, it was under quarantine state. If the permission request happens during that phase, macOS can behave inconsistently.
Apple’s explanation of Gatekeeper and how it affects first launch is here: https://support.apple.com/en-us/HT202491
So I removed quarantine:
xattr -dr com.apple.quarantine /Applications/LangCheck.app
Then I reset TCC for Accessibility specifically:
tccutil reset Accessibility
Logged out and back in (not a full reboot this time).
Launched it again.
This time macOS displayed the Accessibility prompt properly. I approved it, and immediately the status indicator inside the app switched to “Access granted.”
So the problem wasn’t the feature itself. It was the order of operations: first launch under quarantine, then moving the app, then toggling permissions. That sequence confused TCC.
I found this page useful while I was double-checking how macOS systems handle these privacy flows for productivity software — this page helped confirm that others hit the same pattern: https://sznurkowo.com/office-and-productivity/61246-langcheck.html
It matched what I was seeing: permission technically enabled, but not recognized by the running process.
Out of curiosity, I checked whether there’s a Mac App Store version. Store builds usually avoid this because sandbox entitlements are tightly managed: https://apps.apple.com/us/search?term=LangCheck
I didn’t see a clearly official listing under that exact name, so this is likely a direct-download distribution. Which means the notarization and entitlement handling are fully dependent on the developer’s packaging.
After fixing the permission state, everything behaved normally. It injected suggestions into text fields, CPU usage stayed low, no weird accessibility warnings in Console.
What I understood from this little adventure is that macOS tracks permissions per app identity and path. If you:
- launch from Downloads,
- then move to Applications,
- then grant Accessibility,
the system can treat those as slightly different trust contexts.
It’s subtle. And annoying.
If I were doing it again from scratch, I’d do it this way:
- Move the app to /Applications before first launch.
- Remove quarantine immediately after copying.
- Launch once to trigger permission prompt.
- Grant Accessibility.
- If anything feels stuck, reset TCC instead of toggling checkboxes repeatedly.
That would’ve saved me a solid 40 minutes.
The app itself isn’t unstable. Once permissions are properly aligned, it works exactly as expected. This was purely a macOS privacy model issue — specifically how first-run trust interacts with Accessibility services.
Anyway, just passing this along so you don’t go in circles like I did. Sonoma is stricter than people realize, especially with system-level text tools. It’s not broken — it’s just very particular about who gets to observe other apps.
Talk soon.