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

Claude’s Windows desktop app is drawing criticism for automatically creating a large Hyper‑V virtual machine — reportedly 1.8–13 GB and always on — even when users only want basic chat and never enable the Cowork feature it powers. Commenters argue this design wastes storage and memory, reflects rushed “vibe‑coded” engineering, and offers no clear way to opt out or control the sandbox, while others defend per‑app VMs as a reasonable security model for agents that can touch local files. The debate highlights broader frustration with bloated, buggy AI clients and the tension between rapid feature rollout, OS‑level integration, and thoughtful, transparent UX and security choices.

VM behavior & disk/RAM impact

  • Claude Desktop starts a Hyper‑V or similar VM on every launch, even for chat‑only use.
  • Reported VM sizes range from ~1.8 GB RAM to 10–13 GB on disk; some macOS users see ~20 GB consumed when Cowork is triggered.
  • Cowork’s VM bundle is installed by default, is not officially removable, and is silently re‑created if deleted or if Cowork is clicked.
  • Users on 256 GB SSDs find this particularly painful; some “remove” it by deleting contents and locking folder permissions.
  • On Windows, disabling Hyper‑V / “Virtual Machine Platform” or running Claude inside a separate VM can avoid or contain it.

Why the VM exists & design tradeoffs

  • The VM powers Claude Cowork, running tools and code in a sandbox and sometimes mounting specified host directories.
  • Some believe eager startup is a performance optimization and a deliberate attempt to reduce friction to using Cowork.
  • Others argue it should be:
    • Opt‑in
    • Started on‑demand
    • Allowed to shut down when idle
    • Exposed via a clear sandbox on/off toggle
  • A minority feels the design is fine if the VM exits with the app; another group is uneasy about an opaque “black box” with unclear observability or logging.

Software quality, “vibecoding,” and UX

  • Many comments criticize Claude’s desktop, CLI, and TUI as slow, buggy, and over‑engineered (React‑heavy, large codebase) relative to a chat client.
  • Users report broken cross‑platform links (e.g., macOS URLs shown on Windows), scrambled terminals, and poor performance in both desktop and web UIs.
  • Several attribute this to “vibe‑coded” features, heavy reliance on LLM‑generated code, and lack of careful human review.
  • Others counter that rapid iteration and shipping partially‑baked features is expected in the current AI race, especially for client “glue” around backends.

Security, sandboxing, and usage patterns

  • Some see per‑app VMs as the right long‑term model: self‑modifying, strongly sandboxed agents with controlled I/O.
  • Others already run Claude/agents with full system access and consider elaborate sandboxing overkill for personal use, relying on backups and source control.
  • There is broad agreement that prompts and local code sent to the model are already going to the provider’s servers; trust mainly comes from policies and contracts, not just the presence of a local VM.

Meta & language

  • Multiple comments nitpick the original title’s double negative (“without no way”), though others view this as unhelpful pedantry.