I’m reviewing a hypothetical macOS worker controlled through Endpoint Security authorization events. The design uses synthetic fixtures only; no Endpoint Security client has been created for this candidate. The worker’s prohibited operations must be denied before access occurs and remain denied throughout its lifetime. The documentation for es_set_deadline_miss_mode describes missed authorization deadlines and queue overflow. I need clarification on the separate case where the authorization client disappears. For both es_new_client and es_new_descendants_client: What verdict applies to an outstanding AUTH request if the client crashes, disconnects or is deleted before responding? What governs subsequent operations after the last matching client disappears or unsubscribes? Does ES_DEADLINE_MISS_MODE_FAIL_CLOSED cover any of those situations, or only missed deadlines and queue overflow? Is there a supported mechanism that preserves the required denials for an already-running worker throughout client loss and recovery? Which guarantees differ between the two client types or across released macOS versions? Please distinguish pending requests from later requests. A watchdog that eventually terminates the worker would not establish denial during the intervening period. I’m seeking a public, versioned contract or clarification of the specific limitation requiring another independent enforcement mechanism. Relevant references: Deadline miss policy Client deletion Descendant-scoped client No real credentials, backups or customer data are involved. This request does not seek entitlement grants, permission changes or access to private APIs.

I’m reviewing a macOS metadata collector using synthetic fixtures only. Before implementing a replacement, I need clarification on supported startup behaviour. The intended boundary permits bounded metadata queries on explicitly approved objects while independently denying directory enumeration, file-content reads, writes and network access. These restrictions must apply during native runtime startup as well as collection. In existing synthetic testing, a native metadata helper and a minimal control both failed before reaching their entry markers under restrictive sandbox profiles. The recorded termination description was: failed to open root directory: /: 1 The exact open flags and calling frame were not established. Is there a supported public launch or runtime mechanism that permits the necessary startup operation while independently denying root-directory enumeration and prohibited file access? Specifically: Can this be achieved without initializing the helper outside the required boundary or granting broader root-directory read access? Which public APIs, runtime contracts and released macOS versions support it? What entitlements or permission changes, if any, would be prerequisites? How could the guarantee be verified using synthetic fixtures without enumerating the real root or reading protected contents? I’m seeking a documented mechanism or clarification of the specific unsupported requirement. Successful startup alone, source-level avoidance of directory listing, and private loader interfaces would not establish the required boundary. This is a documentation and architecture question. No real credentials, backups or customer data are involved. Any capability changes would require separate review.