Hacker News [expanded by feedex.net]

Claude Desktop spins up a VM without no way of stopping it

Wed, 10 Jun 2026 17:11:56 +0000

[ comments ]

Open

Labels

invalidIssue doesn't seem to be related to Claude Code

Description

Preflight Checklist

I have searched existing issues and this hasn't been reported yet
This is a single bug report (please file separate reports for different bugs)
I am using the latest version of Claude Code

What's Wrong?

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

Note: This issue is specific to the Claude Desktop app (Windows), not Claude Code CLI.

OS: Windows 11 Pro 25H2, Build 26200.7840
Hardware: Razer Blade 15 Base Model (Late 2020), i7-10750H, 16 GB RAM
Claude Desktop: Latest version as of 2/26/2026
Windows Features: VirtualMachinePlatform enabled; Hyper-V, WSL, Docker, and Windows Sandbox are all disabled
Core Isolation / Memory Integrity: Off

Summary
The Claude Desktop app launches a Hyper-V virtual machine (Vmmem) consuming approximately 1.8 GB of RAM every time it starts — even when the user only needs chat functionality and has no intention of using Cowork or agent mode. On a 16 GB laptop, this represents over 11% of total memory consumed by infrastructure that isn't being used.
Steps to Reproduce

Install Claude Desktop on Windows 11 with VirtualMachinePlatform enabled
Use Cowork/agent mode at least once (this creates session files)
Close and reopen Claude Desktop — or simply reboot the machine
Open Task Manager and observe Vmmem consuming ~1,800 MB

What Happens
On every launch, the Claude Desktop app triggers the Hyper-V Host Compute Service (vmcompute) via an RPC interface event, which spawns a vmwp.exe process hosting a full virtual machine. This VM appears as "Vmmem" in Task Manager at approximately 1,796–1,846 MB.
The Hyper-V Compute Admin event log shows repeated errors:
"The specified property query is invalid: The virtual machine or container JSON document is invalid. (0xC037010D, 'Invalid JSON document '$'')"
These errors have been occurring since at least 2/19/2026, triggered on every boot and app launch.
Root Cause Investigation
Through extensive PowerShell diagnostics, we confirmed:

WSL is not installed — wsl --shutdown returns "not installed"
Hyper-V management tools are not installed — Get-VM fails
Docker is not installed — no Docker processes found
Windows Sandbox is disabled
Core Isolation / Memory Integrity is off (and was off before this issue started)
VirtualizationBasedSecurityStatus shows 2 (running), likely due to LSA Protection being enabled — but this alone doesn't explain the 1.8 GB VM
The only enabled virtualization feature is VirtualMachinePlatform

The vmcompute service is set to Manual start but is triggered at boot by an RPC interface event (GUID: bc90d167-9470-4139-a9ba-be0bbbf5b74d). The parent process is services.exe (PID 1400), confirming it's a service trigger, not a user-initiated launch.
We found 2,689 stale session files in %APPDATA%\Claude\local-agent-mode-sessions\ — all from previous Cowork sessions that were never cleaned up. Session names follow Docker-style naming (e.g., "nifty-dreamy-volta", "tender-vigilant-goodall", "admiring-elegant-johnson"). Even after deleting all 2,689 files and killing vmcompute/vmwp, simply reopening the Claude Desktop app immediately respawned the VM and the 1.8 GB Vmmem process.
Impact
On a 16 GB system, this bug causes memory usage to jump from ~50% to ~62% at idle before the user does anything. Combined with normal application load, this pushes total usage to 70–75%, causing system sluggishness and forcing the user to manually kill VM processes after every launch.
Expected Behavior

The Claude Desktop app should not spawn a VM for chat-only sessions
If Cowork infrastructure is needed, it should initialize on demand — only when the user actually starts a Cowork/agent session
Stale session files from previous Cowork sessions should be cleaned up automatically, not accumulate indefinitely (2,689 files in our case)
The app should fall back to chat-only mode if VM initialization fails or is unnecessary, rather than unconditionally starting VM infrastructure

Current Workaround
The only reliable workaround is to disable VirtualMachinePlatform entirely:
powershellDisable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" -NoRestart
This prevents the VM from launching but also disables Cowork functionality. Alternatively, the user can kill the VM processes after every launch:
powershellStop-Process -Name vmwp -Force
Stop-Process -Name vmcompute -Force
Chat functionality continues to work normally after killing these processes.
Request
Please modify the Claude Desktop app so that:

VM/container infrastructure only initializes when Cowork or agent mode is actively requested
Old session data is cleaned up automatically after sessions end
The app gracefully handles the absence of VM infrastructure without degraded chat performance

