So we tested the above with the latest beta and ran into the following: Current behavior on Beta 5: Legacy MDM PPPC profiles are accepted but ignored, and manual granting in System Settings no longer works. Declarative Schema problems: We looked into switching to DDM (com.apple.configuration.app.settings), but the schema explicitly states it is AppKit-only and requires a launch-time consent prompt. Since our product is a UI-less background agent (no AppKit UI, no user launch moment for a prompt to display), how is Declarative Device Management intended to grant Accessibility permissions to background services/daemons? Is there a different declaration type planned for non-AppKit agents, or is maybe the behavior on beta 5 a defect? Long story short, we could not make it work.

Oh, thanks for the heads-up! We have not yet tried that. I passed your hint to our QA team, they are going to give it a try. I'll report back as soon as I can. Thanks!

Hi Quinn and everyone following this, Following up as promised. Our QA team just finished retesting against macOS 27.0 beta 5 (build 26A5406e). The end result hasn't changed (silent Accessibility grants via PPPC profiles still don't work), but the OS behavior subtly shifted in a way that's actually trickier for IT admins. In earlier betas, the Accessibility entry was stripped out of the profile entirely. In beta 5, the profile payload installs cleanly and looks completely valid in the UI, only that it’s just silently ignored by the OS when applying TCC rules. What we're seeing: Checking live applied overrides via: sudo plutil -p /Library/Application Support/com.apple.TCC/MDMOverrides.plist shows that other permissions from the same PPPC profile (like Full Disk Access / kTCCServiceSystemPolicyAllFiles) apply as expected. However, kTCCServiceAccessibility is silently omitted from MDMOverrides.plist. Our helper process logs confirm it immediately. The helper process is not trusted by the Accessibility framework. This creates a silent failure mode for admins. An MDM audit will show the PPPC profile as complete and active on the endpoint, even though the OS is silently discarding the Accessibility payload behind the scenes. I really hope someone from the relevant engineering team is reading this, as the situation is now actually worse.

Hi Quinn, Thanks for the quick response as always—really appreciate your insights here. We haven't tested against macOS 27.0b5 yet, so I've asked our QA team to roll it into our nightly test environments. It'll probably take a day or two to get solid results (fingers crossed!), but I'll make sure to follow up here as soon as we have data.

Hey everyone, Just wanted to chime in and say our team is hitting the exact same wall with macOS 27. We build an enterprise observability agent deployed via MDM, and the only reason we touch Accessibility APIs is to read the active foreground window title for session analytics. Everything else in our agent works fine without special permissions. The move from silent PPPC payloads to consent-based DDM (com.apple.configuration.app.settings) creates two massive headaches for us: IT loses enforcement: On supervised corporate Macs, admins need to guarantee required telemetry is running. Giving end-users a prompt where they can just click "Not Now" or decline completely undermines fleet-wide compliance. Background daemons have no GUI: Our agent runs as a headless launchd system service, not a user-facing AppKit app. A consent flow designed around interactive application launches leaves background services completely stranded—there's no UI to trigger or catch the prompt. Is there any supported, non-interactive route planned for supervised/ADE devices to grant Accessibility to signed enterprise binaries? And if DDM really is the only path Apple is giving us, how are headless background daemons expected to handle this when there's no UI layer to prompt the user in the first place? We have also logged this feedback via Feedback Assistant: FB24264150

This was indeed my problem in the original code, too. I placed the autoreleasepool above the loop, not within. Coming back to Objective-C after more than ten years I also appreciate the linked article to memory management as a refresher. As always, your answer is spot on. Thank you very much and have a nice day.

Hello Quinn, Thank you for your reply. In the interim, others have contributed, and my questions have largely been addressed. We do not have a specific issue or use case at the moment; rather, we were seeking clarification on the behavior as it was not entirely clear to us. It is crucial for us to understand the intended behavior of TCC. Following your suggestion to wriker, I ran the above test program in LLDB from the command line. Interestingly, the program can open the file successfully if the binary has FDA, despite neither LLDB nor Terminal having FDA.

Ok, I see. So thanks for the feedback. Valuable, as always :-). The bug report is updated, so I'll keep an eye on the issue.

