Ok, so a lot of this boils down to the fact that this sort of software really wants to be running on linux. For both windows and mac, the only way to (really) do that is creating a VM.

It seems to me that the main issue here is painful disconnects between the VM and the host system. The kernel in the VM wants to manage memory and disk usage and that management ultimately means the host needs to grant the guest OS large blocks of disk and memory.

Is anyone thinking about or working on narrowing that requirement? Like, I may want the 99% of what a VM does, but I really want my host system to ultimately manage both memory and disk. I'd love it if in the linux VM I had a bridge for file IO which interacted directly with the host file system and a bridge in the memory management system which ultimately called the host system's memory allocation API directly and disabled the kernels memory management system.

containers and cgroups are basically how linux does this. But that's a pretty big surface area that I doubt any non-linux system could adopt.

Given that Claude Code runs without issues on macOS, I'd guess that it's more about sandboxing shell sessions (i.e. not macOS applications or single processes, for which solutions exist).

Unfortunately, unlike Linux, macOS doesn't have a great out-of-the-box story there; even Apple's first-party OCI runtime is based on per-container Linux VMs.

It’s a solved problem in the VM world too. Memory ballooning is a technique where a driver inside the VM kernel cooperates with the hypervisor to return memory back to the host by appearing to consume the memory from the VM. And disk access is even easier; just present a network filesystem to the VM.