This might work, but I'm not sure it is worth the effort to roll out.  The latest beta of macOS 15.1 included a new key forceBypassScreenCaptureAlert that should address Enterprise management needs around this without resorting to hacky solutions.

Thanks for pointing that out, I totally missed that in the beta 4 notes. By chance did you make note of what domain this was? Apple does not mention the domain on the beta 5 notes, and it's not in the restriction's developer page yet.

I have been testing this for the past 24hrs and it seems to be working :)

and here is the plist:

Didn't seem to work for me on Sequoia 15.1 beta 5.

Could you attach a .mobileconfig file where this works for you?
Thanks

What @MoAlJuboori found is good. However it really does mean an extra item for Jamf to add into PPPC profile section.

In case it helps anyone, I created a helper for this. It also contains an MDM profile to disable these on 15.1

https://github.com/luckman212/screencapture-nag-remover

Try this. I believe it requires a restart once it's deployed.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>forceBypassScreenCaptureAlert</key>

<true/>

</dict>

</plist>

---

@mschlosseratfbooru wrote:

I saw this on a blog this morning, posting here to raise visability.

Much has already been written about the new monthly screen recording prompt in macOS 15 Sequoia. After a bit of research, there is a way to get rid of the prompts; kinda tacky, but does work.

The good news is that there's a way to stop the prompts forever

defaults read ~/Library/Group\\ Containers/group.com.apple.replayd/ScreenCaptureApprovals.plist
This file is protected by TCC, so to access it you'll need to grant Full Disk Access to Terminal app.

{ 
 "/Applications/Shottr.app/Contents/MacOS/Shottr" = "2024-09-21 12:40:36 +0000"; 
}

In the plist file, the keys are the paths of the executable files with screen recording permission, and the values are dates. I'm using the Shottr screenshot tool as an example.

To stop the prompts forever—for the rest of your life, anyway—set the date to far in the future, for example, the year 3024 instead of 2024.

defaults write ~/Library/Group\\ Containers/group.com.apple.replayd/ScreenCaptureApprovals.plist "/Applications/Shottr.app/Contents/MacOS/Shottr" -date "3024-09-21 12:40:36 +0000"

You'll need to do this for each app, and afterward logout and login again so that the replayd process recognizes the new defaults.

Not gonna do this, but good to have the knowledge; we will see if Apple provides something better.

 

---

It’s helpful to know how to manage the screen recording prompts in macOS 15. Let’s hope Apple introduces a more user-friendly solution soon, but until then, this is a solid option.

I've made the json if you prefer to get the drop-down options:

I'm really not sure how to use this.   Is this something I can do one time and apply to all the managed devices?   I thought I would have to do this per app.   Please let me know if I follow the information in the above posts, I can be one and done, or do I need to apply it individually?

I deployed my original Plist via jamf as a config profile to all sequiaOS devices, It has been working so far on 200 devices, and it covers all apps in one go :)

Did you have to sign the profile before uploading to Jamf? I have seen Slack posts that suggest you need to.

No I didn't, it might be required for 15.2 though (just guessing).

Thanks for sharing this info.

Does this profile remove 30-day reoccurring alert spam? Specifically, does it require ANY user approval once installed, or does it require a one-time user approval? Trying to understand what my expectations in testing should be.

Im seeing references to (2) domains associated with this domain on Slack and the web: com.apple.applicationaccess and com.apple.TCC. Any reasons why there appears to be some disagreement on the correct preference domain?

apple.tcc has been working for our fleet since my first reply to this post :) 

it doesn't require any user input as well.

@MoAlJuboori can you explain how you are able to not have the user allow at least once?

The idea is once the device is on 15.1, the key should set that alert to false.   It shouldn't prompt at all.   Not once, not ever.   I confirmed with an Apple engineer who works with my account rep and I showed him the scripts on this page.  That engineer said they looked good.   Right now, it's the best we've got.

I dug around more on Slack and a few members including Tony Young from Apple, Rich Trouton, and Lab5 (Lewis) state that the preference domain should be com.apple.applicationacces.

Im guessing this will be a native Restrictions or TCC/PPPC payload in Jamf Pro 11.11ish?

https://derflounder.wordpress.com/2024/10/31/managing-user-notifications-for-apps-which-request-screen-access-on-macos-sequoia-15-1/

https://github.com/apple/device-management/blob/seed_iOS-18.2_macOS-15.2/mdm/profiles/com.apple.applicationaccess.yaml

I spoke with an Apple Engineer who works with our account manager.  He referred me to this,  Line 3620 - key: forceBypassScreenCaptureAlert  an explanation on 3636. payloadtype: com.apple.applicationaccess

Thanks for bringing this question up.

According to Tony Young on the MacAdmins slack, it's best to use an externally created configuration profile for this due to how Jamf Pro implemented the "Application & Custom Settings" payload. Your custom settings are basically delivered under "mcx_preferenc_settings" which will cause inconsistent results for the "forceBypassScreenCaptureAlert" preference key. More context below.

@bwoods Thanks Brandon. Saw your post on Slack too. Good info - much appreciated.

I have uploaded a .mobileconfig to my JSS which appears to be working (replacing my initial raw XML plist version in a Application & Custom Settings" payload).

Key takeaways here are the domain (com.apple.applicationaccess) the pref key (forceBypassScreenCaptureAlert) and the required boolean value (True)

Adding more context. It looks like using a plist is possible as long as the PayloadContent key is featured. The PayloadContent key seems to ensure that the settings aren't disrupted by "mcx_preference_settings" utilized by the "Application & Custom Settings" payload. So, a profile like the one below should work the same as the externally created profile.

preference domain: com.apple.applicationaccess

I found this blog post but couldn't give it a try for now:
https://derflounder.wordpress.com/2024/10/31/managing-user-notifications-for-apps-which-request-screen-access-on-macos-sequoia-15-1/#more-12443

It seems that Apple has provided a payload for managing screen access in macOS 15.1

While this does seem to work in 15.1, after upgrading to 15.2 seems that the configuration profile within the example above doesn’t suppress screen capture alerts anymore. In addition, viewing the profile on the endpoint Mac itself (via System Settings app) doesn’t display the
‘Suppress Screen Capture Alerts’ key value.

What does seem to work is creating a configuration profile and configuring a ‘Restrictions’ payload via Jamf Pro 11.12 (which supports the new ‘forceBypassScreenCaptureAlert’ key setting) but this payload also includes other default restriction keys which I was not planning on setting.

Any ideas why things stopped working on 15.2?

To the above, once the profile is deployed on 15.1 and MacOS os upgraded afterwards to 15.2, all seems to work fine. But when one deploys the profile AFTER the upgrade to 15.2, it doesn't seem to suppress screen capture alerts.