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 observeVZMacOSInstaller.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.socketpreventVZMacOSInstallerfrom 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.virtualizationsufficient 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.
specifically a sandbox-exec-based profile around the command runner
Yeah, I thought that might be the case.
We don’t support custom sandboxes like this, for the reasons I described here.
The nature of doing unsupported stuff is that you might encounter hard-to-explain problems. Sadly, that’s just how it is. You can continue down that path and try to work out what went wrong by yourself, but my advice is that you change your approach.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"