上周，一位程序员在使用 MacBook 时，发现电脑突然变得异常卡顿，检查发现一个 10 GB 的虚拟机文件静静躺在系统目录中，而他从未主动使用过相关功能。这并非个例——许多用户在安装 Anthropic 的 Claude 桌面应用后，都遇到了类似的资源占用问题。Anthropic 是一家专注于 AI 安全的公司，其 Claude 系列模型广受好评，但最近其桌面应用中的 Cowork 功能却引发了不少争议。

什么是 Cowork 功能？

Cowork 是 Claude 桌面应用的一项核心功能，旨在为用户提供安全的代码生成环境。当用户需要让 AI 协助编写代码时，Cowork 会在后台自动创建一个隔离的虚拟机（VM），确保 AI 不会直接访问用户主机系统的敏感文件。这个设计初衷很明确：避免 AI 在生成代码时意外修改用户文件，或执行恶意操作。对于非技术用户来说，这种「无感安全」确实能减少「审批疲劳」——不需要每次操作都手动确认权限，AI 就能直接执行任务。

但问题在于，这个 VM 的体积庞大且难以控制。根据 GitHub issue #22543 的用户报告，该功能会在 ~/Library/Application Support/Claude/vm_bundles/ 目录下生成一个名为 rootfs.img 的 10 GB 文件。更令人惊讶的是，即使用户从未启用过 Cowork，这个文件也会自动创建并持续占用资源。一位用户在评论中吐槽：「我从未使用过 Cowork，却删掉了一个 10 GB 的 bundle。这简直是明显的内存泄漏。」

资源消耗的真相

这个 10 GB 的 VM 并非静态文件。它会随使用时间增长，部分用户报告其体积甚至达到 21.47 GB。当它运行时，系统 CPU 占用率飙升，swap 活动显著增加，导致电脑卡顿。一位 macOS 8 GB 内存用户描述：「清理相关目录后，性能提升 75%，但几分钟内又开始变慢。」更糟的是，这个 VM 在 Windows 系统上同样存在，路径为 %AppData%\Claude\vm_bundles。

为什么需要这么大？Anthropic 工程师 Felix Rieseberg 在 Hacker News 讨论 中解释，使用 VM 的核心原因有三点：一是为 AI 提供独立的计算环境，避免直接操作用户主机；二是通过 Apple Virtualization Framework 或 Microsoft Host Compute System 实现更强的安全边界；三是减少非技术用户的「审批疲劳」。「不需每次确认权限是价值所在。」他写道。

但用户反馈显示，这些设计考量与实际体验严重脱节。一位用户尖锐指出：「当用户发现 Claude Desktop 悄悄消耗 12–20 GB 磁盘空间和 2 GB 内存时，这比审批提示更破坏信任。」另一位开发者补充：「即使关闭 Cowork，VM 仍在后台运行——这完全违背了『按需启动』的基本原则。」

沙箱技术的取舍

技术层面，为什么不用更轻量的沙箱方案？例如，OpenAI 的 Codex CLI 使用了 Apple 的 Seatbelt 机制，但该机制文档稀少且已弃用。Felix 在讨论中提到，现有沙箱方案无法提供足够的安全保证。「其他方案满足不了我们的安全需求。」他解释道。

但用户并不买账。一位开发者指出：「Seatbelt 虽然不完善，但至少不会占用 10 GB 空间。」另一位则调侃：「如果 AI 能写代码，为什么不能写个更小的沙箱？」技术社区的讨论显示，虚拟化技术本身并非问题——微虚拟机（microVMs）在 AWS Lambda 中表现高效，而 Podman 等工具对 VM 的管理更为透明。问题在于 Anthropic 的实现缺乏灵活性：无法选择存储位置、无法动态调整大小、甚至没有禁用选项。

这让人联想到操作系统层面的类似问题。Apple Podcasts 曾自动下载 120 GB 数据却无法清理，系统快照也常被标记为「神秘的 System Data」。一位用户吐槽：「macOS 把存储空间当黑盒，用户需要弯腰才能清理。」这种设计哲学与 Cowork 的问题本质相同：技术决策以厂商便利为先，而非用户知情权。

用户的自救与改进建议

面对现状，用户只能自行解决。常见方案包括手动删除 VM 文件、设置权限阻止再生（如 chmod 000 ~/Library/Application\ Support/Claude/vm_bundles/），或通过修改配置文件禁用 Cowork（macOS 中在 claude_desktop_config.json 添加 "secureVmFeaturesEnabled":false，Windows 中修改注册表）。一位用户甚至分享：「关闭 Claude 后，用 chmod 000 锁定该目录，它就再也没回来过。」

社区也提出了具体改进建议：

• 安装时明确告知 VM 大小和资源需求
• 提供「预下载 VM」的开关选项
• 允许将 VM 存储到外部磁盘
• 增加内置清理工具和监控界面

「低摩擦体验很重要，但透明度同样重要。」一位社会科学家用户在讨论中写道，「用户理解为什么需要 VM 后，更可能接受资源占用，而不是发现它在后台偷偷运行。」这其实呼应了技术界的经典矛盾：安全与易用性往往需要权衡，但权衡的边界不该由厂商单方面决定。

未来的方向

随着 AI 工具深入日常开发，这类问题只会增多。ChatGPT 的代码执行容器曾被曝占用 56 个 CPU 核心，而其他 AI 应用也常在后台默默消耗资源。技术社区的共识是：AI 工具的资源管理必须可观察、可控制。例如，Docker 的容器化方案通过 cgroups 实现精细的资源隔离，而 NixOS 等系统则用声明式配置避免「垃圾文件」堆积。

Anthropic 目前仍在修复中，但用户反馈已推动一些变化。部分版本开始提供更清晰的错误提示，例如在嵌套虚拟化场景（如在 UTM 中运行）时明确报错。不过，根本问题仍未解决——用户仍需手动清理，且无官方禁用选项。一位开发者总结：「当 AI 工具开始占用你的硬盘，却拒绝告诉你原因时，这已不是技术问题，而是信任问题。」

在 AI 普及的时代，技术公司需要重新思考：安全不是单向的「保护」，而是与用户的共同责任。当 10 GB 的虚拟机悄然占据你的存储空间，或许该问的不是「为什么需要这么大」，而是「为什么不能由你来决定」。