2 points par GN⁺ 2026-03-03 | 1 commentaires | Partager sur WhatsApp
  • Lorsque la fonctionnalité Cowork est activée sur macOS, un bundle de machine virtuelle (VM) d’environ 10 Go est automatiquement créé sur le système, ce qui provoque une forte baisse des performances
  • Ce fichier est stocké sous ~/Library/ et, même après suppression, il est recréé le lendemain
  • Sa présence entraîne une hausse de l’utilisation CPU (24 à 55 %), une augmentation du swap et des ralentissements de l’interface, soit une dégradation continue des performances
  • Comme solution temporaire, supprimer le bundle VM et les dossiers de cache apporte environ 75 % d’amélioration des performances, mais le système redevient lent avec le temps
  • Plusieurs utilisateurs dénoncent le manque de transparence et le gaspillage d’espace disque, et demandent un réglage pour choisir si la VM doit être créée ainsi qu’une information préalable

Aperçu du problème

  • Après utilisation de la fonctionnalité Cowork, Claude Desktop devient très lent, avec délai au démarrage, lags de l’interface et latence de réponse
  • La dégradation des performances s’aggrave progressivement même pendant une session, et le fichier bundle VM grossit jusqu’à 10 Go puis est recréé automatiquement
  • Le problème est reproductible dans un environnement macOS (8 Go de RAM)

Résultats de l’enquête

  • Le bundle VM créé par la fonctionnalité Cowork se trouve à l’emplacement ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img
  • Même après suppression, ce fichier est recréé dans la journée, sans nettoyage automatique (cleanup)
  • Après suppression du bundle VM et du cache, l’espace occupé passe de 11 Go à 639 Mo, et la vitesse de travail s’améliore d’environ 75 %
  • Cependant, quelques minutes après redémarrage, l’utilisation CPU passe de 24 % à 55 %, et les swapins augmentent de 20K à plus de 24K
  • Cela suggère une possible dégradation des performances due à une fuite mémoire ou une charge de travail cumulative

Comportements observés

  • Utilisation CPU de 24 à 55 % même au repos
  • Augmentation continue de l’activité de swap, avec dégradation des performances en quelques minutes
  • Recréation d’un bundle VM de 10 Go à chaque session Cowork
  • Amélioration temporaire après nettoyage (75 %), puis nouvelle dégradation avec le temps

Solution temporaire

  • Après avoir quitté Claude Desktop, supprimer la VM et le cache avec les commandes suivantes
    rm -rf ~/Library/Application\ Support/Claude/vm_bundles  
    rm -rf ~/Library/Application\ Support/Claude/Cache  
    rm -rf ~/Library/Application\ Support/Claude/Code\ Cache  
    
  • Cette mesure peut apporter une amélioration temporaire des performances, mais un redémarrage périodique reste nécessaire
  • Certains utilisateurs modifient les permissions du dossier VM en chmod 000 pour empêcher sa recréation

Retours des utilisateurs

  • Même lorsque Cowork est désactivé, la VM s’exécute et occupe de la mémoire
  • Certains utilisateurs signalent aussi des bundles VM ayant dépassé 21 Go
  • La VM est automatiquement reprovisionnée au lancement de l’application, et même le fichier compressé (rootfs.img.zst) reste présent, ce qui duplique inutilement l’espace de stockage
  • Des utilisateurs n’ayant jamais utilisé Cowork ont eux aussi découvert un bundle de 10 Go, qu’ils interprètent comme une fuite mémoire
  • Les utilisateurs de Mac avec un espace de stockage limité insistent sur la nécessité d’une option de désactivation

Questions de transparence et de confiance

  • Les utilisateurs pointent le fait que l’application occupe 12 à 20 Go de disque et 2 Go de RAM sans avertissement préalable
  • Ils proposent notamment une information lors de l’installation ou au premier lancement, un choix quant au pré-téléchargement de la VM et un interrupteur pour désactiver Cowork
  • Certains disent comprendre l’intention derrière l’architecture de sandboxing par VM, mais estiment que le manque d’explications nuit à la confiance des utilisateurs
  • Beaucoup partagent l’avis suivant : « Quand une application utilise les ressources système à l’insu de l’utilisateur, cela érode la confiance »