Hi Quinn, Thanks for the quick response. SecCodeSignatureFlags is a good starting point for the problem I need to solve, as it contains kSecCodeSignatureAdhoc. But currently, I need both CS_ADHOC and CS_SIGNED from cs_blobs.h to determine if a processes binary is signed/ad-hoc signed or not signed. I'm getting this information from ES messages, i.e. from the codesigning flags. So it probably is a good idea to extract those two constants from the header as a work-around and keep an eye on the development of this issue. Or would you recommend against this approach?

Ok, thanks. I filed a bug report with the number FB11958895.

On the other hand, doesn't touch use the utimes function internally? Because I do not get events with eslogger when changing the date via touch (as stated in the OP).

Hi Quinn, the code you posted works fine, the output I get is: {"schema_version":1,"mach_time":567075211518,"event_type":59,"thread":{"thread_id":344982},"version":6,"seq_num":0,"event":{"utimes":{"target":{"path":"\/Users\/sasailic\/test.txt","stat":{"st_blocks":8,"st_blksize":4096,"st_rdev":0,"st_dev":16777232,"st_uid":501,"st_gid":20,"st_ino":14704426,"st_birthtimespec":"1991-12-21T20:12:00.000000000Z","st_flags":64,"st_nlink":1,"st_mtimespec":"2023-01-19T12:57:02.679729000Z","st_ctimespec":"2023-01-19T12:57:02.679759924Z","st_size":11,"st_gen":0,"st_mode":33188,"st_atimespec":"2023-01-19T12:57:03.507743494Z"},"path_truncated":false},"atime":"2023-01-19T12:57:32.692218000Z","mtime":"2023-01-19T12:57:32.692218000Z"}},"time":"2023-01-19T12:57:32.692264799Z","action":{"result":{"result":{"auth":0},"result_type":0}},"process":{"signing_id":"utimes_test","parent_audit_token":{"asid":100006,"pidversion":20612,"ruid":501,"euid":501,"rgid":20,"auid":501,"egid":20,"pid":8304},"codesigning_flags":1912680500,"executable":{"path":"\/Users\/sasailic\/Library\/Developer\/Xcode\/DerivedData\/utimes_test-dfdvixksrrdvdeffdzhdryzpkzlu\/Build\/Products\/Debug\/utimes_test","stat":{"st_blocks":152,"st_blksize":4096,"st_rdev":0,"st_dev":16777232,"st_uid":501,"st_gid":20,"st_ino":14780081,"st_birthtimespec":"2023-01-19T12:56:18.414093520Z","st_flags":0,"st_nlink":1,"st_mtimespec":"2023-01-19T12:56:18.582642868Z","st_ctimespec":"2023-01-19T12:56:18.582709826Z","st_size":77808,"st_gen":0,"st_mode":33261,"st_atimespec":"2023-01-19T12:57:32.687173868Z"},"path_truncated":false},"ppid":8304,"tty":null,"start_time":"2023-01-19T12:57:32.303492Z","is_platform_binary":false,"group_id":8303,"audit_token":{"asid":100006,"pidversion":20610,"ruid":501,"euid":501,"rgid":20,"auid":501,"egid":20,"pid":8303},"is_es_client":false,"responsible_audit_token":{"asid":100006,"pidversion":20610,"ruid":501,"euid":501,"rgid":20,"auid":501,"egid":20,"pid":8303},"session_id":6115,"original_ppid":6115,"cdhash":"E5984AF63EBBFCF8EB6546EDEE7A6F50BACE798C","team_id":"64N35HHH3F"},"action_type":1,"global_seq_num":0} And now I understand where the problem is. I misread the documentation at https://developer.apple.com/documentation/endpointsecurity/es_event_type_t/es_event_type_notify_utimes as if I get a notification when a process changes the modification or access time of a file, not when a process does this using the utime function. That was not clear to me, sorry and thanks for taking the time.

Small update. Suspecting that maybe path muting might be responsible, I tried unmuting a test directory and receiving the mentioned event for this directory with the following additional code: es_invert_muting(client, ES_MUTE_INVERSION_TYPE_TARGET_PATH): es_unmute_all_target_paths(client): es_mute_path(client, "/Users/TestUser", ES_MUTE_PATH_TYPE_TARGET_PREFIX): This did not work either. In the meantime, I also found out that I DO get notifications very seldomly for random apps like, e.g. "/System/Library/CoreServices/Applications/Screen Sharing.app/Contents/MacOS/Screen Sharing". My code should not be the problem, as I do get the same notifications as eslogger.