What Should Happen?

The Claude Desktop app should not spawn a Hyper-V VM (Vmmem, ~1.8 GB RAM) when launching for chat-only use. VM/container infrastructure should only initialize when the user actively starts a Cowork or agent session. Stale session files should be cleaned up automatically after sessions end.

Error Messages/Logs

Hyper-V Compute Admin log shows repeated errors on every boot:
"The specified property query is invalid: The virtual machine or container JSON document is invalid. (0xC037010D, 'Invalid JSON document '$'')"

Steps to Reproduce

Install Claude Desktop on Windows 11 with VirtualMachinePlatform enabled
Use Cowork at least once
Close and reopen Claude Desktop (or reboot)
Observe Vmmem in Task Manager consuming ~1,800 MB at 0% CPU

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude Desktop (Windows) latest as of 2/26/2026

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

See detailed bug report in description above.

Reactions are currently unavailable

Metadata

Assignees

No one assigned

Labels

invalidIssue doesn't seem to be related to Claude Code

Type

No type

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

[ comments ]

Why SpaceX 2040 Revenue FCST $4.3T in highly unlikely

Wed, 10 Jun 2026 17:44:59 +0000

[ comments ]

← All essays

An essay in scrolls

Escape
Velocity

SpaceX's IPO prepares to defy gravity — physical and financial.

Scroll

A line is not a law.

[ comments ]

How JPL keeps the 13-year-old Curiosity rover doing science

Wed, 10 Jun 2026 17:30:48 +0000

[ comments ]

How JPL Keeps the 13-Year-Old Curiosity Rover Doing Science

It takes some special tricks to maintain a robot 200 million kilometers from home

6 min read

Evan Ackerman is IEEE Spectrum’s robotics editor.

Curiosity has explored Mars for well over a decade thanks to some ingenious tricks by JPL engineers to keep the rover going.

Thirteen years ago last August, I was camped out in NASA’s Jet Propulsion Laboratory press room in Pasadena, Calif., waiting to see whether the Curiosity rover would survive its descent and skycrane-assisted landing on the surface of Mars. It did, and it was awesome.

Since then, Curiosity (also known as Mars Science Laboratory) has traveled nearly 37 kilometers, drilled into and sampled 42 different rocks, and as of publication has snapped nearly 763,000 photos. The fact that this robot is still hard at work, getting real science done at the age of 13, is absolutely incredible—not only is Mars an actively hostile environment for robots, but the only kind of maintenance that JPL engineers can do is to send very, very careful software updates.

Nevertheless, the clever folks at JPL have managed to keep Curiosity safe, warm, mobile, and sciencing, despite well-worn wheels and less and less power every day. One of those folks is Alexandra Holloway, the assistant team chief for engineering operations for Curiosity, who spoke to IEEE Spectrum about keeping Curiosity roving, what its future looks like, and how JPL has used that experience to make rovers like Perseverance even more capable.

How astonished should we be that after 13 years on Mars, Curiosity is not only still doing science, but actually getting more capable?

Alexandra Holloway is the assistant team chief for engineering operations on the Curiosity Mars rover at the Jet Propulsion Laboratory.Alexandra Holloway

Alexandra Holloway: I’m astonished! The longevity comes from a lot of ongoing work. It’s not just that Curiosity was built robustly; it’s also because we’re continuously putting in effort to ensure it can continue to have that lifespan. I think about all the different kinds of embedded systems there are, from cars to refrigerators, and none of them have the kind of longevity that we have with the rover. It’s mind-boggling, and it’s inspiring.

Is the Perseverance rover, which is nine years younger than Curiosity, significantly different in terms of its hardware and software?

Holloway: In terms of hardware, the rovers are actually very similar. Both use a RAD 750 processor and have the same amount of memory. However, Perseverance has an extra processor specifically for visual odometry, which allows it to drive autonomously. This difference reflects their primary mission designs: Perseverance was designed for driving long distances, while Curiosity is a mission focused on sampling as it goes. So Perseverance’s onboard scheduling capabilities are there to optimize its driving. In fact, just last year, Perseverance surpassed Curiosity’s driving distance after only about three years on Mars.

Curiosity Rover Memory and Software Fixes

Do you have some examples of significant tweaks the team has made to keep Curiosity roving?