1 commentaires

 
GN⁺ 2026-03-03
Commentaires sur Hacker News
  • Bonjour, ici Felix d’Anthropic. Je m’occupe de Claude Cowork et de Claude Code
    Cowork est construit sur un harnais d’agent Claude Code fonctionnant dans une VM Linux, et s’exécute via l’Apple Virtualization Framework ou le Host Compute System de Microsoft
    Il y a trois raisons à cela
    (1) fournir à Claude un environnement informatique isolé pour qu’il puisse écrire librement du code au nom de l’utilisateur
    (2) offrir une garantie de frontière de sécurité plus solide que d’autres solutions de sandboxing
    (3) proposer une expérience plus sûre aux utilisateurs non techniques
    Cela dit, nous savons qu’il y a des compromis, et nous étudions des idées d’amélioration pour les personnes qui ne veulent pas utiliser Cowork ou qui souhaitent l’utiliser sans VM

    • Pour donner un retour, si Cowork utilise 10 Go de stockage, il faut prévenir l’utilisateur à l’avance et permettre une suppression en un clic
      Réduire la « fatigue d’approbation » n’est avantageux pour Anthropic qu’à court terme, mais ce n’est pas bénéfique pour l’utilisateur sur le long terme
      Il vaudrait mieux arrêter ce genre de pratique avant qu’elle ne s’installe
    • J’aimerais qu’ils fournissent une image de conteneur officielle ou semi-officielle pour le sandbox Claude. Ce serait bien de pouvoir utiliser la VM Cowork ailleurs aussi
    • L’explication est excellente, mais en pratique certains se plaignent que Cowork dégrade les performances et augmente la consommation d’énergie
    • Je ne savais pas que Cowork tournait sur une VM. Si le marketing l’avait dit clairement, je l’aurais probablement essayé bien plus tôt
    • J’ai essayé de l’exécuter depuis Claude Desktop vers une VM Mac (dans UTM), et j’ai rencontré une erreur liée à l’Apple Virtualization Framework
      Comme j’étais déjà dans une VM, cela semble être une erreur de virtualisation imbriquée. Il vaudrait mieux améliorer le message d’erreur ou faire en sorte que Cowork n’utilise pas sa propre VM lorsqu’il détecte qu’il tourne déjà dans une VM
  • C’est étonnant de voir à quel point les applis abusent aujourd’hui de l’accès au disque
    Par exemple, l’app Apple Podcasts télécharge 120 Go de fichiers de podcasts sans raison et ne les supprime pas. Ils apparaissaient comme « System Data », et j’ai dû chercher sur un disque externe

    • Le problème de « System Data » sur macOS est vraiment affreux. Entre Docker, la bibliothèque musicale, les caches, etc., on doit faire une réinstallation propre tous les 1 à 2 ans
    • Si on regarde le dossier ~/Library/Messages, la synchronisation iMessage peut y occuper plus de 100 Go. Ce genre de données devrait être déporté vers le cloud
    • Même à l’ère de la 5G, je ne comprends pas pourquoi les fichiers audio sont encore téléchargés par défaut. Le streaming suffit largement
    • Moi aussi, à cause d’un problème de sauvegarde Time Machine, 300 Go sur 512 Go apparaissaient comme « System Data », et j’ai perdu une journée de travail
    • Pour résoudre ce type de problème, j’utilise des outils comme Mole. J’utilise aussi warp/gemini CLI pour repérer et supprimer les caches inutiles
  • Je ressens à la fois les bénédictions et les malédictions du « vibe coding ». C’est vraiment la double face du coding à l’instinct

  • Le sandbox VM est au cœur de Cowork. Pour offrir une génération de code de façon sûre, un environnement isolé est indispensable
    Je proposerais une interface qui permette à l’utilisateur de n’accorder l’accès qu’à certains dossiers, avec un avertissement si des droits d’écriture sont nécessaires

  • En réalité, même sans LLM, il vaut mieux développer dans une VM
    Des outils comme Vagrant restent utiles
    La cible principale de Cowork, ce sont les non-développeurs, et il est logique de l’aborder comme une IA assistante qui écrit du code
    Les experts travaillent sur un Mac Mini séparé, mais l’utilisateur ordinaire ne peut pas faire ça, donc la VM est une solution réaliste

    • Aujourd’hui, il existe beaucoup de fournisseurs VPS, et on peut facilement monter un environnement sur des services comme exe.dev, sprites.dev, shellbox.dev
    • Pour les projets complexes, je préfère les devcontainers. Avec Docker et NixOS, on peut créer un environnement de développement plus léger et plus flexible
    • Sur macOS, Lima a été le meilleur choix pour moi. J’y mets Claude Code dans une image et je ne monte que les répertoires nécessaires. Cela fonctionne bien plus proprement que Vagrant
    • Certains ont même lancé la blague « alors tu mets aussi un préservatif quand tu programmes ? », en réaction à ce qu’ils voient comme une obsession excessive pour la sécurité
  • J’ai entendu dire que les employés d’Anthropic développent Claude Code avec Claude Code
    L’IA améliore la finition du produit, mais la baisse de qualité pose problème. Au final, il faudra de nouveau des développeurs expérimentés
    Les premiers utilisateurs ont la responsabilité de tester le produit comme des cobayes

    • Je me demande si ces produits 1st party peuvent vraiment rivaliser avec l’open source. Quand il existe des alternatives gratuites et meilleures, il n’y a pas vraiment de raison de les utiliser
    • Quand on voit les problèmes de qualité chez Anthropic, on a l’impression que la plupart des employés sont au niveau junior ou en dessous. L’équipe de Bun semble être la seule exception
  • Au cours des 30 dernières minutes, je faisais le ménage sur mon laptop avec DaisyDisk quand j’ai découvert la VM de 10 Go de Cowork
    Beaucoup d’apps occupent inutilement de l’espace de stockage, et elles ont rarement de vraies fonctions de nettoyage
    Xcode aussi conserve des SDK et des simulateurs pour plusieurs OS, même quand il n’a pas été lancé depuis longtemps

    • Pour régler ce problème, on peut utiliser DevCleaner
    • Avec crond et find déjà présents sur macOS, je me demande pourquoi ce genre de nettoyage n’est pas automatisé
  • Comme Cowork utilise l’Apple Virtualization Framework, cela provoque des erreurs de VM imbriquée
    Cela entraîne des limitations fonctionnelles, du gaspillage d’espace et de la latence. Le sandbox Seatbelt utilisé par OpenAI pourrait être une meilleure alternative
    Lien connexe

    • Mais je pense que Seatbelt est presque inutile. Je me demande pourquoi on voudrait exécuter Cowork dans une VM. Sa propre VM ne suffit-elle pas ?
    • En plus, Seatbelt est très peu documenté
  • C’est contraignant, mais ce genre de sandbox est justement l’essence des outils agentiques
    Un outil exécuté sans sandbox intégré finira un jour par provoquer une perte de données

  • On dirait probablement qu’en interne chez Anthropic, quelqu’un a lancé un prompt du genre « améliorez les performances de l’app », et que cela a donné ce résultat