app was installed from homebrew but in quarantine (mic record doesn't work)

[BrodeOne]

fix:sudo xattr -cr /Applications/MeetingTranscriber.app
Im noob, so delete if this is known "feature"

[pasrom]

Thanks for the report, and no need to apologize.

I dug into it:

• The shipped build (both the meeting-transcriber and @beta casks) is Developer-ID signed, notarized by Apple, and the notarization ticket is stapled to the app itself (spctl -a -t exec reports "Notarized Developer ID" and stapler validate passes). So signing/notarization is correct.
• Homebrew does leave the com.apple.quarantine attribute on the installed app. I reproduced that on a fresh brew install --cask, so that part matches what you saw.
• But on current macOS a freshly installed, still-quarantined copy launches and runs from its real /Applications/MeetingTranscriber.app path (no App Translocation), and Gatekeeper accepts it. So quarantine by itself does not relocate or block the app, and I could not reproduce the microphone failing from quarantine alone.

Your xattr -cr workaround is harmless, so no problem using it. To find the real cause, could you share:

• your macOS version
• brew list --cask --versions meeting-transcriber (or meeting-transcriber@beta)
• whether this was a first-time install or an upgrade
• whether MeetingTranscriber appeared under System Settings > Privacy & Security > Microphone (and was toggled on) when recording failed
• did recording fail silently, or was the app blocked from launching?

That will tell me whether this is a TCC-permission edge case worth handling in the app or the cask.

[BrodeOne]

• macOS version: Version 26.6 Beta (25G5057c) (current public beta)
• install via: brew list --cask --versions meeting-transcriber
• It was first install
• MeetingTranscriber was indeed added to microphone under security, i follow turn on/off, try to change inputs in the app. the app look (no red on icon or inside the settings) but as soon as i try to start record, the microphone usage icon just blicked, and error msg appaer
• so i will call it silent block, app saw setting correctly but mic wasent rly possible to use

For testing I want use deepseek, I have some trouble there, but change to beta version (in app) of MeetingTranscriber fix that.

[pasrom]

Quick update after digging in further.

I reproduced your exact setup in a clean VM: a fresh brew install --cask meeting-transcriber (so the app carries the same com.apple.quarantine attribute Homebrew leaves on it) on stable macOS 26.5. There, granting Microphone and starting a recording works fine, no silent block. So on current stable macOS the quarantined install records normally, and the build itself is correctly signed, notarized and stapled.

The one thing that differs on your side is that you're on macOS 26.6 beta. That is almost certainly the cause: a macOS beta gating actual microphone use on the quarantine attribute (even while TCC shows the app as allowed) would explain exactly what you saw, and why xattr -cr fixes it.

So for now:

• sudo xattr -cr /Applications/MeetingTranscriber.app is a fine workaround.
• I'd expect this to go away on the macOS 26 stable release. If you can retest there, or if it persists on a later 26.6 beta, let me know and I'll dig further, including whether the app should detect the "granted but capture blocked" state and surface the xattr hint itself.

Thanks for the detailed report, it was genuinely helpful.

[pasrom]

v0.6.0 stable is out today and is worth a retest here. The root cause of what you saw is still not pinned down, so I am not claiming a fix, but two things changed: the release is notarized and stapled as before, and the bundle identifier changed, so macOS requests the microphone permission fresh instead of reusing the entry from your earlier install. Could you install it with brew install --cask meeting-transcriber and start a recording without running the xattr command first? Please report your exact macOS build and whether the mic works or blocks again; if it blocks, the output of xattr -l /Applications/MeetingTranscriber.app plus whether the app shows as toggled on under System Settings, Privacy & Security, Microphone would settle whether this is the beta-specific quarantine behavior suspected above.