Pick a hypervisor based on the host's actual nested-virt capability
instead of always using QEMU/HVF (which doesn't expose nested KVM):
* Apple Silicon M3+ on macOS 15 Sequoia+: QEMU/HVF with
-cpu host,el2=on so the Linux guest's KVM (and therefore
firecracker microVMs) actually works.
* Intel Mac: VirtualBox with --nested-hw-virt on. Cask is
installed on demand; the seed ISO and SSH key flow are shared
with the QEMU path.
* Apple Silicon M1/M2 (any macOS), or M3+ pre-Sequoia: skip the
whole VM step and print a notice pointing at a Linux cloud VM
as the only path to firecracker on that hardware.
Backend selection is centralized in _select_vm_backend(); the rest
of setup_firecracker_vm (image download/verify, cloud-init seed,
SSH wait, in-VM firecracker probe, zsh wrapper) is shared.
https://claude.ai/code/session_01R2CnCeEBYT5QoHiwxczDNq
After the normal package install on macOS, fetch the latest Fedora
cloud qcow2 (auto-discovered from dl.fedoraproject.org), verify its
SHA256, build a cloud-init seed ISO with hdiutil, boot it under
QEMU/HVF (UEFI on aarch64, q35 on x86_64), and wait for cloud-init
to install firecracker inside the guest.
Then write a `firecracker()` function block into ~/.zshrc that
starts the backing VM on demand and proxies invocations via SSH.
The host's own firecracker custom-package install is dropped on
macOS since it's Linux-only. Suppress the whole flow with --no-vm.
https://claude.ai/code/session_01R2CnCeEBYT5QoHiwxczDNq
Detect Darwin automatically and, on macOS, install the Xcode Command
Line Tools and Homebrew as the first actions before any package work.
Route system packages through brew (formulae and casks), skip the
Flatpak section entirely, refuse to run as root (brew won't), and
adjust custom-package URL/install-path templates with new {os}, {os_go},
{os_zig}, {os_nvim} substitutions. Architecture detection remains
dynamic on both Apple Silicon and Intel.
https://claude.ai/code/session_01R2CnCeEBYT5QoHiwxczDNq
Claude