Scriba captures audio from your Mac. macOS does not hand that capability to every app by default — Transparency, Consent, and Control (TCC) gates access to the microphone and to screen content. Two permissions matter for Scriba: Microphone and Screen Recording. Understanding them saves the "why is my recording silent?" support thread.
Microphone permission
Every recording starts with mic input. Scriba uses cpal to open the default or selected input device. Before audio flows, TCC must grant Microphone access. The app ships NSMicrophoneUsageDescription in Info.plist explaining why — recording your voice in meetings. Release builds also carry the com.apple.security.device.audio-input entitlement in Entitlements.plist. Without it, Hardened Runtime blocks the mic before TCC even prompts, and Scriba never appears under System Settings → Privacy & Security → Microphone.
- checkMicrophonePermission — read current TCC state before record.
- requestMicrophonePermission — trigger the system prompt on first capture.
- Denial surfaces inline in MeetingView with a link to System Settings.
- Device errors (unplugged mic, exclusive access) are separate from TCC denial.
Screen Recording permission
Mic-only captures your side of the conversation. To record remote participants on a Zoom or Teams call, Scriba needs system audio. On macOS 13+ we use ScreenCaptureKit, which routes through the Screen Recording privacy bucket — the same permission used for screen capture. Granting it does not mean Scriba uploads your display; it means the OS allows audio (and optionally display) taps the API exposes. We ask when you enable system audio capture, with copy that ties permission to hearing the other side of the call.
Screen Recording is a macOS quirk, not a surveillance feature. Scriba does not join your meeting as a bot — it records what your Mac plays and what your mic hears, locally, into your SQLite database.
When restart is required
TCC caches decisions per app bundle. Toggle Screen Recording off and on in System Settings sometimes requires quitting and relaunching Scriba before ScreenCaptureKit sees the new grant — we surface that in onboarding and settings rather than failing silently. Microphone changes are usually live, but OS bugs and Bluetooth handoffs can still leave capture in a bad state; restarting the app is the honest fix.
What we don't ask for upfront
Accessibility is used for global shortcuts, not for recording. Camera is not part of the pipeline. Scriba requests permissions in context — mic when you record, screen when you enable system audio — instead of spraying prompts on first launch. Local-first means denied permissions degrade gracefully: you still own whatever you already captured, and export still works. The permissions exist so the next meeting records completely, not so we can hold your archive hostage on a server.