Thank you, Quinn. Your explanation resolves my startup-race question. I understand that launchd's cleanup depends on the worker remaining in the job's process group. To clarify the XPC question: I meant terminating the worker/service, not having it terminate the application. My existing controller normally performs worker termination. If that controller becomes wholly unresponsive, it cannot do so; there is no independent watchdog in my current design. I therefore distinguish controller death from controller hang and am prioritising the launchd-managed controller route. The qualification worker I am evaluating is fixed-purpose, sandboxed, and does not need to create descendants. My target remains macOS 15.6 on Apple silicon. Four remaining platform points would help me avoid choosing an unsupported arrangement: Completion after controller loss What supported observation can I use in a later verification step to establish that the worker from a particular job execution has exited, including when the controller died before recording its identity? Is there a public completion interface, with particular privilege or registration requirements, or only the documented group-cleanup assurance? I would not treat PID/PGID disappearance or parsing launchctl print as proof. A living but hung controller I understand that launchd has no general hard wall-clock runtime limit. Does macOS 15.6 offer an OS-managed liveness or lease mechanism that can initiate termination when an ordinary job stops participating, without another application-created watchdog? I mean initiating termination, not guaranteeing completion within a deadline. Enforced confinement on macOS 15.6 Following your group-escape warning, is there a supported unprivileged restriction that prevents this worker from changing its inherited process group/session or creating descendants, without Endpoint Security or custom sandbox profiles? I distinguish that from merely reviewing my code to ensure it does not perform those operations. Non-GUI launch context Your login answer addressed a conventional GUI application. As a prospective alternative, could a genuinely non-GUI, signed App Sandbox worker run under a dedicated Standard account before its first GUI login? If supported, which launchd domain/session and sandbox-container initialization prerequisites apply? A reference to the applicable public interface, or confirmation that a particular facility is unavailable, would be sufficient. I understand that filesystem effects and cleanup verification would remain my responsibility. Thank you.

Thank you, Quinn. I reviewed the relevant XPC, launchd and process-lifecycle discussions, including your answers and Kevin's recent replies. I understand that embedded XPC covers application death during service startup, launchd performs reaping, and operation replay prevention belongs in the application protocol. We're comparing embedded XPC with running an existing controller under launchd. Our deployment target is macOS 15.6 on Apple silicon. Three remaining questions would help us choose the appropriate supported architecture: If a controller runs as a launchd job with AbandonProcessGroup=false, does job-death cleanup cover a worker created while the controller dies inside posix_spawn, before the call returns, assuming the worker remains in the same process group and creates no descendants? For embedded XPC, what supported mechanism or design would you recommend for termination control and independently attributable completion evidence if the containing application remains alive but unresponsive? We distinguish connection interruption, process exit, reaping and filesystem cleanup, and are not seeking hard-real-time guarantees during kernel failure. We are also considering running the application and its service under the same dedicated Standard account, instead of switching users during launch. On macOS 15.6, what supported login/bootstrap context should that arrangement use? Is prior interactive login necessary? Our aim is to avoid PID-only recovery and treating timeout or connection loss as proof of termination. Thanks again for your guidance.

Hi Quinn, Thanks — by “command sandbox” I meant the restricted execution context we were using for the diagnostic command, specifically a sandbox-exec-based profile around the command runner. I did not mean the Apple App Sandbox, nor a Virtualization.framework-specific sandbox. The distinction we observed was: with the diagnostic executed under the enforced sandbox-exec profile, the relevant host-side operation was blocked; we also saw /bin/ps fail to execute in that context; when the equivalent host-only diagnostic was run directly on the host, outside that sandbox-exec restriction, it succeeded. So “outside the command sandbox” was shorthand on my part for “outside the sandbox-exec profile applied to our diagnostic command”. To be clear, we have not established that this sandbox behaviour is the cause of the VZMacOSInstaller provisioning process failing to complete. At this point it is simply an environmental difference we observed while trying to isolate the issue. I’m happy to provide the exact sandbox-exec profile, command and resulting output if that would be useful.