Claude桌面端偷偷跑虚拟机:1.8GB内存被谁吃了?

· 科技资讯

你打开Claude Desktop,准备问一句”今天天气怎么样”——一个纯文本聊天请求,不涉及代码执行,不需要文件操作,就是打字聊天。

Claude桌面端偷偷跑虚拟机:1.8GB内存被谁吃了?封面

然后你的电脑风扇开始狂转。

打开任务管理器,你会看到一个名为Vmmem的进程,正在吞噬1.8 GB内存。它属于一个完整的Hyper-V虚拟机——在你点开Claude的那一刻,它就被静默启动了。

这就是2026年2月引爆HN的Claude Desktop争议核心:你什么都没做,它已经把近2GB内存预占了。

事件始末:一个偶然的发现

2026年2月26日,GitHub用户@davidellect在Anthropic官方仓库提交了Issue #29045。标题简洁但冲击力十足:

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

他的配置很普通:一台Razer Blade 15笔记本,i7-10750H处理器,16 GB内存,Windows 11。没有安装WSL,没有开Hyper-V,没有装Docker,甚至连Windows沙盒都是关着的。VirtualMachinePlatform是他唯一启用的虚拟化功能——而这也只是Claude Desktop安装时要求的。

但每次启动Claude Desktop,Task Manager就会多出一个vmwp.exe进程和随附的Vmmem进程,稳定消耗1,796–1,846 MB内存。更离谱的是:

– 他没有打开Cowork标签页

– 他没有使用任何Agent功能

– 他只是在聊天框里打字

在这个16GB的系统上,什么都不做时内存占用就已经从50%跳到了62%。加上日常浏览器和办公软件,总占用率轻松突破70%-75%,系统出现明显卡顿。

这件事在Hacker News上迅速发酵,321个点赞、228条评论,成为当周最受关注的AI工具争议之一。

这1.8GB到底在跑什么?

要理解这个问题,得先搞清楚Claude Desktop在Windows上的架构。

Claude的Cowork功能——那个可以操作你本地文件、执行命令、自动完成任务的”桌面Agent”——并不是直接跑在Windows上的。它运行在一个独立的Linux虚拟机里,通过Hyper-V(Windows宿主机计算服务HCS)管理。这个VM有自己的内核、根文件系统、网络栈和一个持久化状态磁盘。

从安全角度看,这个设计无可厚非。让一个AI Agent在沙箱里操作,总比让它直接裸奔在你的系统上强。

问题是:它在启动时就全部加载了,而不是在你点击Cowork的时候。

GitHub用户的深入排查发现了几层令人不安的事实:

