Hello, I'm investigating the supported macOS mechanisms for supervising a single unprivileged, sandboxed worker process. The target environment is macOS 15.6 (24G84), Apple Silicon (arm64). The worker is intended to operate under a separate Standard user identity, with tightly restricted capabilities and no requirement to create child processes. The main challenge is the startup failure window: A controller initiates worker creation, but exits unexpectedly before spawn returns or before the worker's identity and authenticated handshake can be independently recorded. In this situation, we need a supported approach to prevent the worker from becoming an unaccounted-for process, or to recover sufficiently trustworthy custody to determine its lifecycle and cleanup state. I have reviewed direct child-process supervision, POSIX process groups, launchd job behaviour, sandbox inheritance, resource limits and process identification mechanisms. I would appreciate guidance on the following: Is there a public, supported macOS API or system service that provides recoverable process custody from initial worker creation, including controller failure during startup? Could an application-associated XPC service or launchd mechanism provide the required lifecycle relationship without granting the worker independent ongoing execution authority? Is generation-safe, audit-token-based process signaling available through a supported public interface, and what are its privilege and acquisition requirements? Is setting a hard RLIMIT_NPROC limit before worker operations a supported way to prevent further fork/spawn activity by an unprivileged worker? What limitations or exceptions should be considered? What can macOS guarantee about process termination and cleanup after controller failure, and what must remain application-level verification? I'm particularly interested in documented guarantees and supported APIs rather than behaviour observed only in tests or private interfaces. Any recommendations or references to Apple documentation would be greatly appreciated. Thank you.

Environment: Apple silicon host, macOS 15.6 (24G84). An arm64 command-line launcher is ad hoc signed; strict signature verification passes and its only entitlement is com.apple.security.virtualization. An Apple macOS 15.6 restore image reported a supported hardware model. The VM configuration validated with 4 vCPUs, 8 GiB RAM, a fresh macOS auxiliary store, a 64 GiB writable raw disk, and a separate read-only raw disk. No guest networking, directory sharing, or socket device was configured. One observed sequence: Load the restore image, select its supported hardware model, create the auxiliary store and disk, validate the VM configuration, then call VZMacOSInstaller.install(completionHandler:). The Apple installation service starts; its logs reach RestoreOS and show a signing-server response. The host logs also record the service's sandbox denial and repeated CSSM permission errors: Sandbox: com.apple.Virtualization.Install deny(1) network-outbound /private/var/run/systemkeychaincheck.socket Can not connect to /var/run/systemkeychaincheck.socket: Operation not permitted CSSM Exception: 100001 UNIX[Operation not permitted] RestoreOS mode device connected AMAuthInstallRequestSendSyncWithHeader: received tss response The guest disk gained GPT/APFS volumes and roughly 17.6 GB of data. After about 11 minutes without a completion callback, the operator stopped the launcher. Exit status 130 reflects that interruption, not a result from VZMacOSInstaller. This launcher did not observe VZMacOSInstaller.progress. No VM retry has been performed since the incident. The socket and its host launchd service were present; a host-only connection succeeded outside the command sandbox. The denial was recorded against Apple's installation XPC service, and restore activity continued after it. Restore-image support, initial VM configuration/attachment construction, and launcher signature verification succeeded. A later restore or storage problem has not been ruled out. XPC sandbox socket denial is proven; cause of provisioning non-completion remains unproven. There is no terminal installer result from this attempt. Questions for anyone familiar with this installation path: Can denial of the installation service's connection to /var/run/systemkeychaincheck.socket prevent VZMacOSInstaller from completing? Are repeated CSSM Exception: 100001 UNIX[Operation not permitted] messages expected or incidental here, or can they be fatal? Without a completion callback before manual interruption, which supported progress signals or diagnostics distinguish slow valid progress, a stall, and a failure that did not surface through the callback? Is an ad hoc signed arm64 launcher with only com.apple.security.virtualization sufficient when Virtualization APIs initialize and the configuration validates? Is there any documented additional requirement for signing identity, entitlement, hardened runtime, installation-service access, host security, restore-image compatibility, auxiliary storage, or VM hardware configuration in this path? I am seeking interpretation of this one interrupted attempt, not asserting a framework defect or a cause for the non-completion.