I have created and submitted a new request: FB16069295 with mostly the same definitions of my question here. Since I haven't been able to resolve the issue since then, it became even more important. Actual users (tens of thousands of them currently need to Allow/deny the Local-Network access for my App.

I also created and submitted an enhancement request: FB16070313 to be able to reset the TCC entry for "Local Network Access". I now see that all my submissions from the last 5 years have been completely neglected, so I don't have high hope here - nevertheless. The Eskimo recommends? I submit.

I'm trying, I'm trying, but it's really hard to do in my case. I'll explain.. This tiny menu-bar status-item app serves only as a "mouth" for a product comprised of about a dozen system-level daemons (sigh, a security tool) including EndpointSecurity client, many daemons that can't inform the user because they're not connected to any user-session or UI session etc. I found the hard way that Notification-Center is hardly usable from a "Global-Agent" or even "User Agent" which is not a "Bundle" but a unix-style binary -- so everyone speaks to the user via this tiny app via XPC - and the app converts stuff to "UI" (both in a small normal AppKit window, and via Notification-Center user-notifications. Because of this - its "function" is hardly controllable from within - it just reacts to XPC calls, and turning off stuff or digging for the "timing" of the issue is very hard to do. Our other daemons look for this app to launch - and then start chirping along on the XPC, sending it "progress" reports, summary of action reports messages the user and so on, so the timing between launch (and XPC Listener resume) to the time the dialog pops -- is clattered with many unsequenced XPC calls from different processes.

(Blushing) what does 'DO' stand for? And what architectural recommendation would you give for making XPC client / service implementation be a bit more "flexible" and not fail with exceptions and crashes just because a client did not implement the whole @protocol ? I found out the hard way - (and not without your kind help) along the last 3 years that NSXPC is implemented in quite limited way, and not everything you expect from Obj-C messaging works as expected -- only one "reply block" "reply block" must be last argument. "reply block can only be called once not any class can participate in the @protocol supported by an NSXPCInterface, and you must manually add classes you need. Now this... "respondsToSelector:" drops the XPC connection when something isn't implemented etc. I wish at the very least the NSXPCConnection documentation would cover these limitations as requirements, so I wouldn't have to apply "normal MacOS thinking" again and again, just to reach the end of implementation and stumble on the limitations like this. It is both frustrating, and pushes into bad design. I would design very differently had I known these things BEFORE I started implementing.

I'm struggling with the very same issue and I think this SHOULD be possible, because many MacOS APIs you use (e.g. Notification-Center notification requests) are dealt out to the notification-center daemon via XPC, so obviously it happens. In my case, my external "another" app outside the sandbox is publishing an XPC service in the user's domain, and my calls to establish the connection finally fail because default 15:21:24.427058 [0x14a846f00] activating connection: mach=true listener=false peer=false name=com.mycompany.myapp.browser.monitor default 15:21:24.427459 [0x14a846f00] failed to do a bootstrap look-up: xpc_error=[159: Unknown error: 159] Have you been able to overcome this obstacle?

Personally, I never dared breaking the ES AUTH event's deadline, because people scared me that Apple counts your failures and will revoke your ES "capability" certificate if you exceed certain limit. My two cents -- Whenever my ES client was terminated for "not answering in time" -- it ALWAYS happened after 5-7 seconds, I think - regardless of the actual deadlines of the many events I receive and handle. This stretch of time reminds me of something different with similar behavior -- When you install a daemon publishing an XPC service (place a .plist definition file in /Library/LaunchDaemons/com.mycompany.mydaemon.plist), then if your daemon fails to launch and initialize itself and be ready to receive XPC calls -- it's being kicked/terminated by launchd, after about the same 5-7 seconds. But maybe that's my imagination...

For one thing, though, I need clarification. the "path literal" that I mute. Is it, or is it not, the path of the EXECUTABLE. My need is simple: I do not want to receive any event for specific executables (OS processes I know to be benign and whose events I do not want to evaluate and authorize). Isn't there an API to do that? must I receive some event from them and then dynamically mute the process?

The edge cases and qualifiers you provide here are very far from my needs. Most executables I want to mute are well protected by SIP, and will never move (MacOS private frameworks, daemons etc. plus few third-party that are also very well defined). My issue is very blunt. I mute a simple and perfect executable path. Here are some - my list is much longer, but you'll get the idea: +(NSSet<NSString *> *) baseBinaryPathWhitelist { static NSSet *_baseBinaryPath = nil; // any executable in these specific paths will be ignored static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ _baseBinaryPath = [NSSet setWithArray: @[ NSProcessInfo.processInfo.arguments[0], // don't inspect our own ITProtector process. @"/sbin/launchd", @"/bin/launchctl", @"/bin/ps", @"/bin/sleep", @"/usr/bin/dscl", @"/usr/bin/log", @"/usr/bin/vmmap", @"/usr/sbin/syslogd", @"/usr/sbin/spindump", @"/usr/sbin/usernoted", @"/usr/sbin/securityd", @"/usr/sbin/ipconfig", @"/usr/libexec/biomesyncd", @"/usr/libexec/logd"]; But when I use the newer API (that you say is identical to the old, or rather that the 'old' API translates to the newer) Then I get lots of ES events from, for example @"/usr/sbin/ipconfig" Although I know for a fact that it was muted upfront, and that calling the muting API returned successfully. The strangest thing is, if I revert to the deprecated API - and that is ALL that I do, just change a single line of code -- then these events are NOT received anymore. Same array, same executables, no other change. I don't know how to extract a simple C project to demonstrate the issue, because my code is big and quite complicated, but I will make an attempt to provide such sample.

That should be it. Thank you. But I urge you to re-read the "canonical" documentation in the headers. The difference you point here (between PATH_TYPE_TARGET_LITERAL and PATH_TYPE_LITERAL is not written there. The very simple distinction between "the path of the executable creating the event" and "the path of the file which is the target of the event" -- is simply not there. I understand now that these paths can sometimes coincide, but I think the documentation lacks proper explanation for the "use case" of these 4 different path "styles". Thank you - I will test with the newer API with the (hopefully correct) path style, and see that indeed events are muted.