System audio capture is the mechanism behind recording a meeting without a bot in it: instead of listening to a room through a microphone, it reads the audio the Mac is already playing — a call, a lecture stream, a webinar — directly, as its own track. This covers what that actually involves, one time, before the first recording.
Why macOS blocks this by default
Reading what a Mac is currently outputting is treated as sensitive by design, the same category of permission covering anything that reads what's on screen. That's a deliberate choice on Apple's part, not an obstacle a developer works around — any app doing this has to ask explicitly, and the person using the Mac has to approve it before it works even once.
- 00:12:03YouCan you send the slides after this?
- 00:12:08PresenterSure, I'll drop them in the follow-up email.
Step 1 — start a recording that includes system audio
Open Coii AudioNotes and start a recording as usual. The first time system audio is part of that recording, macOS interrupts with its own permission prompt rather than the app silently failing to capture anything.
Step 2 — approve the one-time system prompt
Approving that prompt is the entire setup. There's no account to create, no key to enter, and no separate driver to download first — the next recording, and every one after it, starts without the interruption showing up again.
Step 3 — if it was denied, turn it on manually
A permission dismissed once doesn't ask again automatically. It can be granted afterward in System Settings → Privacy & Security → Screen Recording, where the app appears in the list once it's been opened at least once; toggling it on there and relaunching the app finishes the setup the same way approving the original prompt would have.
No separate hardware or driver involved
Some approaches to capturing a computer's own audio depend on routing sound through a separate virtual driver or an external interface before anything can record it. That's not what's happening here — once the Screen Recording permission above is granted, the capture happens natively, with nothing extra to install and nothing to configure beyond that one toggle.
What actually counts as "system audio"
It's whatever the Mac is outputting at the moment of recording — the other side of a call, a video playing in a browser tab, a webinar streaming audio, all of it. That also means anything else making sound at the same time, a notification chime or background music, becomes part of the same recording, since the capture doesn't distinguish between sources the way a human listener would. Quitting anything that isn't the meeting before an important recording is the practical fix for that.
Headphones don't change anything
Because the capture reads the audio stream itself rather than sound travelling through the air and back into a microphone, it works the same regardless of which output device is in use — built-in speakers, headphones, AirPods, an external interface. Nothing about wearing headphones during a call makes the other side of the conversation harder to capture; the two approaches solve the problem differently, and only one of them depends on what's physically audible in the room.
Beyond meetings — anything the Mac plays
The same mechanism applies to anything else a Mac plays audio for, not only video calls. A lecture streamed through a browser, a recorded webinar, a webinar's own Q&A audio — all of it is system audio the same way a call is, which is why the best apps for recording a lecture rely on the identical underlying capability rather than something built specifically for meetings.
What happens to the audio once it's captured
System audio capture on its own is just the recording step. From there, transcription runs on the Mac itself, segment by segment, while the recording continues — nothing about the audio needs to be sent anywhere else once the permission above has done its job. How to transcribe a meeting without uploading it covers that next step in full.
Recording both sides at once
System audio and the microphone are captured as two separate tracks rather than mixed into one file — the room's own audio on one track, the call's own audio on the other. That separation is what makes it possible to tell speakers apart afterward using a voice print built from each track, rather than trying to untangle two people's voices from a single merged recording. The fuller walkthrough for recording a meeting end to end covers where this step sits inside the whole process.
When the permission needs granting again
Occasionally a macOS update resets a previously granted permission, which shows up as a recording missing its system audio track despite having worked the day before. The fix is the same as the initial setup: check System Settings → Privacy & Security → Screen Recording, confirm the app is still listed and enabled, and toggle it back on if it isn't. This is uncommon enough not to expect it every update, but common enough to be the first thing worth checking if a recording ever comes back one track short.
Why this differs from just hitting record on a microphone
Apple's own Voice Memos, and plenty of other simple recorders, only ever capture what a microphone physically hears — which means the other side of a call comes through faintly, if at all, mixed in with room noise rather than captured cleanly as its own signal. Coii AudioNotes against Voice Memos covers that gap directly; system audio capture is the specific feature that closes it, by reading the call's audio at the source rather than listening for it secondhand through a microphone.
Why this is different from a microphone picking up a speaker
Before system audio capture existed as an option, the workaround for recording a call's other side was to point a microphone at the Mac's own speakers and record the room, hoping the call's audio came through loud enough over whatever else was happening nearby. That approach captures a degraded, secondhand copy of the audio, mixed with room noise, echo and anything else audible at the same time. Reading the audio stream directly, the way system audio capture does, sidesteps that entirely: the signal being recorded is the same one the Mac is already producing internally, not a lossy re-recording of it bouncing off a wall first.
What the permission prompt actually looks like
The first time it appears, the prompt names the app requesting access and explains, in Apple's own wording, that it wants to record the screen and system audio — the same permission category covers both, since capturing what's playing and capturing what's displayed rely on the same underlying system capability. Approving it doesn't grant anything beyond that one category; it doesn't hand over camera access, microphone access separately, or anything unrelated to audio and screen content.
Restarting the app after granting the permission
Occasionally a permission granted through System Settings rather than through the original in-app prompt doesn't take effect until the app is quit and reopened — macOS sometimes only re-checks a permission's status when an app launches, not while it's already running. If toggling the Screen Recording permission on doesn't seem to fix a recording missing its system audio track, quitting and relaunching the app before trying again is worth doing before assuming something else is wrong.
System audio capture and screen sharing are not the same thing
The permission category they share sometimes causes the two to get confused. Capturing system audio doesn't record or transmit anything visual — no windows, no desktop, nothing on screen — even though macOS groups the underlying permission together with the one that governs screen recording software. What's being kept here is exclusively the audio stream; nothing about what's visible on the display is read, stored or sent anywhere as part of this.
Recording a webinar you're only watching, not hosting
The same capability works identically whether the audio being captured belongs to a call being actively participated in or a webinar being watched passively in a browser tab. There's no distinction in how the capture works between "a call I'm speaking in" and "a stream I'm only listening to" — both are simply audio the Mac is outputting at the time, and both get captured and transcribed the same way once recording starts.
A recording with two silent tracks isn't a system audio problem
If neither the microphone nor the system audio track has anything on it, the cause usually isn't the Screen Recording permission at all — it's more likely that recording was started before anyone had actually joined the call, or that the meeting itself hadn't produced any audio yet at the moment recording began. Checking that the call is actually connected and producing sound before assuming a permissions issue saves a round of unnecessary troubleshooting.
Testing that it's actually working before a call that matters
Rather than discovering a missing system audio track after an important call has already ended, a short test recording — playing any audio through the Mac for thirty seconds and checking both tracks came through — confirms the permission is genuinely working. That's a cheap way to catch a permission that was silently revoked by a macOS update before it costs an actual meeting's audio.
Switching output devices mid-recording
Moving from built-in speakers to headphones, or connecting a different output device partway through a call, doesn't interrupt system audio capture — it keeps reading whatever the Mac is currently outputting rather than being tied to a single device chosen at the start. What can interrupt it is switching to an output the Mac doesn't consider part of its own audio output at all, which is uncommon enough in an ordinary meeting not to be a practical concern for most recordings.
A recording made across two rooms, one call
A hybrid meeting — some people in a conference room, others dialling in individually — still only needs system audio capture running on whichever Mac is actually hosting or joining the call as a participant. Everyone calling in remotely on their own device is, from that Mac's perspective, simply more audio coming through the call, captured the same way a single remote participant would be.
Why this permission exists even for trusted apps
It's worth being clear that Apple's Screen Recording permission isn't a judgment about any particular app's trustworthiness — every app capturing system audio goes through the identical prompt, without exception, because the capability itself is treated as sensitive rather than any specific developer being treated with suspicion. There's no way to skip the prompt by being a more established or more trusted piece of software; the permission model applies uniformly.
Confirming the permission is still active
Beyond a test recording, the permission's current status is always visible directly in System Settings → Privacy & Security → Screen Recording, listed alongside every other app that has ever requested it. Checking that list before a recording that matters, rather than after it's already missing a track, is the more reliable habit of the two.
Why the setup stays a one-time step
Nothing about this permission needs revisiting per meeting, per platform, or per week — once granted, it stays in effect across every recording until a macOS update resets it or it's turned off deliberately. That's worth knowing up front: the small amount of friction in the first recording is genuinely a one-time cost, not a recurring one baked into every call going forward, which is part of why the setup described above fits in a single short list of steps rather than a routine to repeat.
What it costs, what it runs on
System audio capture is part of Coii AudioNotes at no separate cost — $19 once, covering three of your own Macs, with a 30-day trial needing no card and no account. It runs on macOS 13 Ventura or later, on Apple Silicon or Intel, and the permission covered above is the only setup step involved anywhere in this workflow. What the app is built to do more broadly covers everything system audio capture feeds into once the recording itself is done.