Show HN: Lume 0.2 – Build and Run macOS VMs with unattended setup

(cua.ai)

146 points by frabonacci 2 days ago

42 comments

View on Hacker News

Hey HN, Lume is an open-source CLI for running macOS and Linux VMs on Apple Silicon. Since launch (https://news.ycombinator.com/item?id=42908061), we've been using it to run AI agents in isolated macOS environments. We needed VMs that could set themselves up, so we built that.

Here's what's new in 0.2:

*Unattended Setup* – Go from IPSW to a fully configured VM without touching the keyboard. We built a VNC + OCR system that clicks through macOS Setup Assistant automatically. No more manual setup before pushing to a registry:

  lume create my-vm --os macos --ipsw latest --unattended tahoe
You can write custom YAML configs to set up any macOS version your way.

*HTTP API + Daemon* – A REST API on port 7777 that runs as a background service. Your scripts and CI pipelines can manage VMs that persist even if your terminal closes:

  curl -X POST localhost:7777/lume/vms/my-vm/run -d '{"noDisplay": true}'
*MCP Server* – Native integration with Claude Desktop and AI coding agents. Claude can create, run, and execute commands in VMs directly:

  # Add to Claude Desktop config
  "lume": { "command": "lume", "args": ["serve", "--mcp"] }
    
  # Then just ask: "Create a sandbox VM and run my tests"
*Multi-location Storage* – macOS disk space is always tight, so from user feedback we added support for external drives. Add an SSD, move VMs between locations:

  lume config storage add external-ssd /Volumes/ExternalSSD/lume
  lume clone my-vm backup --source-storage default --dest-storage external-ssd
*Registry Support* – Pull and push VM images from GHCR or GCS. Create a golden image once, share it across your team.

We're seeing people use Lume for: - Running Claude Code in an isolated VM (your host stays clean, reset mistakes by cloning) - CI/CD pipelines for Apple platform apps - Automated UI testing across macOS versions - Disposable sandboxes for security research

To get started:

  /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/trycua/cua/main/libs/lume/scripts/install.sh)"

  lume create sandbox --os macos --ipsw latest --unattended tahoe
  lume run sandbox --shared-dir ~/my-project
Lume is MIT licensed and Apple Silicon only (M1/M2/M3/M4) since it uses Apple's native Virtualization Framework directly—no emulation.

Lume runs on EC2 Mac instances and Scaleway if you need cloud infrastructure. We're also working on a managed cloud offering for teams that need macOS compute on demand—if you're interested, reach out.

We're actively developing this as part of Cua (https://github.com/trycua/cua), our Computer Use Agent SDK. We'd love your feedback, bug reports, or feature ideas.

GitHub: https://github.com/trycua/cua Docs: https://cua.ai/docs/lume

We'll be here to answer questions!

cmckn 2 days ago

I tried to set up a macOS VM recently so I could run an old version of iTunes to manage my iPods. I found it nearly impossible to even download an installer for older versions of the OS, and could never get it working. Where can one acquire an IPSW for, say, macOS Mojave? My understanding is this is not the same thing as the “Install macOS.app”?

Reply View 8 replies
  • CharlesW 2 days ago

    I like to use MIST (macOS Installer Super Tool) to grab old macOS versions: https://github.com/ninxsoft/Mist

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

    Reply View 1 reply
    • frabonacci 2 days ago

      Nice, thanks for sharing! It'd be interesting to integrate MIST into lume's ipsw command - right now Apple's native features in Apple Vz only provides download links for the latest supported version of the host, so grabbing older versions requires workarounds like this.

      Reply View 0 replies
  • samtheprogram 2 days ago

    For a version of macOS that old, you’d probably want a dmg, which you can create with createinstallmedia if you have the Install macOS.app. Not sure if it’s supported with Lume as it’s the first time I’ve heard of it.

    Reply View 0 replies
  • LoganDark 2 days ago

    Mojave never was an IPSW, because it never ran on Apple Silicon. I imagine this tool might just not support that at all.

    Reply View 2 replies
    • frabonacci 2 days ago

      LoganDark is right. I've personally never tried, and don't think it'd be easy for any macOS predating Apple Virtualization Framework. For that you'd need something like UTM since they're relying on QEMU - these configs might help: https://github.com/adespoton/utmconfigs

      Reply View 1 reply
      • cmckn 2 days ago

        Ahh I see. UTM was what I was trying, so I’ll give those a look! Thanks

        Reply View 0 replies
  • illithid0 2 days ago

    I was trying to do something similar last year and gave up because it felt futile. That said, it was the push I needed to try Rockbox, and I haven't looked back. Managing things via the file system is really nice.

    Reply View 1 reply
    • cmckn 2 days ago

      I started on my Linux box and despite many apps claiming to support iPods, none would actually work. I ended up getting an old Mac mini running again and I’m using that for now. I’ve never given Rockbox a good look, I should check it out.

      Reply View 0 replies
