01What they are & why
Each macOS VM is a per-session, isolated Mac running on Apple's Virtualization framework — a real, disposable macOS instance where xcodebuild, the simulators (xcrun simctl), and codesign run end-to-end without ever touching your host.
They exist to remove shared-host toolchain thrash. Two agents building on the same host collide and corrupt each other's derived-data build output — one clobbers the other's intermediate files mid-compile, and both builds fail in confusing ways. When each agent gets its own isolated Mac, concurrent builds never collide: every session compiles, simulates, and signs in its own clean environment.
This is exposed to agents as the mac_vm_exec tool — the per-agent alternative to the shared-host host_exec. Where host_exec runs commands directly on your Mac (shared by every session), mac_vm_exec runs them inside that session's own VM.
02Requirements
Before you turn this on, make sure the machine can carry it:
- Apple silicon Mac. Running macOS guests requires Apple silicon — Intel Macs can't host a macOS VM.
- Plenty of RAM. It's heavy: expect several GB of RAM per running VM, on top of a one-time base-image install.
- Free disk space. The golden base image, its downloaded restore image, and each per-session VM disk add up fast.
- macOS 27 or later on host and guest. macOS 27 is the supported host and guest version for macOS VMs.
03Turning it on
-
Enable the service
In Settings ▸ Virtual Machines, turn on Enable macOS VM service.
-
Optionally expose it to sessions
Turn on Expose to sandboxed sessions by default so sessions get the
mac_vm_exectool automatically, without opting in per session. -
Build the one-time base image
Before any VM can boot, you must build the golden base image once — this installs macOS and provisions the dev toolchain. See Building the base image for the full walkthrough.
04How a per-session VM works
The first time a session calls mac_vm_exec, Nucleic spins up a VM just for that session:
- Clone the golden base. Nucleic makes a copy-on-write clone of the base image — fast and space-efficient, since unchanged blocks are shared with the base rather than copied.
- Boot and connect. It boots the clone and connects to it over SSH.
- Share the repo. That session's repository is shared into the VM over virtiofs at
/Volumes/My Shared Files/workspace, so the agent builds the exact working tree it's editing.
When the VM goes idle (default 15 minutes), it stops to free RAM — but its disk persists, so the next turn reboots quickly instead of re-cloning from scratch. When the session ends or is interrupted, the clone is deleted. Any orphaned clones left behind by a crash are cleaned up on the next app launch.
05Concurrency & resources
macOS caps how many macOS guests can run at once — about 2 on recent releases. Nucleic works within that limit rather than fighting it:
- Max concurrent VMs. When the cap is reached, extra agents queue for a VM rather than failing — a session waits its turn for a slot instead of erroring out.
- CPUs. A per-session ceiling on virtual CPUs (default 4).
- Memory. A per-session memory ceiling (default 8 GB).
06What's next
Now that you know what macOS VMs are, these guides take you the rest of the way:
- Building the base image — the required one-time build that every per-session VM is cloned from.
- Computer use for macOS VMs — letting an agent see and drive the VM's screen with screenshots, clicks, and typing.
- Setting up AX-based computer use — the advanced, semantic accessibility agent for by-identity control of the guest.