Thanks mdolan! Looks like online documentation doesn't have all the details, I will get the beta and refer to the headers.

Thanks, I have created a bug FB8722387.

As informed by Security Engineer, not seeing the error from mute process on 10.15.6 (even with Simulator and lots of other processes running).

Thanks for all the details. I will try out the mute by path and as you suggested will measure the impact in different volume conditions.

Thanks for the information. This is helpful. I will check on 10.15.6 (haven't upgraded yet). This implies muting a process during process exec is not enough as mute may fail and I would still see open calls from such processes. So filtering and muting from open auth callback is also required. Does es_mute_path_literal also have such limits? WWDC session "Build an Endpoint Security app" said not to use too many paths in es_mute_path_literal. So is it a bad idea to use it if I am muting most processes from which I see open auth events? What I mean is if mute by audit token fails then I anyway keep on receiving open auth events I filter those based on process path and respond allow Would it be better to use es_mute_path_literal in such cases?

Thanks for the reply. Return value from IOConnectCallStructMethod on error is 0xE00002BC which also I suppose is generic error. I think it maps to following in xnu code but I could be wrong #define kIOReturnError iokit_common_err(0x2bc) // general error Could not see any relevant logs (for kernel process or otherwise) in Console even with Debug and Info enabled. There are not many logs from endpointsecurityd as well. Can you suggest any specific process, log that I can look for?

It is always 1 (ES_RETURN_ERROR). These are the only two possible values documented for es_return_t, return type of es_mute_process function.

Return value from the function is not ES_RETURN_SUCCESS. I tried filtering console logs by endpointsecurityd. There are no additional logs when mute fails. I can reproduce this as follows. I have to leave it running and keep on launching processes. e.g. I launch Simulator (launch Safari inside it) from Xcode which seems to launch a lot of processes. //subscribed to only ES_EVENT_TYPE_AUTH_OPEN  es_new_client(&amp;client, ^(es_client_t *, const es_message_t * message) { es_message_t *msg = es_copy_message(message); dispatch_async(dispatch_get_main_queue(), ^{ uint32_t fflags = 0xffffffff; es_respond_flags_result(client, msg, fflags, true); es_return_t res = es_mute_process(client, &amp;msg->process->audit_token); if (res != ES_RETURN_SUCCESS) std::cout << "mute failed " << res << std::endl; es_free_message(msg); }); With following I was not able to reproduce the issue but the issue is intermittent so can't say for sure that it doesn't. In a simple program I tried listing all processes and muted all (close to 400). There I don't see the error. Ran this periodically at 1 sec interval, still no error. Most processes for which I see error (some listed below) seem to be short lived. So I also tried a simple program where in open callback check if process is, say, Safari copy its audit token from message kill the process in async dispatch block wait for 2 sec then mute the process Even this succeeds. Some of the processes for which I see mute failure, there are many more /bin/bash /usr/bin/su /usr/bin/security /usr/bin/dscl /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/libexec/nsurlstoraged /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/TCC.framework/tccd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/Security.framework/CircleJoinRequested/CircleJoinRequested

Looking for the same. While end use experience is important, allowing administrators finer control to protect company data via user enrolled MDM sounds like a good tradeoff. If timeout is there to protect against buggy applications which may never respond, would it make sense to ask app to check-in proactively before deadline to extend it on a per request basis. In this case timeout can be made shorter than a minute. Typically out of all the file system activity, we are interested in only a limited number of operations out of which only a few might take more than 1 minute. However, in those situations they might take considerably more than a minute. Asking users to retry also doesn't have a good user experience in cases like bulk copy where some operations would succeed and others user would have to track (or we list those user) and retry.

Thanks eskimo for quick response.On macOS 10.15, I tested with a dmg file formatted using exfat. The result is same as that for APFS.