Anthropic-Cowork-Funktion erstellt unter macOS ohne Warnung ein 10-GB-VM-Bundle

 (github.com/anthropics)
2 Punkte von GN⁺ 2026-03-03 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn die Cowork-Funktion unter macOS aktiviert wird, wird automatisch ein etwa 10 GB großes Virtual-Machine-(VM-)Bundle auf dem System erstellt, was zu einem starken Leistungseinbruch führt
  • Diese Datei wird unter ~/Library/ gespeichert und am nächsten Tag erneut erstellt, selbst wenn sie gelöscht wurde
  • Ist sie vorhanden, kommt es zu anhaltenden Leistungseinbußen wie höherer CPU-Auslastung (24–55 %), mehr Swap-Nutzung und UI-Verzögerungen
  • Als vorläufige Lösung bringt das Löschen des VM-Bundles und der Cache-Ordner eine Leistungsverbesserung von etwa 75 %, doch mit der Zeit wird das System wieder langsamer
  • Mehrere Nutzer kritisieren mangelnde Transparenz und verschwendeten Speicherplatz und fordern eine Einstellung zur Wahl, ob die VM erstellt werden soll, sowie eine vorherige Benachrichtigung

Problemübersicht

  • Nach der Nutzung der Cowork-Funktion wird Claude Desktop sehr langsam, mit Startverzögerungen, UI-Lags und träger Reaktion
  • Die Leistung verschlechtert sich auch während einer Sitzung zunehmend, und die VM-Bundle-Datei wächst auf bis zu 10 GB an und wird automatisch neu erstellt
  • Das Problem lässt sich in einer macOS-Umgebung (8 GB RAM) reproduzieren

Untersuchungsergebnisse

  • Das von der Cowork-Funktion erstellte VM-Bundle befindet sich unter ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img
  • Selbst wenn diese Datei gelöscht wird, wird sie innerhalb eines Tages erneut erstellt, und es findet keine automatische Bereinigung (Cleanup) statt
  • Nach dem Löschen von VM-Bundle und Cache sinkt der belegte Speicherplatz von 11 GB auf 639 MB, und die Arbeitsgeschwindigkeit verbessert sich um etwa 75 %
  • Nach einem Neustart steigt die CPU-Auslastung jedoch innerhalb weniger Minuten von 24 % auf 55 %, und swapins nehmen von 20K auf 24K+ zu
  • Das deutet auf mögliche Leistungseinbußen durch ein Memory Leak oder kumulierte Arbeitslast hin

Beobachtetes Verhalten

  • 24–55 % CPU-Auslastung selbst im Leerlauf
  • Kontinuierlich zunehmende Swap-Aktivität, Leistungseinbruch innerhalb weniger Minuten
  • Neuerstellung eines 10-GB-VM-Bundles bei jeder Cowork-Sitzung
  • Vorübergehende Verbesserung nach dem Bereinigen (75 %), danach mit der Zeit erneute Verschlechterung

Vorläufige Lösung

  • Nach dem Beenden von Claude Desktop lassen sich VM und Cache mit den folgenden Befehlen löschen 
    rm -rf ~/Library/Application\ Support/Claude/vm_bundles  
rm -rf ~/Library/Application\ Support/Claude/Cache  
rm -rf ~/Library/Application\ Support/Claude/Code\ Cache
  • Diese Maßnahme kann die Leistung vorübergehend verbessern, erfordert jedoch regelmäßige Neustarts
  • Einige Nutzer ändern die Berechtigungen des VM-Ordners auf chmod 000, um die Neuerstellung zu verhindern

Nutzerfeedback

  • Auch bei deaktivierter Cowork-Funktion läuft die VM weiter und belegt Speicher
  • Einige Nutzer berichten von VM-Bundles, die auf mehr als 21 GB angewachsen sind
  • Die VM wird beim Start der App automatisch neu bereitgestellt, und sogar die komprimierte Datei (rootfs.img.zst) bleibt erhalten, was zu doppelter Speicherplatzverschwendung führt
  • Auch Nutzer, die Cowork nie verwendet haben, fanden ein 10-GB-Bundle und halten dies für ein Memory Leak
  • Mac-Nutzer mit begrenztem Speicherplatz betonen die Notwendigkeit einer Deaktivierungsoption

