HN Debrief

Claude Desktop spawns 1.8 GB Hyper-V VM on every launch, even for chat-only use

  • AI
  • Developer Tools
  • Security
  • Windows

The GitHub post says Claude Desktop on Windows launches a Hyper-V VM that consumes about 1.8 GB of RAM at startup, even for simple chat use. Commenters quickly filled in the missing context. The VM exists for Claude Cowork, Anthropic’s sandboxed local agent mode, where the model can operate inside an isolated environment instead of directly on the host machine. That part did not bother most people. What bothered them was the product decision around it. The sandbox starts eagerly instead of on demand, appears hard or impossible to disable in normal use, and comes with a large local image that multiple people said takes roughly 10 to 13 GB of disk, with some Mac users reporting closer to 20 GB after triggering Cowork once.

If you ship local AI agents, treat isolation as a feature users opt into and can inspect, not a hidden tax on RAM and disk. If you deploy these tools in a company, assume desktop agent apps still need the same scrutiny you would apply to any endpoint software with broad file and network access.

Discussion mood

Strongly negative. People mostly accepted the need for sandboxing, but they were annoyed by the default-on behavior, extra RAM and disk usage, lack of an off switch, and a string of sloppy desktop bugs that make Anthropic look strong on models and weak on software craft.

Key insights

  1. 01

    The objection is eager startup, not sandboxing

    The VM is there because Cowork runs inside a sandbox, and several people who actually use agent features said that is sensible. The failure is starting it immediately, keeping a large image around, and not cleanly separating chat mode from agent mode. That distinction changes the story from “Anthropic added a weird VM” to “Anthropic chose the wrong activation model for a legitimate security design.”

    If you build agent features, gate the sandbox behind first use and shut it down when idle. Split lightweight chat from privileged local automation so users can predict the cost of each mode.

      Attribution:
    • nathanyz #1 #2
    • boudra #1
    • giancarlostoro #1
    • tom1337 #1
  2. 02

    The broken macOS link on Windows made the quality critique concrete

    A reported Windows permission dialog that tries to open an x-apple.systempreferences link turned general complaints about sloppiness into a crisp product failure. This is not an abstract rant about Electron or AI hype. It is a basic cross-platform bug in a high-visibility flow, which makes the larger claim about weak testing much easier to believe.

    Look for simple platform-specific footguns when evaluating AI desktop tools. A few obvious misses in setup or permissions are a good proxy for how much care went into the rest of the client.

      Attribution:
    • literatepeople #1
    • maweaver #1
    • angry_octet #1
  3. 03

    Windows users may be better off sandboxing Claude themselves

    One practical workaround came from someone running Claude Desktop inside their own Hyper-V VM with the Virtual Machine Platform feature disabled inside that guest, which causes Cowork to be unavailable. They also noted that Claude Code on Windows lacks the sandboxing support Anthropic ships for Linux and macOS, so isolating the whole app in Windows Sandbox or a separate VM is the safer setup anyway. That reframes the issue as partly a Windows support gap, not just a wasteful startup choice.

    On Windows, do not assume Claude’s own isolation story is complete. If you need local agent access, consider running the tool inside Windows Sandbox, Hyper-V, or WSL2-based isolation instead of trusting the desktop app’s defaults.

      Attribution:
    • electroly #1
    • angry_octet #1
  4. 04

    Per-agent microVMs look like a real software pattern

    A more forward-looking argument was that bundling an agent, its tools, and its mutable workspace inside a microVM is a sensible application model for self-modifying software. The interesting part was not the buzzword. It was the packaging question. How do you expose UI, files, and network permissions cleanly when the app logic lives behind a VM boundary. That is closer to a new app runtime than a one-off Claude quirk.

    Expect agent products to converge on VM or container boundaries as a standard safety layer. The competitive edge will come from how clearly they expose permissions, lifecycle, logging, and integration points to users and admins.

      Attribution:
    • dbmikus #1 #2 #3
    • danudey #1

Against the grain

  1. 01

    If Cowork is core, prewarming the VM is reasonable

    A few people argued that if the product is built around agent workflows, keeping the sandbox ready is the simplest way to avoid cold-start friction. For users who actually rely on Cowork, an always-ready VM can feel like the correct tradeoff, and some saw the obvious alternative for chat-only use as just pinning the web app or installing it as a PWA instead of using the full desktop client.

    Do not assume every heavy startup path is accidental. If your users live in the agent mode, measure whether prewarming improves perceived responsiveness enough to justify a separate power-user build or setting.

      Attribution:
    • nailer #1
    • gastonmorixe #1
    • Grombobulous #1
  2. 02

    The VM is not the real privacy boundary

    One skeptic saw the hidden VM as an opaque black box on the user’s machine. The pushback was that this misses where trust already has to be placed. Once you grant Claude local file access and network connectivity, the vendor can send data upstream regardless of whether a VM is involved. In practice the enforceable boundary is the contract and privacy policy, not the presence or absence of Hyper-V.

    When you assess risk from desktop AI tools, focus first on data access, telemetry, and contractual controls. A sandbox changes host safety more than it changes what the vendor can see once you authorize the app.

      Attribution:
    • doublerabbit #1
    • Grombobulous #1
  3. 03

    The alternative is a much scarier host compromise

    One blunt defense was that people would be far angrier if an agent ran destructive shell commands directly on the host. From that view, a wasteful sandbox is still better than pretending local agents can be safe without strong isolation. It does not excuse the UX, but it does challenge the idea that the VM itself is the mistake.

    Separate complaints about implementation from complaints about architecture. If you plan to let an LLM execute code or shell commands, keep a hard isolation boundary even if the first version is clumsy.

      Attribution:
    • Uptrenda #1

In plain english

Claude Cowork ↩
Anthropic’s desktop agent feature that can perform tasks using a sandboxed local environment.
Hyper-V ↩
Microsoft’s built-in virtualization system for running virtual machines on Windows.
microVM ↩
A very lightweight virtual machine designed for fast startup and strong isolation.
PWA ↩
Progressive web app, a website designed to behave more like an installable app, often with offline support and home-screen integration.
sandbox ↩
An isolated environment that limits what software can access or change on the host system.
VM ↩
Virtual machine, a software-emulated computer that runs its own operating system isolated from the host.
Windows Sandbox ↩
A disposable isolated Windows environment that can be launched for safely running software.

Reference links

Original issue and user reports

Related products and infrastructure

  • Barnum
    Suggested as a local LLM-oriented programming and workflow tool
  • Docker Sandboxes
    Referenced as a similar direction for isolating agent work in packaged environments

Background references