Holloway: One of my favorite examples comes from a processor anomaly that happened on Sol 2172 [Ed. note: “Sol” is the term for a Martian day—about 24 hours and 40 minutes]. Curiosity has two computers, A and B. We landed on A, swapped to B due to a NAND memory anomaly early on (Sol 200). For years, we were chugging along on B, until one day there was a problem—B booted up, but it couldn’t mount its drive partition. We’d never seen this before. To preserve B’s data, we swapped back to A, which we hadn’t trusted in two thousand Sols. A also had a degraded memory, with only two gigabytes of usable storage space instead of four. We painstakingly transferred data from B over to A and then down to Earth, and eventually we ran out of stuff we wanted to transfer, which was really good, because A then started acting funny in the same way it did on Sol 200. It was acting like its memory was coming unsoldered. That’s bad.

We quickly swapped back to B, formatted it, and got it working again. The problem then became that we couldn’t trust A’s memory at all, but we needed a second computer as a “lifeboat” for diagnostics and transfers if B failed again. We realized we had one other place of memory: where we keep our flight software. We have four copies of the flight software (two current versions and two older versions) in different banks of very small amounts of memory, just 32 megabytes each. What if we just jettisoned the old flight software copies and used that 64-megabyte NOR memory as our file system for computer A?

So that’s what we did. It was so elegant! Computer A is operating with less than 1 percent of its original memory, but we can run a mission on it. A small mission, but we haven’t had to jettison any core capabilities. We can still drive, we can manage data, we can even theoretically do science. Everything works fine, just much slower and much smaller. That flight software release was even called “R-Hope“ because we hoped it would work.

What are the constraints on Curiosity’s lifespan?

Holloway: Our biggest hardware challenge is wheel wear. It looks like we’re driving on this sandy terrain with some rocks in it, and our intuition said that we could just drive over these rocks and they’d get pushed down into the sand and it would be no big deal. But what we ended up seeing was that those little rocks are actually the tips of giant boulders buried in the sand, and they’re razor sharp. Our wheels were getting ripped apart driving over them, especially our front wheels, so we started driving backwards.

We also monitor consumables. We consider the number of times we move our actuators. That’s a consumable. Curiosity hasn’t taken a selfie in a while, and one of the reasons is that it’s really hard on the joint actuators. Our onboard memory is a consumable, but surprisingly we’re not anywhere near our life cycle for memory. Our biggest consumable is power; we have an RTG, a nuclear power source, which decreases its output as it ages.

Newer missions are flying Snapdragon [processors], but Curiosity’s RAD 750 is a power hog. One of the things that we’ve rolled out that’s going really well is a way of reducing the amount of time we spend with the computer powered on, by harvesting time when we finish activities early and going to sleep, which lets us turn off the computers and some of the heating. Another thing we’re looking at is doing stuff in parallel when we’re on, like being able to drive or use the arm while communicating with an orbiter.

So power is decreasing, and that’s causing us to do all this parallelism work and become more efficient and nuanced in the way we operate. But we are not having any degraded science output at this time. Our wheels are still going, our arm is still okay for now, knock on wood. I would say maybe the bottleneck is budget.

Curiosity Rover’s Impact on Future Mars Exploration

What have you learned from Curiosity that will improve future missions?

Holloway: As an embedded flight software person, I think about how we can change, add, or modify software capabilities during the mission. There’s definitely a sweet spot for loading and patching flight software—some of these concepts were pioneered on Spirit and Opportunity and then inherited by Curiosity and Perseverance, making it easier to understand and change the software.

Some of the things that I wish we had now on [the Mars Science Laboratory] include a better understanding of where our power is going. I want to see how much power each component is drawing every minute, so that we could architect a software system that could balance loads better. We have some of this information that was built in by the engineers who designed the rover, but as an operator, I want something slightly different. So if I were building a mission, I would have those discussions earlier and get operators into the room to say, “what do you want your data products to look like?”

The key takeaway for designing future missions is to talk to all your users early in the design process. It needs to happen upfront.

What does Curiosity’s long-term future look like?

Holloway: That’s a conversation that happens, and it’s a really delicate one. We have a lot of science instruments, and a lot of them have to do with contact science and sampling and rely on the arm. If we lose the arm, what science can we still do? Well, we have a lot of remote sensors too, like cameras, environmental sensors, and radiation sensors. All of these things are important for the future of space exploration and humans on Mars.

From a power perspective, our RTG is projected to start degrading science output in the sixth extended mission, but we’re going to be fine through 2035 and potentially even beyond that. So we have a long and exciting future ahead of us. We need to figure out the best way of operating within our constraints, but we’re still kicking.

Evan Ackerman

Evan Ackerman is a senior editor at IEEE Spectrum. Since 2007, he has written over 6,000 articles on robotics and technology. He has a degree in Martian geology and is excellent at playing bagpipes.

[ comments ]