kxbnb a day ago

The MCP Server integration is a great addition - being able to have Claude manage VMs directly opens up interesting sandboxing patterns for agent workflows.

One thing I've been thinking about with agents running in isolated environments: how do you handle visibility into what API calls the agent is making from within the VM? Right now we rely on proxying outbound requests to see what's actually happening. Does Lume expose any of that through the MCP interface?

Nice work on the unattended setup - that's usually the painful part.

Reply View 1 reply
  • frabonacci a day ago

    Thanks! On API call visibility - Lume's MCP interface doesn't expose outbound network traffic directly. It's focused on VM lifecycle (create, run, stop) and command execution, not network inspection.

    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?

    Reply View 0 replies
ahmadyan 2 days ago

I believe this is using Virtualization.framework and not Containerization API from Tahoe, right?

Is there a limit on number of instances you can have per physical mac? i recall there was a hard limit of 2 because of EULA, unless Apple has changed it. (Cupertino really likes to sell you their Macs)

Reply View 1 reply
abrookewood 2 days ago

"We built a VNC + OCR system that clicks through macOS Setup Assistant automatically" - that is both awesome and annoying. I guess I assumed that Apple supported some form of unattended setup.

Reply View 1 reply
  • frabonacci 2 days ago

    Yeah, Apple intentionally provides no unattended setup. Plus any process trying to control the UI programmatically needs explicit accessibility permissions, which defeats the purpose.

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

    Reply View 0 replies
fartfeatures 2 days ago

How does this compare to something like Tart and shapehq/tartelet

Reply View 8 replies
  • frabonacci 2 days ago

    Both use Apple's Virtualization Framework, so core VM performance is similar. Main differences are around agent-first design (HTTP API, MCP server), unattended setup via VNC + OCR, and registry support for VM images.

    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

    Reply View 7 replies
    • fartfeatures 2 days ago

      Thanks for answering, makes sense.

      Not seeing any reference to Tart at that link. Tart also has registry support for VM images it treats them very much like Docker images, is that what you are doing too?

      Is it worth putting a comparison up somewhere other than a Github thread? Seems to be a frequently asked question at this point.

      Also worth drawing attention to Tart being source available not open source.

      Reply View 6 replies
JSR_FDED 2 days ago

Looked at Lume before and it was already very impressive then. For this unattended use case this looks amazing.

Slight tangent - do the VMs have decent graphics performance? I live in fear of one day accidentally pressing the Update button and being forced into the GUI mess that is Tahoe. Knowing I could just use a VM with Sequioa as my primary desktop would dramatically lower my anxiety.

Reply View 1 reply
  • frabonacci 2 days ago

    Thanks! On graphics - currently it's paravirtualized via Apple's Virtualization Framework, so basic 2D acceleration but no GPU passthrough. Fine for desktop use, web browsing, coding, productivity apps. Wouldn't recommend it for anything GPU-intensive though.

    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.

    Reply View 0 replies
JimDabell 2 days ago

> We built a VNC + OCR system that clicks through macOS Setup Assistant automatically.

You can automate at least some of this with `defaults write` commands or copying files to the right places. If you look at what some existing MDM platforms do you should be able to do this a lot more efficiently.

Reply View 2 replies
  • frabonacci 2 days ago

    MDM platforms can skip Setup Assistant, but they require the device to be pre-enrolled in Apple Business Manager before first boot - VMs can't be enrolled in ABM, so those hooks aren't available.

    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.

    Reply View 1 reply
    • saagarjha 2 days ago

      Surely your VNC script is guaranteed to break between versions

      Reply View 0 replies
whinvik 2 days ago

Sorry for the naive question but specifically for running Claude on a sandbox, why do people decide to use lume as opposed to running it on Docker?

Reply View 7 replies
  • frabonacci 2 days ago

    Docker on Mac runs Linux containers inside a Linux VM - you can't run macOS in Docker. So if you need Claude / Codex / OpenCode to interact with:

    - 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.

    Reply View 6 replies
eptcyka 2 days ago

How is the networking? Tart broke networking in Tahoe. Would love to see this work, setting up base images has always been a massive pain.

Reply View 2 replies
  • frabonacci 2 days ago

    We haven't observed any networking degradation with Lume on Tahoe so far - things have been working smoothly in our testing. Give it a try and let us know if you run into any issues!

    Reply View 0 replies
  • fkorotkov 2 days ago

    Can you elaborate on what got “broken” on Tahoe?

    Reply View 0 replies
pjmlp 2 days ago

This at least feels more natural than writing Swift scripts.

Reply View 0 replies