IM Account Manager on macOS: Fixing Microphone & Screen Recording Permission Failures

Hey,

I spent part of last night wrestling with IM Account Manager (app) on my M2 MacBook Pro (Sonoma 14.3), and I figured I’d write it up for you while it’s still fresh. You know how I keep most of my test installs organized under OrchardKit so I can reproduce setups cleanly? This one was supposed to be quick — install, connect accounts, done.

Instead, it turned into a classic macOS permissions story.

The issue wasn’t that it wouldn’t launch. It launched fine. The problem was that it refused to access the microphone and screen recording, which is kind of the whole point for a communication/account management client that integrates with messaging and video tools. Inside the app, I’d enable voice features, and it would just say “Microphone unavailable.” No system prompt. No crash. Just dead silence.

First thing I did — and this was the wrong move — was assume it was a bug in the build. I reinstalled it. Dragged it out of Applications, deleted leftovers in ~/Library/Application Support, re-downloaded, tried again. Same behavior. No permission prompts from macOS.

Then I checked System Settings → Privacy & Security → Microphone and Screen Recording.

The app wasn’t even listed.

That’s when I realized this wasn’t about toggles. macOS never registered the request in the first place.

Apple’s privacy system (TCC) only shows apps in those panels after they attempt to request access properly. If the request doesn’t fire — or if the binary identity changes between launches — macOS won’t even display it. Apple explains the general privacy permissions model here:
https://support.apple.com/en-us/HT210638

So I tried the obvious trick: launch the app from Terminal instead of Finder. Sometimes that surfaces entitlement errors more clearly.

/Applications/IM\ Account\ Manager.app/Contents/MacOS/IM\ Account\ Manager

Immediately saw this in the output: a sandbox denial tied to “com.apple.security.device.microphone.”

That told me the app either wasn’t signed correctly with the proper entitlements, or macOS was blocking it at a deeper level.

At that point, I checked for quarantine flags (I’ve been burned by this before):

xattr -l /Applications/IM\ Account\ Manager.app

Sure enough, com.apple.quarantine was there.

Now here’s where I made my second mistake. I removed the quarantine flag right away:

xattr -dr com.apple.quarantine /Applications/IM\ Account\ Manager.app

Relaunched. Still no microphone access. No prompts.

That’s when it clicked: if the first launch happened under quarantine and macOS denied or failed to register the permission request, TCC might have cached that state. So even after removing quarantine, the system wasn’t reconsidering it.

Apple documents how Gatekeeper and notarization affect first launch behavior here:
https://support.apple.com/en-us/HT202491

And the developer-side explanation of hardened runtime and entitlements is here:
https://developer.apple.com/documentation/security/hardened_runtime

So I reset TCC for the app specifically:

tccutil reset Microphone com.imaccountmanager.app
tccutil reset ScreenCapture com.imaccountmanager.app

(Found the exact bundle identifier with mdls.)

Then I rebooted. Probably overkill, but I wanted to clear any lingering state.

After restart, I launched it again — this time normally from Applications. Immediately, macOS prompted:

“IM Account Manager would like to access the microphone.”

Allowed.

Then it requested screen recording.

Allowed that too.

Everything worked instantly after that. Voice input was recognized, screen-sharing preview appeared, no more “device unavailable” messages.

I found this page useful while I was checking macOS security handling and confirming that others had seen similar behavior with this build:
https://rvfcb.com/communication/99273-im-account-manager.html

It helped me confirm that the issue wasn’t specific to my hardware or Apple Silicon — it was mostly about how the app interacted with macOS privacy on first run.

Out of curiosity, I checked whether there’s a Mac App Store version (sandboxed apps distributed there usually handle entitlements more cleanly):
https://apps.apple.com/us/search?term=IM%20Account%20Manager

Didn’t see an obvious official listing under that exact name, so direct download it is — which means notarization and entitlement configuration are fully dependent on the developer’s release process.

What I learned (again) is that macOS doesn’t “retry” permission requests automatically if the first attempt happens in a weird trust state. If the app launches under quarantine and fails to properly request access, you can get stuck in a silent denial loop.

Here’s the short checklist I’d follow next time:

• Check for quarantine attribute before troubleshooting features.
• Reset TCC for the specific service (Microphone, ScreenCapture, etc.).
• Relaunch after reboot to force fresh permission prompts.
• Only then start blaming the app.

Once I did that, performance was normal. No CPU spikes. No weird background permission errors in Console. It behaves like any standard communication client now.

So yeah — nothing dramatic. Just macOS being strict about privacy (as it should be). The app itself wasn’t broken; the first-run security handshake just failed, and the system never retried it on its own.

If you end up deploying it on your machine or one of the OrchardKit test environments, I’d clear quarantine and reset TCC right away. Saves a lot of head-scratching.

Talk soon.