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.

Thank you so much for the elaborate and helpful reply. I will try to address each point, to try and see how to "close in" on my problem. I will also attach a sample crash-report. My "rule engine" is very fast, based on NSPredicates over ObjC custom classes (No core-data etc.). Rule evaluation is completely internal to my daemon, no API calls and no external calls. There IS , however a stage prior to rule evaluation, where I Parse ES messages into my custom ObjC class, and in that stage there are few API calls one of which has given me grief in the past. I need to decide whether a file-system object (from the ES message) is a "Document", in my own semantics. A document is any "normal file", or -- "package" directories. If the file-system object exists and is a directory, and it has a file-name extension, I use something like: _isDocument = [[NSWorkspace sharedWorkspace] isFilePackageAtPath:_filePath ]; If it is non-existing (to be created etc.) Then I use this heuristics and API: { // non-existing directory object about to be created... NSArray<UTType *> *types = [UTType typesWithTag:_filenameExtension tagClass:UTTagClassFilenameExtension conformingToType:UTTypePackage]; switch (types.count) { case 0: _isDocument = NO; break; // no package type with this filename extension known to LaunchServices. case 1: _isDocument = ! [[types firstObject].identifier hasPrefix:@"dyn."]; break; default:_isDocument = YES; break; } Both APIs boil down to LaunchServices calls, that MAY be extenal, and which notoriously "hang" for long periods sometimes. However - these things almost NEVER happen to my ES daemon in normal use (no such crash-reports from 100K+ deployments) but around Mac sleep cycles, this DOES happen. I DO NOT currently employ an active mechanism to "short-circuit" my evaluation of events. What I have instead is: Lots of "white-listing" (large list of "muted" binaries and processes for ES. Events I never receive. If I receive an event with <50 milliseconds deadline, I "give up" and authorize immediately. I subscribe to small set (8) of file-system events, that usually come with 30-60 sec deadlines. mostly open/create. Never read/write. Of course I see much smaller deadlines, but I NEVER saw in my logs a "give up" because of tight deadline. My rules-engine has been tested with at least million events per sec, and it is indeed very fast. ITProtector-2026-02-18-172637.ips.txt ITProtector-2026-02-18-093300.ips.txt ITProtector-2026-02-21-055538.ips.txt I will be happy to share with you parts of my code, but I cannot post publicly - this is corporate proprietary. Please let me know any private e-mail or other method I can send you relevant parts. Thank you so much!