screen recording permission on a mac

screen recording permission on a mac is a single toggle hiding a surprising amount of machinery, and that machinery is why the toggle sometimes lies to you.

apple tightened this deliberately. the permission is not a preference, it is an entry in a protected database keyed to the exact copy of the app you granted, and almost every confusing symptom comes from that one design decision.

here is what macos actually grants, why it keeps forgetting, and how to fix it, current as of macos 26 in september 2026.

what the permission actually covers

the screen recording grant is broader than most people assume and narrower than they fear.

the important line is the second column's row 2. seeing pixels and controlling the interface are separate grants, and conflating them is the most common misunderstanding in this area. a screen recorder needs to see. an agent that operates apps for you needs accessibility permission, which is a far broader thing to hand over, covered in computer use agents on a mac.

how to grant it

granting macos screen recording permission takes 4 steps, and the last one is the one people skip.

1. open system settings, then privacy and security.
2. choose screen and system audio recording.
3. turn on the toggle next to the app.
4. quit the app completely and reopen it.

step 4 is not optional. macos reads the permission when the process starts, so an app that was running while you granted it will keep behaving as though it has nothing. apple's own guide to controlling screen recording access says the same thing, and it is still the single most common reason a correctly granted app captures a black rectangle.

why the toggle lies

the permission is keyed to a specific binary, not to a name, and this causes most of the trouble.

macos stores privacy grants in tcc, which stands for transparency, consent and control. the tcc database on macos is a pair of sqlite files, one system level and one per user, protected by system integrity protection so nothing can edit them directly. each record ties a grant to an app's bundle identifier and code signature.

so the record does not mean "remynd may record the screen". it means "this exact signed copy at this path may record the screen". three things break that link:

1. a second copy of the app. one in applications and one still in downloads are different paths. you granted one and launched the other.
2. an updated or re signed build. a development build signed with a different certificate is a different app as far as tcc is concerned.
3. moving the app after granting. the path changed, and the grant may not follow.

the symptom is identical in all 3 cases: the toggle in system settings is on, the app behaves as though it is off, and toggling it makes no difference. that is screen recording permission not working in its most common form, and it is not a bug.

why does the permission stop working?

work through these 6 fixes in sequence and stop when it starts working. steps 1 to 3 resolve well over 90% of cases.

1. quit and reopen the app. solves the majority of cases, costs 10 seconds.
2. check you have exactly one copy. search for the app by name and delete stray copies from downloads, the desktop and old build folders.
3. toggle the permission off, then on, then relaunch. this rewrites the record rather than reading a stale one.
4. reset the permission entirely. tccutil reset ScreenCapture clears it for every app, or tccutil reset ScreenCapture com.example.app for one. the app prompts again on next launch.
5. reboot. genuinely helps here, because some permission state is cached per session.
6. check for a mobile device management profile. on a managed work mac, an mdm profile can deny the grant regardless of what the toggle shows.

step 4 is the one worth learning, because to reset screen recording permission properly you have to clear the record rather than flip the switch. step 6 catches the case where nothing you do locally will ever work.

what a well behaved recorder does with it

the grant is broad, so what the app chooses to do inside it is the part that matters.

apple's screencapturekit, introduced in 2022, lets an app capture a single window rather than the whole display, and filter out specific applications. screencapturekit replaced the older apis precisely so that capturing 1 window did not require asking for all of them. an app that asks for the whole screen when it needs one window is making a choice, not following a constraint.

three questions worth asking of anything you grant this to:

• does it capture the focused window or every pixel of every display? the difference is large for both privacy and battery, measured in does screen recording slow down your mac.
• can you exclude specific apps and sites? a banking app or a health portal should never enter the archive at all.
• where do the frames go? local disk and a vendor's servers are very different answers to the same permission prompt.

microsoft arrived at similar conclusions the hard way with recall, pausing it in june 2024 after the privacy reception and spending roughly 2 years rebuilding it with on device encryption and biometric gating. windows now requires a neural processing unit rated at 40+ trillion operations per second before recall will run at all.

the permission model is the easy part. what you do behind it is the product.

what the grant actually produces

granting screen recording permission on a mac starts a process that writes to your disk continuously, and it is worth knowing the rate before you agree to it.

we measured a real install across 17 days of capture. it held 26gb. video accounted for roughly 24.6gb, about 95% of the total, and the searchable ocr index for 1.4gb, about 5%. that is roughly 1.5gb per recorded day.

extrapolated, a year of index runs around 20gb and a year of the video it came from runs around 360gb, about 18x more for the part you almost never replay. this is why the retention setting matters more than the permission dialog: the grant decides what an app may see, and retention decides how long any of it survives. the full working is in screen recording storage on a mac.

does the grant cover the lock screen?

there are real boundaries on this grant, and they are worth knowing.

a mac will not capture while the screen is locked or during the login window, so an archive has a natural gap of 100% whenever you step away. screen recording also does not imply microphone access, which is a separate prompt, or file access, which is another. and it says nothing about the network: an app with screen recording permission and no network entitlement cannot send anything anywhere.

that separation is the useful mental model. macos grants capabilities one at a time, and the interesting question about any app is which combination it holds. an app with screen recording plus accessibility plus network is a categorically different proposition from one with screen recording alone.

why people grant it at all

it is a broad permission, so it is worth being clear about what you get back for it.

per the anthropic economic index for may 2026, searching electronic sources is the single most common work task in sampled claude conversations at 4.95%, with reference searching second at 3.74%.

searching your own material is 3.61% and anything about a meeting is 0.26%, while work makes up 43.36% of classified conversations and 51.38% of all usage is augmentation rather than automation. those low numbers are a supply problem: almost nobody has an index of their own week to search. the screen recording grant is the thing that makes one possible, which is why it is worth understanding rather than clicking through.

where remynd sits

remynd asks for screen recording permission and uses it to capture the focused window rather than every pixel of every display.

the scope, stated exactly: focused window capture, ocr running locally on device through apple's vision framework, storage on your machine, recordings default to 30 days of retention, app and site exclusions so you can keep whole categories out of the archive entirely, and history that is read only everywhere in the app. call transcription runs on device using an mlx speech model on apple silicon, which needs the separate microphone grant.

what it does not do: asking a question sends the retrieved slices to a cloud model, so this is not a claim that nothing ever leaves the machine.

if the permission is granted and you are still seeing nothing, work down the fix list above, starting with quitting the app properly. if you want the category rather than the permission, start with screen memory, and if you want to know what the capture is worth, read how to find something you saw on your screen.