Permissions — Oris handbook

The two macOS prompts on first run, the notification prompt that follows, and the two hardware situations that decide whether Oris can hear the call at all.

The first time you hit record, macOS shows two click-Allow prompts, both labeled Oris: one for Microphone, the obvious one, and one for System Audio Recording, which is what lets Oris capture the other side of a call. macOS treats those as two separate permissions with different risks attached, so there is no single combined grant to click.

Grant them once and they stay granted. Every Oris update keeps the same signed identity, so an update never sends you back through the prompts. If you want them back deliberately, to re-test the flow or to hand the machine on, reset them yourself:

tccutil reset Microphone   com.shariqh.oris.recorder
tccutil reset AudioCapture com.shariqh.oris.recorder

Note the service name for System Audio Recording is AudioCapture, not SystemAudioCapture or kTCCServiceAudioCapture. As of macOS 26.4 that’s the name that works.

The notification prompt

There’s a third prompt, and it isn’t a TCC one: macOS asks separately whether Oris may post notifications. That’s what delivers the “Notes inserted” banner when a recording finishes, along with the auto-stop and summary-failed alerts. Oris only ever asks once, from a dedicated request during the walkthrough (and, for people who never run the walkthrough, at the start of your first recording). Nothing else in the app asks on the side, because macOS grants exactly one prompt and a request fired from the wrong place can burn it without ever showing you anything.

If notifications end up denied, macOS will not present that prompt again. The only way back is System Settings → Notifications → Oris → Allow Notifications. Oris doesn’t let that state hide: the walkthrough’s permission step flags it with a link straight to the pane and a Re-check button, and the app’s General tab carries a permanent Notifications row showing the same thing. Recording, transcription, and summaries all work normally without notifications; you simply don’t get the banner.

When the lid is closed

There’s a macOS quirk worth knowing about if you work with the lid shut. When your Mac’s output is set to its built-in speakers and the lid is closed, system audio can’t be captured at all. You’d still hear the call, because the sound is coming out of your monitor or whatever else you have plugged in, but the recording would carry your voice and nothing else. You wouldn’t find out until the transcript arrived with only one side of the conversation in it.

Oris checks for that combination before a recording starts and refuses to begin, telling you which outputs you could switch to instead. Pick one of them in Control Center → Sound, or open the lid, and start again.

How it works underneath

Audio interfaces, docks, and virtual devices

Most Macs make this question boring. Built-in speakers, AirPods, a Bluetooth headset: macOS presents each of those to Oris as a playback device carrying nothing but playback, even when the hardware has a microphone, because the microphone shows up separately as its own input device. So when Oris captures the audio coming out of your machine there is only one stream to take.

Some hardware is not like that. A USB audio interface (a Focusrite Scarlett, MOTU M2, UA Volt, SSL 2, Audient iD4) is a single device carrying its inputs and its outputs together, and macOS presents it that way. So is a dock or a monitor with a built-in mic and speakers, a class-compliant USB headset, and a virtual audio device used as your output, which is what Loopback, BlackHole, and some conferencing apps install. On those, the audio Oris receives arrives as several streams at once: the device’s own inputs, and the system audio Oris actually wants.

Oris works out which stream is which before recording starts, by asking macOS to describe the streams it is about to receive and comparing that against the device it is recording through. It checks the answer rather than trusting it, and it re-checks whenever the picture can have moved, which is when you change output device mid-recording. If that check is inconclusive it tries a second one based on the channel layout.

What it will not do is guess. On this kind of hardware the stream sitting next to the one Oris wants is usually the device’s own input, which is often your microphone, so a wrong guess would quietly file your own voice as the other side of the conversation. If neither check can identify the meeting audio, Oris records nothing for the system track and tells you rather than filing something that looks right and is not.

What you should see

Nothing different. The “others” track holds the meeting, the “me” track holds your microphone, and the transcript separates them as usual. The point of this page is that the interesting cases already work, not that they need attention.

If you want to confirm it, the recorder’s log (~/.local/state/oris/audio-capture.log) records which stream it chose on the sys topology: line at the start of each recording, and again on the stats: line at the end.

Sample rates above 48 kHz

Oris encodes system audio through macOS’s own AAC encoder, and that encoder accepts sample rates only up to 48 kHz. If your output device runs higher, which happens with hi-res DACs and with the headphone jack when it is configured for 96 kHz in Audio MIDI Setup, the recording is encoded at 48 kHz instead of refusing to start. Your playback device is left exactly as you set it. Nothing that matters is lost: transcription downsamples everything to 16 kHz mono anyway.

When it still goes wrong

If the “others” track comes out empty or holds the wrong audio on an unusual setup, the fastest fix is to switch your output to the built-in speakers or a headset for the meeting. Then send the log along with the make and model of the device, because a device that defeats the checks above is worth fixing properly rather than working around.