I'm Eric Ries, author of "The Lean Startup" and new book "Incorruptible" – AMA

Wed, 10 Jun 2026 14:47:52 +0000

[ comments ]

Hey gang, you may remember me from such books as _The Lean Startup_ and _The Startup Way_.

It's been fifteen years since I wrote The Lean Startup, and in that time I've seen some things. In both big companies and tiny startups, NGOs and governments, in almost every industry you can name.

I've helped a lot of people create a lot of amazing companies, but I've also seen so many ways this can go wrong. There's a darkness in our industry that we often don't talk about.

I kept watching good companies drift away from the missions they were founded on. Not because anyone woke up one day and decided to be evil, but because the structure they were built on slowly pulled them there. I call that pull "financial gravity."

We've all experienced watching a company we love or admire be warped and broken beyond recognition; until it's a husk of its former self, or worse. I wanted to understand why. And I wanted to know what all of us can do to stop that from happening.

My new book _Incorruptible_ is my attempt to explain the invisible forces that shape organizations, and how a handful of companies (like Costco, Patagonia, and Novo Nordisk) have successfully been structured to resist gravity and thrive for decades -- or even centuries.

Along the way, I founded the Long-Term Stock Exchange, co-founded an AI R&D lab called Answer.AI with Jeremy Howard, and helped a number of notable companies with their governance (yes, including Anthropic).

I won't pretend I have this all figured out, but I've probably spent more time than is healthy on the "why do good companies go bad" question. Ask me anything!

[ comments ]

PgDog is funded and coming to a database near you

Wed, 10 Jun 2026 14:02:59 +0000

[ comments ]

Postgres is the only database you need.

The reason DBs like Mongo or Dynamo exist is because Postgres has a scaling problem. If you could make it just work, with 100 TB+ tables and 1M queries per second, we don’t think you would use anything else.

This is why we are building PgDog. Same old Postgres, just with a proxy in front of it, to make it horizontally scalable.

You can deploy PgDog anywhere, including on-prem and in your cloud account: pull our Docker image, change your DATABASE_URL, and make us do the work.

Our status

PgDog is serving more than 2M queries per second, in production, across dozens of deployments. We sharded over 20 TB that we know about.

PgDog is open source and anyone can just deploy it, and they do: we have over 1.4M Docker pulls on GitHub.

A new version comes out every week, on Thursdays. Our Discord community is growing. We are there, every day, to answer questions and provide support.

Why us

PgDog is a small, three-person startup. So, why use our stuff and trust us with your data?

We are infrastructure engineers, application engineers and generalists. We built apps on Postgres before it was cool and made it work at massive scale.

I ran Postgres at Instacart, where we scaled the company 5x in April of 2020. The biggest problem we had was making Postgres serve 100,000s of grocery delivery orders per minute.

We sharded Postgres on RDS, Aurora and EC2. We fixed the actual problem, using first principles (and a lot of code).

The same technology is now available as an open source product.

Building PgDog is not a pivot. For us, scaling Postgres has been, and is, the only goal.

We built PgDog to run in your cloud, in your colo rack, on-prem, or on your laptop. Wherever you need it, PgDog works, with no dependencies or hidden serverless costs. If you can provide CPUs, our multithreaded code will use them all.

Postgres adoption is only going to increase. With $5.5M from Basis Set, YC, Pioneer Fund and other great investors, we have years of runway, and we are going to make Postgres just work, for everyone, at any scale.

– Lev

P.S. We are building an Enterprise edition of PgDog to make it easier to run in AWS. It comes with SLA-backed support from our team. Give us a call if you want to try it out.

More info

Read our docs to get started with PgDog
Star our repo and follow it for weekly releases
Join our Discord to get to know us better

[ comments ]

Hacker News [expanded by feedex.net]

Claude Desktop spins up a VM without no way of stopping it

Description

Preflight Checklist

What's Wrong?

What Should Happen?

Error Messages/Logs

Steps to Reproduce

Claude Model

Is this a regression?

Last Working Version

Claude Code Version

Platform

Operating System

Terminal/Shell

Additional Information

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Why SpaceX 2040 Revenue FCST $4.3T in highly unlikely

EscapeVelocity

A line is not a law.

How JPL keeps the 13-year-old Curiosity rover doing science

How JPL Keeps the 13-Year-Old Curiosity Rover Doing Science

Curiosity Rover Memory and Software Fixes

Curiosity Rover’s Impact on Future Mars Exploration

I'm Eric Ries, author of "The Lean Startup" and new book "Incorruptible" – AMA

PgDog is funded and coming to a database near you

Our status

Why us

More info

Escape
Velocity