Could you please clarify the supported caller arrangement for this case? A signed app, Example.app, registers a fixed LaunchAgent for user E using SMAppService.agent(plistName:). The plist is in the app's Contents/Library/LaunchAgents directory. A separately launched, same-team-signed helper is already running as ordinary user E in the same user-login/bootstrap context. It is a bare executable at Example.app/Contents/MacOS/StopHelper, without its own nested .app bundle. After the original main-app process exits, this helper reconstructs SMAppService.agent(plistName:) for that plist and calls unregister(completionHandler:). Apple's GUI-less sample already demonstrates a fresh invocation of the owning app's main executable reconstructing and unregistering its service. The agent factory documentation refers to the calling app's plist directory. Does the separate embedded helper in this case resolve to the containing app's original registration, and may it unregister that same user's service? How does ServiceManagement establish the calling-app association, and what documented signing, packaging, execution-context or macOS-version requirements apply? If this helper arrangement is unsupported, could you identify the relevant caller-association restriction and confirm whether the owning main-executable approach demonstrated in Apple's sample remains applicable? This question concerns caller-to-registration association. Process protection, reactivation prevention and complete job-termination verification are separate obligations. No re-registration or arbitrary cross-user control is proposed. Thank you for your guidance.

We are assessing a native macOS worker supervised by an independently protected background service. Our current Mac's system-version file reports macOS 27.0.1 (26A434), and the installed SDK declares es_new_descendants_client for macOS 27. No Endpoint Security client or experimental confinement has been activated. We need a supported public way to stop a job and verify that its controlled execution has ceased, even if workers fork, exec, call setsid/setpgid, are reparented, or their immediate supervisor crashes. Admission must remain closed until reconciliation after a failure. Delegation to outside services must either be denied or have its own enforceable ownership and stop contract. Does Apple provide a public API/configuration that establishes this hereditary ownership and complete termination boundary? In particular, does a descendants ES client's scope retain processes across parent exit/reparenting, and what supported operation can quiesce/terminate that entire owned population without a fork-versus-enumeration race? What remains enforced if that client dies or is deleted? We understand that fail-closed AUTH deadlines and es_sync_client alone do not establish this property. Please identify the supported interface, OS versions, entitlement/privilege requirements, relevant failure semantics and independently observable completion condition, or confirm the limits of this proposed combination. We are asking about the public contract, not private implementation details or a guarantee during kernel failure.