Show HN: Lume 0.2 – Build and Run macOS VMs with unattended setup (opens in new tab)

Apple also provides instructions for downloading many older macOS versions via your terminal: https://support.apple.com/en-us/102662#terminal

There's a kernel-level check in the Hypervisor framework that enforces the 2 VM limit, and bypassing it violates Apple's EULA.

Nice technical deep-dive on the how here: https://khronokernel.com/macos/2023/08/08/AS-VM.html

So we just click through like a human would via VNC. Version-specific but works with their security model rather than against it.

We've also built a broader ecosystem on top - the Cua computer and agent framework for building computer-use agents: https://cua.ai/docs

We went through the comparison with Tart, Lima etc here: https://github.com/trycua/cua/issues/10

- macOS GUI apps (Xcode, Numbers, Safari, etc.) - macOS desktop automation (screenshots, mouse/keyboard input, accessibility APIs) - macOS CI/CD (building iOS/macOS apps, running XCTest)

...you need an actual macOS VM, which is what Lume provides.

Good news is there are hints of GPU passthrough coming (_VZPCIDeviceConfiguration symbol appeared in Tahoe's Virtualization framework), so that might land in a future macOS release. We're keeping an eye on it.

defaults write only works after you have shell access, which means Setup Assistant is already done.

There are tools that modify marker files like .AppleSetupDone via Recovery Mode, but that's mainly for bypassing MDM enrollment on physical Macs - you'd still need to create a valid user account with proper Directory Services entries, keychain, etc.

The VNC + OCR approach is less elegant but works reliably without needing to reverse-engineer macOS internals or rely on undocumented behaviors that might break between versions.

For agent observability, we handle this at the Cua framework level rather than the VM level:

- Agent actions and tool calls are logged via our tracing integration (Laminar, OpenTelemetry) - You can see the full decision trace - what the agent saw, what it decided, what tools it invoked - For the "what HTTP requests actually went out" question, proxying is still the right approach. You could configure the VM's network to route through a transparent proxy, or set up mitmproxy inside the VM. We haven't built that into Lume itself since network inspection feels orthogonal to VM management.

That said, it's an interesting idea - exposing a proxy config option in Lume that automatically routes VM traffic through a capture layer. Would that be useful for your workflow?