Bedenken zu Transparenz und Vertrauen

  • Nutzer kritisieren, dass ohne vorherige Ankündigung 12–20 GB Festplattenspeicher und 2 GB RAM belegt werden
  • Vorgeschlagen werden eine Hinweismeldung bei Installation oder erstem Start, eine Wahlmöglichkeit für den Vorab-Download der VM sowie ein Schalter zum Deaktivieren von Cowork
  • Einige sagen, sie verstünden zwar die Absicht des VM-Sandboxing-Designs, aber der Mangel an Erklärung schade dem Vertrauen der Nutzer
  • Viele vertreten die Ansicht: „Wenn eine App ohne Wissen des Nutzers Systemressourcen verwendet, untergräbt das das Vertrauen.“

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-03
Hacker-News-Kommentare

  • Hallo, hier ist Felix von Anthropic. Ich bin für Claude Cowork und Claude Code zuständig
    Cowork ist auf dem Agent-Harness von Claude Code aufgebaut, das in einer Linux-VM läuft, und wird über Apples Virtualization Framework oder Microsofts Host Compute System ausgeführt
    Dafür gibt es drei Gründe
    (1) um Claude eine isolierte Computerumgebung bereitzustellen, in der es im Namen des Nutzers frei Code schreiben kann
    (2) weil dadurch Sicherheitsgrenzen zuverlässiger gewährleistet werden als bei anderen Sandboxing-Lösungen
    (3) um technisch weniger versierten Nutzern ein sichereres Nutzungserlebnis zu bieten
    Wir wissen aber, dass es dabei Trade-offs gibt, und prüfen Verbesserungen für Menschen, die Cowork nicht nutzen oder es ohne VM verwenden möchten

    • Als Feedback: Wenn Cowork 10 GB Speicherplatz belegt, sollte der Nutzer vorher informiert werden und es sollte sich mit einem Klick löschen lassen
      „Approval Fatigue“ zu verringern ist kurzfristig vielleicht gut für Anthropic, langfristig aber nicht im Interesse der Nutzer
      Es wäre besser, dieses Muster zu stoppen, bevor es sich verfestigt
    • Ich hätte gern ein offizielles oder halboffizielles Container-Image für die Claude-Sandbox. Es wäre gut, wenn sich die Cowork-VM auch extern nutzen ließe
    • Die Erklärung ist hervorragend, aber in der Praxis gibt es Beschwerden, dass Cowork Leistungseinbußen und höheren Stromverbrauch verursacht
    • Ich wusste nicht, dass Cowork auf einer VM läuft. Wenn das im Marketing klar kommuniziert worden wäre, hätte ich es viel früher ausprobiert
    • Ich habe versucht, Claude Desktop in einer Mac-VM (innerhalb von UTM) auszuführen, und bekam einen Fehler im Zusammenhang mit Apples Virtualization Framework
      Da es bereits innerhalb einer VM lief, war es vermutlich ein Nested-Virtualization-Fehler. Es wäre gut, die Fehlermeldung zu verbessern oder Cowork seine eigene VM überspringen zu lassen, wenn es bereits in einer VM läuft

  • Es ist erstaunlich, wie stark Apps heutzutage den Festplattenzugriff missbrauchen
    Zum Beispiel lädt Apple Podcasts ohne ersichtlichen Grund 120 GB an Podcast-Dateien herunter und löscht sie nicht. Das wurde als „System Data“ angezeigt, sodass ich auf externen Laufwerken nachsehen musste

    • Das Problem mit „System Data“ unter macOS ist wirklich furchtbar. Wegen Docker, Musikbibliotheken, Caches usw. muss ich alle ein bis zwei Jahre eine Neuinstallation machen
    • Im Ordner ~/Library/Messages sieht man, dass durch die iMessage-Synchronisierung mehr als 100 GB belegt sind. Solche Daten sollten in die Cloud ausgelagert werden
    • Wir leben im 5G-Zeitalter, und trotzdem werden Audiodateien noch immer standardmäßig heruntergeladen. Das ist für mich unverständlich. Streaming reicht völlig
    • Ich habe wegen eines Time-Machine-Backup-Problems auf einem 512-GB-Laufwerk 300 GB als „System Data“ angezeigt bekommen und dadurch die Arbeit eines ganzen Tages verloren
    • Um solche Probleme zu lösen, nutze ich Tools wie Mole. Außerdem finde und lösche ich unnötige Caches mit warp/gemini CLI

  • Ich erlebe gerade zugleich den Segen und den Fluch von „vibe coding“. Das ist wirklich die Doppelseitigkeit des Vibe Codings

  • Die VM-Sandbox ist der Kern von Cowork. Um Codegenerierung sicher anzubieten, ist eine isolierte Umgebung unverzichtbar
    Ich schlage eine UI vor, in der Nutzer nur bestimmten Ordnern Zugriff geben und bei benötigten Schreibrechten eine Warnung sehen

  • Eigentlich ist es auch ohne LLM besser, Entwicklung in einer VM zu machen
    Tools wie Vagrant sind nach wie vor nützlich
    Die Hauptzielgruppe von Cowork sind Nicht-Entwickler, und es ist sinnvoll, es als assistenzartige KI, die Code schreibt, zu betrachten
    Profis arbeiten auf einem separaten Mac Mini, aber normale Nutzer können das nicht, daher ist eine VM eine realistische Lösung

    • Heutzutage gibt es viele VPS-Anbieter, und bei exe.dev, sprites.dev, shellbox.dev und ähnlichen Diensten kann man leicht Umgebungen aufsetzen
    • Für komplexe Projekte bevorzuge ich devcontainer. Mit Docker und NixOS lassen sich leichtere und flexiblere Entwicklungsumgebungen bauen
    • Unter macOS war Lima für mich die beste Wahl. Ich halte Claude Code als Image vor und mounte nur die benötigten Verzeichnisse. Das funktioniert deutlich reibungsloser als Vagrant
    • Es gab sogar die spöttische Reaktion: „Benutzt du dann auch ein Kondom beim Programmieren?“, so übertrieben erschien manchen diese Sicherheitsfixierung

  • Ich habe gehört, dass Anthropic-Mitarbeiter Claude Code mit Claude Code entwickeln
    KI steigert zwar die Produktreife, aber Qualitätsverlust ist ein Problem. Am Ende werden wieder erfahrene Entwickler gebraucht
    Frühe Nutzer tragen die Verantwortung, das Produkt praktisch wie Versuchskaninchen zu testen

    • Ich frage mich, ob solche 1st-Party-Produkte überhaupt mit Open Source konkurrieren können. Wenn es kostenlose und bessere Alternativen gibt, gibt es keinen besonderen Grund, sie zu verwenden
    • Wenn man sich die Qualitätsprobleme bei Anthropic ansieht, wirkt es, als läge das Niveau der meisten Mitarbeiter auf Junior-Level oder darunter. Nur das Bun-Team scheint eine Ausnahme zu sein

  • Ich habe in den letzten 30 Minuten mit DaisyDisk mein Notebook aufgeräumt und dabei die 10-GB-VM von Cowork entdeckt
    Apps belegen oft unnötig Speicherplatz, und Aufräumfunktionen gibt es kaum
    Auch Xcode bewahrt weiterhin SDKs und Simulatoren für verschiedene OS-Versionen auf, obwohl ich es lange nicht gestartet habe

    • Um solche Probleme zu lösen, kann man DevCleaner verwenden
    • macOS hat doch crond und find — warum werden solche Aufräumarbeiten nicht automatisiert?

  • Weil Cowork Apples Virtualization Framework nutzt, kommt es zu Nested-VM-Fehlern
    Das bringt Funktionseinschränkungen, Platzverschwendung und Latenz mit sich. Die von OpenAI verwendete Seatbelt-Sandbox könnte eine bessere Alternative sein
    Verwandter Link

    • Ich halte Seatbelt allerdings für nahezu nutzlos. Ich frage mich, warum man Cowork überhaupt innerhalb einer VM ausführen will. Reicht eine eigene VM nicht aus?
    • Außerdem ist Seatbelt kaum dokumentiert

  • Es ist zwar unbequem, aber genau diese Art von Sandbox ist das Wesen agentischer Tools
    Werkzeuge, die ohne eingebaute Sandbox laufen, werden irgendwann Datenverlust verursachen

  • Vermutlich hat man intern bei Anthropic einfach den Prompt „App-Performance verbessern“ eingegeben, und das ist dabei herausgekommen