Claude Desktop 的失控 VM 生命周期：当 AI 客户端工具突破用户边界

当 AI 工具开始自主管理计算资源时，谁来掌控启动与停止的开关？Claude Desktop 的 Cowork 功能提供了一个值得警惕的案例 —— 它在用户不知情的情况下自动创建 10GB 以上的虚拟机镜像，占用 4 核 CPU 和 4GB 内存，且无法通过常规手段彻底停止。这种失控的 VM 生命周期不仅造成资源浪费，更暴露了 AI 客户端工具在权限边界设计上的深层缺陷。

静默启动的 10GB 虚拟机

Claude Desktop 的 Cowork 功能旨在提供一个隔离的执行环境，让 AI 能够在沙箱中运行代码。然而，这个设计选择带来了意想不到的后果。根据用户报告，Claude 会在 ~/Library/Application Support/Claude/vm_bundles/ 路径下自动创建名为 claudevm.bundle 的虚拟机镜像，其中 rootfs.img 文件轻松突破 10GB，极端情况下甚至达到 21GB。

更令人担忧的是，这个 VM 的创建完全不需要用户显式授权。即使你从未点击过 Cowork 标签页，甚至从未使用过相关功能，虚拟机依然会在后台静默生成。有用户反馈，在完全未启用 Cowork 的情况下，系统仍被占用了超过 10GB 的磁盘空间。

技术架构与资源分配

Cowork VM 基于 Apple 的 Virtualization.framework 构建，采用 EFI/GRUB 启动方式。其资源配置相当激进：

vsock 是一种绕过传统 TCP/IP 协议栈的通信机制，允许宿主机与虚拟机直接通过 hypervisor 交换数据。这种设计虽然降低了通信开销，但也意味着一旦 VM 启动，它就与宿主系统建立了紧密的耦合关系。

Anthropic 工程师 Felix Rieseberg 在 Hacker News 上解释了这一设计的三重考量：提供完全隔离的执行环境、建立比容器更强的安全边界、减少非技术用户的 "授权疲劳"。然而，这种以安全为名的设计，却在资源管控方面制造了新的问题。

无法停止的再生循环

问题的核心在于用户缺乏对 VM 生命周期的控制权。当你尝试删除 VM 文件时，会发现这只是治标不治本 —— 几小时后，Claude Desktop 会自动重新下载并生成整个 10GB 的镜像包。这种 "删除 - 再生" 循环让用户陷入被动。

性能影响同样显著。在 8GB 内存的 Mac 上，Claude Desktop 启动后不久 CPU 占用率就达到 24%，几分钟后攀升至 55%（其中渲染进程 24%、主进程 21%、GPU 7%）。内存压力导致 swap 活动激增，swapins 计数从 20,000 飙升至 24,000 以上，系统明显变得迟缓。

临时解决方案是手动清理缓存目录：

rm -rf ~/Library/Application\ Support/Claude/vm_bundles
rm -rf ~/Library/Application\ Support/Claude/Cache
rm -rf ~/Library/Application\ Support/Claude/Code\ Cache

这可以立即释放约 75% 的系统资源，但效果只能维持几分钟到几小时，之后 VM 会再次自动生成。

安全边界的悖论

Cowork VM 的设计初衷是建立更强的安全隔离，但失控的生命周期管理反而制造了新的安全风险。首先，自动启动机制违背了最小权限原则 —— 一个用户可能永远不需要的功能，却在后台持续消耗计算资源。其次，缺乏显式停止按钮意味着用户无法快速切断潜在的安全事件响应路径。

更严重的是，macOS 26.x 版本还出现了 vsock 连接超时的问题。当 guest_vsock_connect 在 60 秒后超时失败时，启动循环会尝试停止前一个 VM，但停止操作往往失败，导致 vmnet 网关 IP 从 67.1 递增到 68.1、69.1，形成资源泄漏。这意味着每次失败的启动尝试都会留下未完全释放的网络资源，可能被恶意利用或导致系统不稳定。

工程化缓解策略

面对这种失控的 VM 生命周期，用户目前可以采取以下 containment 措施：

监控与告警：定期检查 ~/Library/Application Support/Claude/vm_bundles/ 目录大小，设置磁盘使用阈值告警。监控 ~/Library/Logs/Claude/ 下的 cowork_vm_node.log、cowork_vm_swift.log 和 coworkd.log，关注 VM 启动和连接状态。

进程级限制：使用 launchctl 或类似工具限制 Claude Desktop 进程的资源配额，防止无限制的 CPU / 内存占用。考虑使用 AppArmor 或等效机制约束 VM 进程的权限范围。

网络隔离：在防火墙层面限制 VM 的网络访问权限，防止其通过共享模式访问敏感内网资源。

替代方案：对于不需要图形界面的用户，可以切换到纯命令行的 claude CLI 版本，完全避开 VM 相关问题。

设计层面的反思

GitHub issue #22543 自 2026 年 2 月报告以来已获得 81 个赞同，被标记为 high-priority，但截至 6 月仍未得到官方修复。社区提出的改进建议包括：延迟启动（仅在用户打开 Cowork 标签页时才启动 VM）、增量更新（而非全量重新下载 10GB 镜像）、自定义存储位置、以及最关键的 —— 完全 opt-in 机制，让从未使用 Cowork 的用户可以选择不生成 VM。

这一事件揭示了一个更广泛的 AI 工具设计问题：当客户端软件具备自主启动重量级资源的能力时，必须提供相应的显式控制机制。安全边界不能以牺牲用户控制权为代价。理想的 AI 客户端应该遵循 "默认最小化、显式授权、可彻底停止" 的原则，在提供便利的同时尊重用户对计算资源的最终支配权。

对于企业环境而言，Claude Desktop 的 VM 行为更应引起警惕。在受监管的环境中，未经审计的虚拟机自动启动可能违反合规要求。IT 管理员需要评估是否允许此类软件在终端设备上运行，或考虑将其限制在专门的隔离环境中。

参考来源

• GitHub Issue #22543: Cowork feature creates 10GB VM bundle that severely degrades performance (anthropics/claude-code)
• "Claude Code's Cowork silently creates a 10GB VM on macOS — and 55% CPU even after deletion" (lilting.ch, 2026-03-03)

ai-systems