Anthropic का Cowork फ़ीचर macOS पर बिना चेतावनी 10GB VM bundle बना रहा है

• macOS में Cowork फ़ीचर सक्रिय होने पर, सिस्टम में लगभग 10GB आकार का virtual machine (VM) bundle अपने-आप बन जाता है, जिससे performance तेज़ी से गिरती है
• यह फ़ाइल ~/Library/ के नीचे सेव होती है, और delete करने के बाद भी अगले दिन फिर से बन जाती है
• इसके मौजूद रहने पर CPU उपयोग बढ़ना (24~55%), swap बढ़ना, UI delay जैसी लगातार performance समस्याएँ होती हैं
• अस्थायी समाधान के रूप में VM bundle और cache folder delete करने पर लगभग 75% performance सुधार मिलता है, लेकिन कुछ समय बाद फिर से धीमापन आ जाता है
• कई users ने पारदर्शिता की कमी और storage space की बर्बादी की ओर इशारा करते हुए, VM creation को चुनने का option और पहले से सूचना देने की मांग की

---

समस्या का सार

• Cowork फ़ीचर इस्तेमाल करने के बाद Claude Desktop बहुत धीमा हो जाता है, और startup delay, UI lag, response delay जैसी समस्याएँ आती हैं
• performance गिरावट session के दौरान भी धीरे-धीरे बढ़ती है, और VM bundle फ़ाइल 10GB तक बढ़कर अपने-आप फिर बनती रहती है
• यह समस्या macOS environment (8GB RAM) में reproduce हुई

जाँच के नतीजे

• Cowork फ़ीचर द्वारा बनाया गया VM bundle ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img लोकेशन पर मिलता है
• यह फ़ाइल delete करने पर भी एक दिन के भीतर फिर बन जाती है, और automatic cleanup नहीं होता
• VM bundle और cache delete करने पर storage usage 11GB → 639MB तक घट गया, और काम की speed लगभग 75% बेहतर हुई
• लेकिन restart के कुछ ही मिनटों में CPU usage 24% → 55% तक बढ़ गया, और swapins 20K → 24K+ तक पहुँच गया
• इससे संकेत मिलता है कि performance गिरावट के पीछे memory leak या जमा होता workload हो सकता है

देखे गए व्यवहार

• idle स्थिति में भी CPU usage 24~55%
• swap activity लगातार बढ़ती रहती है, और कुछ मिनटों में performance गिरने लगती है
• हर Cowork session में 10GB VM bundle फिर से बनता है
• cleanup के बाद अस्थायी सुधार (75%), लेकिन समय के साथ फिर गिरावट

अस्थायी समाधान

• Claude Desktop बंद करने के बाद नीचे दिए गए commands से VM और cache delete करें

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

• इस कदम से अस्थायी performance सुधार हो सकता है, लेकिन समय-समय पर restart करना पड़ेगा
• कुछ users ने VM folder permissions को chmod 000 में बदलकर फिर से बनना रोका

यूज़र फ़ीडबैक

• Cowork disabled होने पर भी VM चलती रहती है और memory घेरती है
• कुछ users ने 21GB से बड़े VM bundle भी report किए
• VM app launch पर अपने-आप फिर provision होती है, और compressed file (rootfs.img.zst) भी बची रहती है, जिससे duplicate storage waste होता है
• जिन users ने Cowork कभी इस्तेमाल ही नहीं किया, उन्होंने भी 10GB bundle मिलने और इसे memory leak मानने की बात कही
• limited storage वाले Mac users ने disable option की ज़रूरत पर ज़ोर दिया

पारदर्शिता और भरोसे से जुड़े सवाल

• users ने बिना पहले से बताए 12~20GB disk और 2GB RAM लेने को समस्या बताया
• install के समय या पहली launch पर सूचना, VM pre-download का option, Cowork disable toggle जैसी माँगें सामने आईं
• कुछ लोगों ने कहा कि VM sandboxing design का इरादा समझ में आता है, लेकिन पर्याप्त जानकारी न होना user trust को नुकसान पहुँचाता है
• कई लोगों की राय थी कि “अगर कोई app user को बताए बिना system resources इस्तेमाल करे, तो भरोसा कम होता है”

