The agent sandbox that works is a disposable VM, and Apple decides its shape for you

A developer writing on dev.to published the build notes for giving a coding agent its own computer: a VM on the same Mac, a filesystem with none of his own files in it, credentials that only work on throwaway repos, and a snapshot taken before every session ^[2][3]. The reason to read it is the failure mode he names first, which is not a security model but a human one: the permission prompts get annoying enough that everyone eventually turns them off, and after that you are one confidently wrong `rm` away from a bad afternoon ^[1]. The interesting part is what the snapshot does to incident response. According to the author, when the agent does something destructive he does not debug it, he rolls back, and thirty seconds later the mistake never happened ^[4]. That converts a class of failure from investigation into a reset, which is the only reason it is tolerable to hand a shell to something that cannot be reliably instructed. Then the platform starts making architectural decisions on your behalf. Apple's Virtualization.framework boots two things, macOS on ARM and Linux on ARM, and that is the whole list: there is no Windows on ARM, and the author is blunt that this is not a licensing gate to argue past, there is simply nothing to enable ^[5]. Anything claiming otherwise, he writes, is describing UTM's QEMU backend or VMware Fusion, both of which ship their own hypervisor ^[6]. So if the agent's toolchain needs Windows, your hypervisor is chosen before you write a line of setup code ^[7]. For a sandbox it does not bite, because Linux is what you want anyway: smaller on disk, faster to boot, and it does not spend one of your two permitted macOS guests on a box that mostly runs `npm install` ^[8]. The two guest types also diverge in configuration in ways he says the docs do not foreground. macOS guests boot the macOS bootloader and need a separate auxiliary storage file next to the disk image; Linux guests boot EFI and need a variable store that persists across reboots ^[9]. Copy the disk image without that store and you get a guest that lands in an EFI shell and looks broken ^[10]. The debugging trap is better than the boot trap. Attaching a serial console to a Linux guest is the obvious move when it fails silently, except Ubuntu's Subiquity installer detects the serial port, moves the install UI off the graphical display onto the console in reduced text mode, and leaves your VM window looking hung ^[11]. His fix is to make the console opt in behind a flag, attached only while debugging ^[12]. The general rule he draws is worth keeping: on this framework, adding a device is never free, because every device is visible to the guest and the guest may make decisions about it ^[13]. His first version mounted the real project directory in over VirtioFS. It worked immediately and was pointless, because an agent that can write to your actual project folder is your main machine with extra steps ^[14]. The version that holds is copy in, work, copy the diff out, with a read-only share or no share at all and everything moving over SSH ^[15]. If you do share, the tag differs by guest: Linux picks its own tag and mounts it, while macOS guests use Apple's automount tag and the share appears at /Volumes/My Shared Files with no mount command ^[16]. For x86-64 binaries still lurking in a toolchain, Rosetta can be shared into an ARM Linux guest, with an availability check that distinguishes installed, not installed, and not supported ^[17]. Watch the ceiling: two macOS guests is a hard number, so any plan that wants a macOS agent box plus a macOS test box has already spent its budget ^[8].