Hey,
So yesterday I spent way too long poking around with ESLint Configurator (app) from OrchardKit, and I thought I’d tell you what actually happened instead of the polished “it works now” version.
I downloaded the macOS build from their site — it’s not on the Mac App Store, but here’s the official page for reference: https://planetgpa.com/developer/22638-eslint-configurator.html
Moved it to /Applications, double-clicked… and nothing. The Dock icon bounced once and disappeared. No crash dialog, no warning. Just… gone. Classic Gatekeeper silent-block behavior, I realized, but a bit sneakier than usual.
First Attempt: Right-Click Open
My first instinct was the usual: right-click → Open. macOS gave me the standard “this app was downloaded from the internet” prompt. Click Open. Icon bounced. Gone. Again.
At this point, I started suspecting it wasn’t just a Gatekeeper thing. Maybe something inside the bundle was off — an unsigned binary or a missing notarization.
Attempt Two: Quarantine Flags
I opened Terminal and checked extended attributes:
xattr -l /Applications/ESLint\ Configurator.app
Sure enough: com.apple.quarantine. That’s standard for anything downloaded from the web. Removing it sometimes helps, so I ran:
sudo xattr -dr com.apple.quarantine /Applications/ESLint\ Configurator.app
Launched again. Same bounce. Silent death.
Then I remembered that even if the top-level app is cleared, nested binaries inside can still trigger the security check. Apple’s notarization docs explain this clearly: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
Attempt Three: Terminal + File Permissions
Next, I tried launching from Terminal:
open /Applications/ESLint\ Configurator.app
Finally, some console output. It complained about file access — trying to write config files in ~/Documents without proper permissions. Makes sense. macOS silently blocks apps from touching user directories until they’re granted explicit permissions.
I went into System Settings → Privacy & Security → Full Disk Access and added the app. Overkill? Maybe, but effective. Once I did that, it launched properly. Dashboard loaded, settings were editable, and I could save new configurations without a hitch.
During this process, I found this page useful — it had notes on macOS handling of unsigned apps, quarantine flags, and file permissions. Worth bookmarking if you ever tangle with this kind of behavior: https://planetgpa.com/developer/22638-eslint-configurator.html
What Didn’t Work
- Re-downloading the same build — didn’t change anything.
- Only removing quarantine from the top-level bundle — partial, still wouldn’t start.
- Resetting Launch Services — wasted 10 minutes.
Only the combination of recursively clearing quarantine flags, granting file access, and launching via Terminal revealed the actual blockers.
Quick Checklist for Next Time
- Check extended attributes with
xattr -l. - Remove quarantine recursively if needed (
sudo xattr -dr com.apple.quarantine). - Launch via Terminal to catch hidden errors.
- Preemptively grant file system permissions if the app writes to Documents or Downloads.
Had I done that from the start, I would have saved myself an hour of guessing.
Final Thoughts
Once it was running, ESLint Configurator was smooth and responsive. No hangs, no crashes, fully compatible with my M1 Mac running macOS Sonoma. The problem wasn’t the app itself — macOS was enforcing modern security layers that silently block execution if the app isn’t notarized or trying to touch protected directories.
It’s a good reminder: on modern macOS, especially on M1/M2 machines, silent app termination often comes from Gatekeeper + sandbox + file system permissions, not broken software. The Dock bounce-and-vanish is basically macOS saying, “I don’t trust this yet.”
Anyway, now that it’s running, I can finally tweak some ESLint configs alongside OrchardKit workflows without the usual macOS drama. Next time I’ll check quarantine flags first — lesson learned.