[GN⁺]

Hacker News की राय

• नमस्ते, मैं Anthropic का Felix हूँ। मैं Claude Cowork और Claude Code पर काम करता हूँ
  Cowork, Linux VM के भीतर चलने वाले Claude Code agent harness पर बना है, और Apple के Virtualization Framework या Microsoft के Host Compute System के ज़रिए चलता है
  इसके तीन कारण हैं
  (1) Claude को उपयोगकर्ता की ओर से स्वतंत्र रूप से कोड लिखने के लिए अलग कंप्यूटर वातावरण देना
  (2) दूसरी sandboxing solutions की तुलना में security boundary की गारंटी अधिक स्पष्ट होना
  (3) non-technical users के लिए अधिक सुरक्षित उपयोग अनुभव देना
  लेकिन हमें पता है कि इसमें trade-off हैं, और हम उन लोगों के लिए सुधार के विचार देख रहे हैं जो Cowork का उपयोग नहीं करना चाहते या VM के बिना इसका इस्तेमाल करना चाहते हैं

  • फ़ीडबैक के तौर पर, अगर Cowork 10GB storage इस्तेमाल करता है तो उसे पहले से उपयोगकर्ता को बताना चाहिए और one-click से delete करने की सुविधा देनी चाहिए
    “approval fatigue” कम करना अल्पकाल में Anthropic के लिए फायदेमंद हो सकता है, लेकिन लंबे समय में उपयोगकर्ताओं के लिए नहीं
    यह pattern स्थायी बनने से पहले इसे रोकना बेहतर होगा
  • अच्छा होगा अगर आधिकारिक या semi-official Claude sandbox के लिए container image दी जाए। Cowork VM को बाहरी तौर पर भी इस्तेमाल किया जा सके तो बेहतर होगा
  • व्याख्या अच्छी है, लेकिन व्यवहार में Cowork के कारण performance गिरने और power consumption बढ़ने की शिकायतें हैं
  • मुझे पता ही नहीं था कि Cowork VM पर चलता है। अगर marketing में इसे साफ़ बताया गया होता, तो शायद मैं इसे बहुत पहले आज़मा चुका होता
  • Claude Desktop से Mac VM (UTM के भीतर) में चलाने की कोशिश करते समय Apple Virtualization Framework से जुड़ी error आई
    लगता है कि यह पहले से VM के भीतर चल रहा था, इसलिए nested virtualization error आई। error message बेहतर होना चाहिए, या अगर पहले से VM के भीतर हो तो Cowork अपना VM न बनाए

• आजकल apps का disk access का दुरुपयोग करना चौंकाने वाला है
  उदाहरण के लिए, Apple Podcasts app बिना किसी वजह 120GB podcast files डाउनलोड कर लेती है और हटाती नहीं। यह “System Data” के रूप में दिख रहा था, इसलिए external drive तक ढूँढनी पड़ी

  • macOS का “System Data” मसला वाकई भयानक है। Docker, music libraries, cache वगैरह की वजह से हर 1~2 साल में clean install करना पड़ता है
  • ~/Library/Messages फ़ोल्डर देखने पर iMessage sync की वजह से 100GB से ज़्यादा space घिरा हुआ मिलता है। ऐसी चीज़ों को cloud में offload करना चाहिए
  • 5G के दौर में भी audio files को default रूप से डाउनलोड करना समझ से बाहर है। streaming काफ़ी है
  • Time Machine backup समस्या की वजह से मेरे 512GB में से 300GB “System Data” के रूप में दिखे, और मेरा एक दिन का काम चला गया
  • ऐसी समस्याओं को सुलझाने के लिए मैं Mole जैसे tools का उपयोग करता हूँ। साथ ही warp/gemini CLI से बेकार cache ढूँढकर हटाता हूँ

• मैं इस समय “vibe coding” के आशीर्वाद और अभिशाप दोनों महसूस कर रहा हूँ। सचमुच यह वाइब कोडिंग की दोधारी प्रकृति है