第一,残留会话文件泛滥。 @davidellect在`%APPDATA%\Claude\local-agent-mode-sessions\`目录下找到了2,689个过期的会话目录,文件名是Docker风格的随机词组(如`nifty-dreamy-volta`、`tender-vigilant-goodall`)。这些文件来自之前的Cowork会话,从未被清理过。

第二,VM启动日志出现无效JSON错误。 事件查看器中的Hyper-V Compute Admin日志反复报错:

> “The specified property query is invalid: The virtual machine or container JSON document is invalid.”

残留的会话状态文件触发了VM的预加载逻辑,而这个预加载在JSON解析失败时依然照常执行——不管三七二十一,先占上内存再说。

第三,这不是一个Windows独有的问题。 macOS用户同样中招。Issue #30972确认,macOS上的”Cowork VM”进程在应用启动时就加载,即使从未打开Cowork标签页,内存消耗在1.9–3 GB之间。Reddit用户报告,Claude Desktop在macOS上还会静默下载一个约13 GB的VM镜像文件(`claudevm.bundle`),存放在`~/Library/Application Support/Claude/claude-code-vm/`里——即便你只是Free用户,即便你从未使用过Claude Code。

更严重的连锁反应

如果说1.8GB只是个开始,那后续爆出的相关Issue就是一连串深水炸弹。

Issue #40249:25GB RAM的噩梦。 一位32GB内存的Windows 11用户报告,Claude Desktop MSIX版本在启动时直接吃掉了25GB内存,同时启动了10个以上的`claude.exe`进程。问题根源依然是Cowork VM的预加载,加上”残留会话累积”。

Issue #49628:git.exe进程指数级复制。 Windows版Claude Desktop被发现在关闭应用后依然在后台不断复制`git.exe`进程,几分钟内生成约7,500个进程,最终耗尽系统资源,连WSL都跟着一起崩溃。

Issue #53250:WSL2被直接搞坏。 Claude Desktop的Cowork VM启动后,通过vsock接口永久破坏了WSL2的互操作功能,报错信息为”vsock accept4 failed 110″。修复手段只有一个:重启电脑。

> “Average users cannot self-diagnose this — it presents as ‘my computer got slow and WSL broke after installing Claude.'”

这条来自GitHub评论区的总结,戳中了一个核心矛盾:AI工具的复杂性正在越过用户的容忍阈值。 当你安装的是一个”聊天助手”,它却在背后拉起完整的虚拟化基础设施、占用接近2GB内存、破坏其他开发工具的正常运行,这种认知落差本身就是产品信任危机。

社区自救与官方沉默

在Anthropic给出正式修复之前,社区的workaround已经形成了三套方案:

方案一:自断一臂。 直接在Windows功能中禁用VirtualMachinePlatform。这是最彻底的办法——但代价是彻底失去Cowork功能。对于只想用聊天的人来说,这可能无所谓;但对于付费订阅了Pro/Max的用户,这等于花钱买了功能没法用。

Disable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" -NoRestart

方案二:手动宰进程。 每次启动Claude之后,用PowerShell杀掉vmwp和vmcompute进程。聊天功能在进程被杀后依然正常工作,说明这套VM基础设施对纯文本聊天而言根本是冗余的。

Stop-Process -Name vmwp -Force
Stop-Process -Name vmcompute -Force

方案三:注册表手术。 把CoworkVMService的启动类型改为”禁用”(Start值设为4)。这会阻止VM自动拉起,聊天功能不受影响。但磁盘上2GB的`rootfs.vhdx`文件依然留在那里。

社区的愤怒催生了工具化的自救方案:用户@JesperLive创建了[ClaudeFix](https://github.com/JesperLive/ClaudeFix),集合了上述所有修复手段和预防技巧。

与此同时,Anthropic的回应令人失望。Issue #29045被标记为“invalid”,理由是”Issue doesn’t seem to be related to Claude Code”——严格来说没错,这是Claude Desktop的问题,但用户根本分不清也无意区分”Claude Code”和”Claude Desktop”在GitHub仓库里的边界。

更重要的是,Reddit用户向官方支持询问是否能禁用VM预加载,得到的Fin AI Agent回复承认这是“当前桌面应用设计中的一个gap”,但同时表示:

– 预加载VM是”有意为之”的设计决策

– 个人用户无法在应用中关闭这一行为

– Web端的Cable开关不影响桌面应用

– 企业管理员可以通过策略标志禁用,但这一能力不向个人/团队用户开放

> 如果你是一个每月付20美元的个人用户,你的选择是:接受2GB内存被白白占用,或者动手改注册表。

这到底是谁的问题?

Claude Desktop的VM争议表面上是技术Bug,深层却是AI产品化过程中的结构性摩擦。

从技术角度,沙箱化Agent执行环境是有道理的。让AI直接读写你的文件系统、执行Shell命令,裸奔是不负责任的。但预加载策略暴露了一个产品思维盲区:开发者默认”用AI桌面端的人当然会用Agent功能”,但实际上绝大多数用户的日常行为就是聊天。

从透明性角度,Claude Desktop没有在任何地方提示用户”我们将启动一个完整的Linux虚拟机并占用1.8GB内存”。它甚至没有在UI上显示VM的运行状态。这种沉默让原本可能是合理设计的功能变成了”偷偷在后台吃资源”的信任危机。

从生态角度,这不是Claude一家的问题。随着AI客户端越来越”重”——本地推理、文件索引、Agent沙箱——资源消耗的边界在哪里?用户有权知道什么在跑、跑在哪儿、能吃多少内存吗?

Anthropic的产品负责人Cat Wu在最近一次Ars Technica采访中说了一句耐人寻味的话:”我们没有宏大的计划。”也许这就是问题所在:当你的产品跑得比规划快,基础设施上的技术债就会以”1.8GB静默VM”这种形式暴露出来。

而用户要的,其实很简单:一个开关。一个告诉我的按钮。一个我有权说”不”的选择。


— END —
LC 智趣厅 · 科技与生活的交点
ihygg.cn

滚动至顶部
微信公众号:LC智趣厅

扫码关注微信公众号
LC智趣厅