Quinn recommended consolidating my related question into this thread. I have a similar observation on a system reported as macOS Monterey 12.7.6 (21H1320), Intel, with the relevant volume reported as APFS; the filesystem type has not been independently reverified. An existing empty regular file was opened read-only with O_NOFOLLOW and O_CLOEXEC. Before/after pathname and descriptor metadata matched. One acl_get_fd_np(fd, ACL_TYPE_EXTENDED) call returned NULL with ENOENT, captured immediately after clearing errno. This does not independently establish ACL absence. I have not tested fgetattrlist or controlled ACL fixtures on this host, so I am not claiming the additional results described in the original post. Could Apple clarify a supported descriptor-bound sequence for distinguishing absent ACLs, explicit zero-entry ACLs, and unavailable ACL evidence, including whether that guidance applies to Monterey? My related question, for context: https://developer.apple.com/forums/thread/855564 Thank you. I’ll keep further discussion here.

Thanks, Quinn. Could you please share a link to the reply you mean? I’d like to make sure I’m reading the correct discussion.

Hi Quinn, Thanks — that distinction is helpful. There are two separate trust boundaries in our design: The host child process is a trusted executable that we build and sign. It owns a VZVirtualMachine. For this process, our concern is programming errors, hangs, crashes, and reliable cleanup, rather than deliberately malicious host code. The guest runs potentially untrusted, AI-generated code. We intend to contain that code within the VM, with restricted resources and no configured host directory sharing or networking. We are not treating process groups or a watchdog as a security sandbox. The immediate question is about the lifecycle of the VM when its host owner fails or must be terminated. Our normal path is to request a controlled VM stop and collect the owner’s exit status. We also need to handle an unresponsive owner. If that exact owner process is forcibly terminated and its termination is confirmed, what can we rely on regarding the VM’s continued execution and the release of its virtualization resources? In particular, is confirmed owner-process termination sufficient to establish that the guest can no longer execute, or is there another documented lifecycle mechanism or observation we should use? We want to avoid claiming that collecting the host process’s exit status proves VM teardown unless that is a supported guarantee. Thanks for helping us clarify the boundary.

Thanks, Quinn. Yes, that’s exactly the scenario I was asking about. Your recommendation makes the architectural boundary clear: we’ll use the normal guest shutdown / stop() paths during expected operation, and we won’t add a separate crash-detection cleanup mechanism. We’ll rely on Virtualization.framework to clean up the guest if the host terminates unexpectedly. We’ll also add the repeated force-quit test you suggested on our target macOS environment and monitor for any resource or VM-worker leakage. This resolves the question I was trying to answer. Thanks again for taking the time to walk through it so carefully.

Thank you, Quinn. This is very helpful and clears up the distinction I was struggling with between the supported Virtualization.framework lifecycle contract and the implementation details of the helper processes. In particular, your clarification that an unexpectedly terminated Virtualization.framework client should have its VMs cleaned up by the system, and that this is the expected behavior across macOS versions, answers the main question I was trying to resolve. I also understand now that process names, process relationships, and process lifetime are implementation details and therefore aren’t appropriate as an ownership or VM-liveness contract. I have one final architecture-level question, if you don’t mind: Is it reasonable for an application to rely on this client-lifetime → VM-cleanup behavior as part of the supported Virtualization.framework lifecycle contract when designing a bounded VM execution host? In other words, assuming the application still implements its own normal stop/timeout/cleanup paths, can it reasonably treat unexpected client termination as a failure case where macOS is expected to terminate the VM rather than allowing that VM’s execution to continue independently? I’m not asking for guarantees about private helper processes or implementation details — only whether that high-level lifecycle behavior is an appropriate supported assumption for application architecture. Thanks again for taking the time to clarify this.

Thanks for checking. For this specific investigation, I am primarily interested in macOS Monterey 12.7.x on Intel x86_64, rather than treating macOS 12 merely as a minimum deployment target. The reason is that I need to establish a security/lifecycle property for that exact host environment: if the userspace process responsible for a running VZVirtualMachine is abruptly destroyed, I need to know whether the live guest/vCPU execution is necessarily reclaimed and cannot continue independently. Behavior on newer macOS releases would certainly be useful context, especially if the ownership model changed over time, but a guarantee that applies only to newer releases would not establish the property I need for Monterey. So, ideally, I’m looking for the answer specifically for Intel macOS Monterey 12.7.x. If the behavior is the same from Monterey onward, that would of course also be very useful to know.