• VM sandbox, Cowork का मूल हिस्सा है। code generation feature को सुरक्षित रूप से देने के लिए isolated environment ज़रूरी है
  मैं ऐसा UI सुझाता हूँ जिसमें उपयोगकर्ता केवल कुछ folders की access permission दें, और write permission चाहिए होने पर warning दिखाई जाए

• सच कहें तो LLM के बिना भी development VM के भीतर करना बेहतर है
  Vagrant जैसे tools आज भी उपयोगी हैं
  Cowork का मुख्य target non-developers हैं, इसलिए इसे कोड लिखने वाले assistant AI की तरह देखना सही है
  experts अलग Mac Mini पर काम कर सकते हैं, लेकिन आम उपयोगकर्ताओं के लिए यह संभव नहीं, इसलिए VM एक व्यावहारिक समाधान है

  • आजकल कई VPS providers हैं, इसलिए exe.dev, sprites.dev, shellbox.dev जैसी जगहों पर आसानी से environment बनाया जा सकता है
  • मैं जटिल projects के लिए devcontainer पसंद करता हूँ। Docker और NixOS का उपयोग करके अधिक हल्का और flexible development environment बनाया जा सकता है
  • macOS पर Lima सबसे अच्छा विकल्प रहा है। Claude Code को image के रूप में रखकर केवल ज़रूरी directories mount की जाती हैं। यह Vagrant की तुलना में काफ़ी स्मूद चलता है
  • यहाँ तक कि मज़ाक में यह भी कहा गया, “तो क्या programming करते समय भी condom इस्तेमाल करते हो?”, यानी security को लेकर जुनून कुछ ज़्यादा ही है

• सुना है कि Anthropic के कर्मचारी Claude Code से Claude Code ही बना रहे हैं
  AI से product completeness बढ़ती है, लेकिन quality गिरना समस्या है। अंततः फिर skilled developers की ज़रूरत पड़ेगी
  शुरुआती users पर मानो test subjects की तरह product को परखने की ज़िम्मेदारी आ जाती है

  • संदेह है कि ऐसे 1st party products open source से प्रतिस्पर्धा कर पाएँगे या नहीं। जब मुफ्त और बेहतर alternatives मौजूद हैं, तो इसे इस्तेमाल करने की वजह कम है
  • Anthropic के अंदर की quality problems देखकर लगता है कि अधिकांश कर्मचारी junior से भी नीचे के स्तर के हैं। Bun team शायद एक अपवाद हो सकती है

• पिछले 30 मिनट से DaisyDisk से अपने laptop की सफ़ाई करते हुए मुझे Cowork का 10GB VM मिला
  apps अक्सर बेवजह storage घेर लेते हैं, और cleanup features लगभग नहीं होते
  Xcode भी लंबे समय से न चलाने के बावजूद कई OS के SDKs और simulators संभालकर रखता है

  • ऐसी समस्या के लिए DevCleaner इस्तेमाल किया जा सकता है
  • macOS में crond और find होने के बावजूद यह समझ नहीं आता कि ऐसी cleanup tasks को automate क्यों नहीं किया जाता

• क्योंकि Cowork Apple Virtualization Framework का उपयोग करता है, इसलिए nested VM error आती है
  इससे feature limitations, space waste, और latency पैदा होती है। OpenAI का इस्तेमाल किया जाने वाला Seatbelt sandbox बेहतर विकल्प हो सकता है
  संबंधित लिंक

  • लेकिन मुझे लगता है कि Seatbelt लगभग बेकार है। सवाल यह है कि Cowork को VM के भीतर चलाने की ज़रूरत ही क्यों है? क्या इसका अपना VM काफ़ी नहीं है?
  • ऊपर से Seatbelt की documentation लगभग न के बराबर है

• यह असुविधाजनक ज़रूर है, लेकिन ऐसा sandbox approach ही agentic tools का असली स्वभाव है
  built-in sandbox के बिना चलने वाले tools कभी न कभी data loss का कारण बनेंगे

• शायद Anthropic के भीतर किसी ने “app performance improve करो” वाला prompt डाला, और नतीजा यही निकला