System audio recording permission on Mac: what it allows
The permission authorizes access to outgoing audio. It does not tell you which processes an app taps, whether it saves audio, or whether a meeting audience can hear it.
The direct answer: grant system audio recording permission only when the product's requested audio job makes sense. For TeenySound, the current source uses the permission to tap selected processes, change their volume in a real-time callback, and play the result to an output device. The audio path has no file writer or network request.
Permission alone proves none of that product behavior. A useful review has four separate states: macOS authorization, the processes the app selects, whether audio is stored or transmitted, and what reaches the physical or remote listener. Check each state instead of treating an enabled toggle as a complete privacy answer.
What macOS authorizes, and what it does not
| Question | What the permission tells you | What still needs evidence |
|---|---|---|
| Can the app access outgoing system audio? | Yes, when the toggle is allowed. | Which processes, devices, and moments it taps. |
| Can it see the screen? | Not necessarily. Apple can allow screen and audio or audio only in the same settings area. | The exact access shown for that app. |
| Can it use the microphone? | Not through this permission. Microphone access is a separate privacy control. | Whether the app separately requests microphone access. |
| Does it save or upload audio? | The toggle does not answer this. | Product policy, source behavior, and network or file-writing paths. |
| Will people in a call hear the audio? | No guarantee. Meeting transmission is a separate app-level state. | The meeting app's share-sound control and a remote listener test. |
Apple's current Privacy and Security guide says the Screen & System Audio Recording area can allow an app to record both screen and audio or audio only. Apple also requires NSAudioCaptureUsageDescription when a Mac app requests system audio capture.
Why per-app volume needs access to outgoing audio
macOS exposes one output level but no built-in mixer with separate sliders for every active app. A utility that changes one process without changing another must work with that process's outgoing stream.
Apple's Core Audio tap API can capture the output of a process or group of processes. Apple's sample connects a tap to an aggregate device and requires macOS 14.2 or later. The system asks for audio recording permission the first time an aggregate device containing a tap starts recording.
That API explains why a mixer needs the capability. It does not excuse a vague product explanation. A trustworthy mixer should identify its process scope, data handling, failure behavior, and permission recovery path.
TeenySound's source-verified data path
TeenySound creates a Core Audio tap for a selected process and output-device pair, connects it through an aggregate device, and handles the stream in an IOProc callback. That callback copies audio buffers to the output while applying a smoothed 0 to 100 percent volume value. Mute sets the target level to zero. The path contains no audio-file encoder, file write, or audio upload.
What does persist is control state: app bundle identifiers, saved volumes, mute state, selected output routes, and per-device volume choices. Network code exists elsewhere for license validation and update checks. The current audio engine does not pass audio buffers to those requests.
The app's Info.plist explains that access is needed to control individual-app volume. Its homepage also says audio is not written to disk or transmitted. The public privacy policy describes local settings and license data, but it does not explicitly document transient audio-buffer handling. Review that written-policy gap separately from what the current source implements.
The permission helper has an implementation caveat
The current TeenySound helper checks and requests the narrower audio-capture TCC service through private TCC framework symbols. If those symbols are unavailable or return an unexpected value, the source treats permission as unknown instead of assuming access. It then guides the user to System Settings.
That fail-closed behavior is safer than silently claiming authorization, but private framework symbols can change between macOS releases. An unknown banner can therefore mean the helper could not determine state, not necessarily that the user denied access. The article cannot promise that future macOS versions will keep the same pane name or private status path.
Run a positive and negative acceptance test
- Before granting access, open TeenySound. The mixer should show a permission recovery message rather than presenting working per-app controls.
- Grant audio-only access in System Settings, then play harmless audio in two apps, such as Music and a browser.
- Move one app's slider. That app should change while the second app remains at its prior level.
- Mute the selected app, restore it, and confirm the sound still reaches the expected physical output.
- Turn TeenySound's access off, return to the app, and let it refresh. The current source marks taps unauthorized and destroys existing tap resources.
- Re-enable access and repeat the two-source test. If the state stays unknown or the mixer remains empty, reopen the app and use its System Settings recovery link.
Use non-sensitive audio for this test. It proves per-app scope and revocation behavior. It does not prove a meeting audience's audio, because a call app can transmit its own microphone and shared sound independently.
Approve or deny from product fit
Approval can fit a per-app mixer, output router, screen recorder, streamer, or transcription tool when system audio is central to the requested feature. Still check whether it stores files, sends audio to a service, or keeps processing after the visible job ends.
Deny access when the capability does not match the product or the explanation is vague. For TeenySound, denial means per-app volume and routing cannot work. System output volume remains a separate macOS control.
For meeting preparation, use the Mac meeting privacy checklist. It treats macOS authorization, the selected share, meeting-app sound sharing, and remote proof as separate states. For the day's companion privacy surface, see clipboard manager privacy on Mac.
Sources checked
- TeenySound claims were checked against the TeenySound homepage, its privacy policy, and local Swift source for permission state, tap creation, IOProc processing, revocation, persisted settings, and network boundaries.
- Apple Developer Documentation: Capturing system audio with Core Audio taps.
- Apple Developer Documentation: NSAudioCaptureUsageDescription.
- Apple Support: Allow apps to use screen and audio recording.
Per-app volume without a virtual audio driver.
teenysound gives each audio app its own volume slider, mute control, and output route. Native Mac app, $9.99 once, 3-day trial.