The editorial argues Anthropic is right to isolate model-generated code execution inside a hypervisor — it's table stakes for any agent that can write and run code on your machine. But treating the sandbox as an invisible implementation detail rather than a first-class resource users own and control is the actual defect. The fix is a lifecycle UI (menu item, settings toggle, CLI command), not ripping out the VM.
Filed the original issue after discovering Claude Desktop spawns a virtualization process that persists after the app is quit, holds roughly 2GB of memory, and respawns on next launch even after a kill -9. The grievance is that there is no menu item, settings toggle, or CLI command to stop it — users only notice because of fan noise or battery drain mid-flight.
Points to Apple's new container CLI and OrbStack's per-app micro-VMs as evidence that the hypervisor-per-tool pattern is now the default across dev tooling. The pattern itself is sound and converging across the industry; what's missing is the user-facing lifecycle story — start, stop, inspect, resource-cap — that desktop apps like Docker Desktop figured out years ago.
GitHub issue [#29045](https://github.com/anthropics/claude-code/issues/29045) on the `anthropics/claude-code` repo hit the Hacker News front page with 251 points and a title that does most of the work: *"Claude Desktop spins up a VM without no way of stopping it."* The grammar is rough; the complaint is not. Users report that after installing or updating Claude Desktop, a virtualization process appears in Activity Monitor, holds memory, and survives quitting the app. There is no menu item, no settings toggle, no `claude vm stop` command. The documented remedy in the thread is to find the hypervisor process by hand and `kill -9` it — which, predictably, the app re-spawns on next launch.
The VM is the sandbox Anthropic uses to execute model-generated code and tool calls in isolation from the host. Running untrusted LLM output inside a hypervisor is the right call from a security standpoint; shipping it without a lifecycle UI is a product bug. The issue thread is full of developers who only noticed the VM because their fans spun up or their battery drained mid-flight. One commenter pinned it at ~2GB resident; others reported the process refusing to release memory even after the GUI was closed via Cmd-Q.
This lands the same week Apple shipped its `container` CLI — which also runs each Linux container in its own lightweight VM on Apple silicon — and roughly a month after OrbStack normalized per-app micro-VMs for dev tooling. The hypervisor-per-tool pattern is now the default. The lifecycle story is not.
The security argument for sandboxing model output is airtight. An agent that can write and execute code on your machine is, by definition, a foothold; isolating it inside a VM with a constrained syscall surface is table stakes. Anthropic is not wrong to do this. The bug is treating the sandbox as an implementation detail rather than a first-class resource the user owns.
Compare the contrasts. Docker Desktop, for all its faults, has a tray icon, a quit button, and a settings pane that tells you how much RAM the Linux VM is allowed to consume. OrbStack exposes `orb stop` and surfaces per-container memory in a menubar widget. Apple's new `container` tool ships with `container system stop` on day one. Claude Desktop, per the thread, ships none of this. The VM is invisible until it isn't, and then it's unkillable through any documented path.
The HN comments split along a predictable line. One camp argues this is a reasonable trade-off for safety — if you give users an off switch, they'll flip it, and then the sandbox is decorative. The other camp points out that the same logic could justify any background process refusing to terminate, and that "trust us, it needs to run" is precisely the posture that produced the macOS background-daemon-soup the OS now actively fights. A sandbox the user can't audit isn't a sandbox; it's a black box with a security label.
There's also a credibility cost. Anthropic's positioning leans hard on safety, transparency, and developer trust. A laptop process that resists termination, eats 2GB of RAM, and has no documented control surface is exactly the kind of behavior the company's marketing implicitly promises to avoid. The issue is currently unlabeled and has no maintainer response at the time of writing — which, given the visibility, will not stay true for long.
The deeper pattern: 2026 is the year every AI dev tool became a hypervisor host, and none of them agreed on what "stop" means. Cursor, Windsurf, Claude Desktop, and the open-source agent runners are all converging on micro-VM execution. Each ships its own virtualization stack, its own lifecycle conventions, and its own definition of "the app is closed." For developers running three or four of these in parallel, the cumulative resource footprint is no longer trivial — and the mental model of "I quit the app, it's gone" is straightforwardly wrong.
If Claude Desktop is on your machine, open Activity Monitor and filter for `com.apple.Virtualization` or `vz`. If you see a process you didn't start, you've found it. The thread's workaround — `pkill -f Virtualization` followed by removing the app's LaunchAgent — works but is fragile across updates. A cleaner approach is to treat Claude Desktop as you would a Docker Desktop install: assume the VM is running whenever the binary exists on disk, and budget RAM accordingly.
For teams standardizing on AI-assisted dev environments, this is the moment to write a one-page policy. Which agents are allowed to install hypervisors? Who owns the lifecycle? What's the memory budget per developer laptop? The Docker Desktop fight of 2021 is repeating itself with AI tooling, and the orgs that win are the ones that notice early. Procurement reviews for AI dev tools should now include a "how do I stop it" question alongside the usual data-exfiltration and license diligence.
For anyone shipping a similar tool: the lesson is mundane and expensive. A menubar item with a memory readout and a quit-and-stay-quit button costs a week of engineering and buys you years of trust. Anthropic will fix this — the issue is too visible not to — but the next Claude Desktop user who notices the VM before reading the patch notes will already have decided what kind of company ships software like this.
Expect a patch within the week, a settings toggle within the month, and a sheepish blog post explaining the sandboxing rationale shortly after. The more interesting question is whether the broader AI tooling ecosystem standardizes on a shared lifecycle convention — a `~/.config/ai-sandbox/` equivalent of `XDG_RUNTIME_DIR`, or a macOS LaunchAgent contract that surfaces VMs in System Settings. Without that, every AI dev tool will keep reinventing the off switch, and developers will keep discovering them by reading GitHub issues at 2am when their MacBook fans won't stop.
I didn’t get a screenshot of this, but I just found a really pointed example of Anthropics lack of craft / rush to build. If you open Claude on Windows, and click Dispatch (under cowork) to start that up, it will tell you that you need permissions windows doesn’t have. When you click the button
The VM itself is for Claude Cowork which does all work within the VM sandbox. That doesn't help answer why they spin it up immediately and don't have a way to disable it though. Just the "why it exists" question.
I won't understand why Cowork isn't simply opt-in. It also installs a ~10GB vm bundle which you cannot removehttps://www.reddit.com/r/ClaudeAI/comments/1rlc71n/claude_de...
Back in the day, personalization / customization was all the rage, as it lets the user feel the control, power and freedom. Now it's the opposite. It's about not letting user to have any control at all. I can't delete some junk apps from my phone and mac, because they are "s
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
This all feels like a race where the model companies try to solve doing work locally in a way that doesn't suck, before the major operating systems companies figure out AI integration into their OS that doesn't suck. It also makes me wonder why Google which has both Gemini and Android can&