Thanks Quinn — that answers the exact question I was trying to pin down. So for this requirement, there isn’t a supported launchd mechanism that both allows the work to survive its initiating controller and gives launchd responsibility for a hard wall-clock lifetime bound. An XPC service ties lifetime back to the initiating process, while a LaunchAgent can outlive it but doesn’t provide the wall-time termination guarantee I was looking for. That’s enough for me to rule out the OS-owned lifetime model I was considering and design around that constraint instead. Really appreciate the clear explanation.

Thanks Quinn — yes, that is close, but the specific concern is slightly narrower. I understand that if the parent exits first, the child can be reparented and may later terminate normally. The question is what supported macOS mechanism, if any, can own and bound the diagnostic’s lifetime independently of the requesting controller. In the focused sample, the controller may exit immediately after launch, before retaining the child PID or establishing output collection. The child may also create a new session, close stdin/stdout/stderr, and continue running. So I’m trying to establish whether a per-user launchd job or another supported OS-managed mechanism can: take responsibility before the diagnostic starts; keep that responsibility if the requesting controller dies; bound or terminate the diagnostic if it exceeds its intended execution window; and provide some supported completion/failure state after the original controller is gone. If ordinary child reparenting is the supported model and macOS does not provide that stronger per-job lifetime/containment guarantee, that would also answer the question. Thanks for helping me narrow it down.