Apple's Core Audio process taps landed in macOS 14.2 and capture system audio without any screen permission at all, which makes the prompt you just saw look wrong.
You installed an audio plugin. It asked for Screen Recording access. Nothing about that pairing makes sense until you know which capture route the developer picked, and why they had a good reason to pick the older one.
Two things can pull sound out of your Mac's output stage. ScreenCaptureKit has done it since macOS 13, and it treats audio as one more track alongside the pixels it was built to grab. Core Audio taps arrived later, in 14.2, and do nothing but audio. Same result, different route, wildly different permission dialog.
Core Audio taps go through a separate lane. The developer declares NSAudioCaptureUsageDescription in the app's Info.plist, and macOS files the approval under its own category instead of lumping it in with screen access. On recent systems, that appears in Privacy and Security as its own entry, so you can hand over your speaker output without handing over your desktop.
The clean route has a version requirement. Taps only exist from 14.2, and most developers target 14.4 or later, because the earlier point releases put approvals in a different bucket and the categories do not line up. Anything below that gets nothing.
So a plugin that still supports macOS 13 has one option, and that is the whole reason the prompt looks odd. A developer aiming at desktop audio capture without a virtual cable has to choose the API that reaches the most machines, and on macOS today that is still the screen one.
Reinstall from a build with a changed certificate and the grant no longer matches. The helper launches, gets refused, and hands your DAW silence with no error worth reading. Same folder, same version number, same icon. Different signature.
Unsigned builds fail earlier and more quietly. A binary without a valid signature will compile and run, but it can never raise the permission dialog in the first place, so nothing ever appears in System Settings for you to tick. If you are testing a local build and the entry simply is not there, that is usually why.
Resetting is the fastest diagnostic. Running tccutil reset ScreenCapture followed by the bundle identifier clears the record for that one process and forces a fresh prompt on next launch. Quit the host first. TCC checks at process start, so a DAW that was already open when you granted access keeps the old answer until you relaunch it.
The current behavior is calmer but still catches people out. A month is long enough that you forget the plugin needs anything, and the dialog tends to surface mid-session rather than at a convenient moment. Later 15.x releases eased the frequency again for apps you keep approving.
Grant it and move on. Denying by reflex is the common failure, and the recovery is not obvious, because the plugin will not ask again for weeks, and its audio lane just sits there empty in the meantime.
What the permission actually gives up is narrower than the wording suggests. Screen Recording access covers window contents and display capture in general, so it is a real grant and not a formality, but a plugin using it for audio never opens a video stream. The scope on paper is wide. The use in practice is one stereo pair coming off your output device.
Check the menu bar indicator if you want to confirm nothing else is happening. macOS lights it whenever screen capture is genuinely active, and an audio-only helper will show as recording the entire time it runs, which is expected rather than evidence that your display is being watched.
You installed an audio plugin. It asked for Screen Recording access. Nothing about that pairing makes sense until you know which capture route the developer picked, and why they had a good reason to pick the older one.
Two things can pull sound out of your Mac's output stage. ScreenCaptureKit has done it since macOS 13, and it treats audio as one more track alongside the pixels it was built to grab. Core Audio taps arrived later, in 14.2, and do nothing but audio. Same result, different route, wildly different permission dialog.
Two capture routes carry two different permissions
ScreenCaptureKit sits behind Screen Recording. The system does not care that you only want the audio track, because the framework is a screen framework, so the permission is the screen permission. You get the full warning language about seeing your display, plus the recording indicator in the menu bar, for a tool that never looks at a single pixel.Core Audio taps go through a separate lane. The developer declares NSAudioCaptureUsageDescription in the app's Info.plist, and macOS files the approval under its own category instead of lumping it in with screen access. On recent systems, that appears in Privacy and Security as its own entry, so you can hand over your speaker output without handing over your desktop.
The clean route has a version requirement. Taps only exist from 14.2, and most developers target 14.4 or later, because the earlier point releases put approvals in a different bucket and the categories do not line up. Anything below that gets nothing.
So a plugin that still supports macOS 13 has one option, and that is the whole reason the prompt looks odd. A developer aiming at desktop audio capture without a virtual cable has to choose the API that reaches the most machines, and on macOS today that is still the screen one.
The approval is tied to the signature, not the app
TCC does not remember "that plugin." It remembers a code-signing identity, and it files your answer against that.Reinstall from a build with a changed certificate and the grant no longer matches. The helper launches, gets refused, and hands your DAW silence with no error worth reading. Same folder, same version number, same icon. Different signature.
Unsigned builds fail earlier and more quietly. A binary without a valid signature will compile and run, but it can never raise the permission dialog in the first place, so nothing ever appears in System Settings for you to tick. If you are testing a local build and the entry simply is not there, that is usually why.
Resetting is the fastest diagnostic. Running tccutil reset ScreenCapture followed by the bundle identifier clears the record for that one process and forces a fresh prompt on next launch. Quit the host first. TCC checks at process start, so a DAW that was already open when you granted access keeps the old answer until you relaunch it.
Sequoia re-asks for screen recording every month
Apple shipped a monthly re-approval prompt in macOS 15, after backing away from something far more aggressive during the beta, where the same dialog surfaced weekly.The current behavior is calmer but still catches people out. A month is long enough that you forget the plugin needs anything, and the dialog tends to surface mid-session rather than at a convenient moment. Later 15.x releases eased the frequency again for apps you keep approving.
Grant it and move on. Denying by reflex is the common failure, and the recovery is not obvious, because the plugin will not ask again for weeks, and its audio lane just sits there empty in the meantime.
What the permission actually gives up is narrower than the wording suggests. Screen Recording access covers window contents and display capture in general, so it is a real grant and not a formality, but a plugin using it for audio never opens a video stream. The scope on paper is wide. The use in practice is one stereo pair coming off your output device.
Check the menu bar indicator if you want to confirm nothing else is happening. macOS lights it whenever screen capture is genuinely active, and an audio-only helper will show as recording the entire time it runs, which is expected rather than evidence that your display is being watched.
