2 คะแนน โดย GN⁺ 2026-03-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อเปิดใช้งาน ฟีเจอร์ Cowork บน macOS ระบบจะสร้าง virtual machine (VM) bundle ขนาดราว 10GB โดยอัตโนมัติ ทำให้ประสิทธิภาพลดลงอย่างมาก
  • ไฟล์นี้ถูกเก็บไว้ใต้ ~/Library/ และแม้จะลบออกแล้วก็จะ ถูกสร้างขึ้นใหม่อีกในวันถัดไป
  • เมื่อมีไฟล์นี้ จะเกิดอาการประสิทธิภาพลดลงต่อเนื่อง เช่น การใช้ CPU สูงขึ้น (24~55%), swap เพิ่มขึ้น, UI หน่วง
  • วิธีแก้ชั่วคราวคือการลบ VM bundle และโฟลเดอร์แคช ซึ่งช่วย ปรับปรุงประสิทธิภาพได้ราว 75% แต่เมื่อเวลาผ่านไปก็จะช้าลงอีก
  • ผู้ใช้หลายรายชี้ให้เห็นถึง การขาดความโปร่งใสและการสิ้นเปลืองพื้นที่จัดเก็บ พร้อมเรียกร้องให้มีการตั้งค่าเพื่อเลือกว่าจะสร้าง VM หรือไม่ และมีการแจ้งล่วงหน้า

ภาพรวมของปัญหา

  • หลังใช้ฟีเจอร์ Cowork แล้ว Claude Desktop ช้ามาก และเกิดอาการเริ่มต้นช้า, UI กระตุก, การตอบสนองล่าช้า
  • ประสิทธิภาพลดลงจะค่อย ๆ รุนแรงขึ้นระหว่างเซสชัน และ ไฟล์ VM bundle ขยายได้ถึง 10GB พร้อมถูกสร้างใหม่อัตโนมัติ
  • ปัญหานี้สามารถเกิดซ้ำได้บน macOS (RAM 8GB)

ผลการตรวจสอบ

  • VM bundle ที่ฟีเจอร์ Cowork สร้างอยู่ที่ ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img
  • แม้จะลบไฟล์นี้แล้ว ก็จะถูกสร้างใหม่ภายในหนึ่งวัน และไม่มี การล้างข้อมูลอัตโนมัติ (cleanup)
  • เมื่อลบ VM bundle และแคช พื้นที่จัดเก็บจะลดจาก 11GB → 639MB และ ความเร็วในการทำงานดีขึ้นราว 75%
  • อย่างไรก็ตาม หลังรีสตาร์ตเพียงไม่กี่นาที การใช้ CPU จะเพิ่มจาก 24% → 55% และ swapins 20K → 24K+
  • สิ่งนี้บ่งชี้ว่าอาจมี memory leak หรือภาระงานสะสม ที่ทำให้ประสิทธิภาพลดลง

พฤติกรรมที่สังเกตได้

  • การใช้ CPU 24~55% แม้ขณะ idle
  • กิจกรรม swap เพิ่มขึ้นต่อเนื่อง และประสิทธิภาพตกลงภายในไม่กี่นาที
  • มีการสร้าง VM bundle ขนาด 10GB ใหม่ทุกเซสชันของ Cowork
  • ดีขึ้นชั่วคราวหลังล้างข้อมูล (75%) แต่เมื่อเวลาผ่านไปก็กลับมาลดลงอีก

วิธีแก้ชั่วคราว

  • ปิด Claude Desktop แล้วลบ VM และแคชด้วยคำสั่งต่อไปนี้
    rm -rf ~/Library/Application\ Support/Claude/vm_bundles  
    rm -rf ~/Library/Application\ Support/Claude/Cache  
    rm -rf ~/Library/Application\ Support/Claude/Code\ Cache  
    
  • วิธีนี้อาจช่วยให้ประสิทธิภาพดีขึ้นชั่วคราว แต่ จำเป็นต้องรีสตาร์ตเป็นระยะ
  • ผู้ใช้บางรายเปลี่ยนสิทธิ์ของโฟลเดอร์ VM เป็น chmod 000 เพื่อ ป้องกันการสร้างใหม่

เสียงตอบรับจากผู้ใช้

  • แม้จะปิดการใช้งาน Cowork อยู่ VM ก็ยังทำงานและใช้หน่วยความจำ
  • ผู้ใช้บางรายรายงานว่า VM bundle ขยายเกิน 21GB
  • VM จะถูก reprovision ใหม่อัตโนมัติเมื่อเปิดแอป และยังเหลือไฟล์บีบอัด (rootfs.img.zst) ไว้ด้วย ทำให้ เปลืองพื้นที่ซ้ำซ้อน
  • แม้แต่ผู้ใช้ที่ไม่เคยใช้ Cowork เลยก็ยังพบ bundle ขนาด 10GB และมองว่าเป็น memory leak
  • ผู้ใช้ Mac ที่มีพื้นที่จัดเก็บจำกัดย้ำถึง ความจำเป็นของตัวเลือกปิดใช้งาน

ประเด็นด้านความโปร่งใสและความน่าเชื่อถือ

  • ผู้ใช้ชี้ว่าการที่แอปใช้ ดิสก์ 12~20GB และ RAM 2GB โดยไม่แจ้งล่วงหน้า เป็นปัญหา
  • มีข้อเสนอให้ แจ้งเตือนตอนติดตั้งหรือเปิดใช้งานครั้งแรก, ให้เลือกว่าจะดาวน์โหลด VM ล่วงหน้าหรือไม่, และ เพิ่มสวิตช์ปิด Cowork
  • บางคนระบุว่า เข้าใจเจตนาของการออกแบบ sandbox ด้วย VM แต่การขาดคำอธิบายทำลายความเชื่อมั่นของผู้ใช้
  • มีความเห็นจำนวนมากว่า “แอปที่ใช้ทรัพยากรระบบโดยที่ผู้ใช้ไม่รู้ตัว ทำให้ความเชื่อมั่นลดลง”

1 ความคิดเห็น

 
GN⁺ 2026-03-03
ความคิดเห็นจาก Hacker News
  • สวัสดี Felix จาก Anthropic เอง ฉันรับผิดชอบ Claude Cowork และ Claude Code
    Cowork ถูกสร้างขึ้นบน agent harness ของ Claude Code ที่ทำงานอยู่ภายใน Linux VM และรันผ่าน Apple Virtualization Framework หรือ Microsoft Host Compute System
    เหตุผลที่ทำแบบนี้มีสามข้อ
    (1) เพื่อมอบ สภาพแวดล้อมคอมพิวเตอร์ที่แยกอิสระ ให้ Claude สามารถเขียนโค้ดแทนผู้ใช้ได้อย่างอิสระ
    (2) เพื่อให้ การรับประกันขอบเขตด้านความปลอดภัย ชัดเจนกว่าทางเลือกด้าน sandboxing อื่น ๆ
    (3) เพื่อมอบประสบการณ์การใช้งานที่ปลอดภัยยิ่งขึ้นแก่ผู้ใช้ที่ไม่เชี่ยวชาญด้านเทคนิค
    อย่างไรก็ตาม เราทราบดีว่ามี trade-off อยู่ และกำลังพิจารณาแนวคิดปรับปรุงสำหรับคนที่ไม่ต้องการใช้ Cowork หรืออยากใช้งานโดยไม่มี VM

    • ขอเสนอ feedback ว่า ถ้า Cowork ใช้พื้นที่เก็บข้อมูล 10GB ก็ควร แจ้งผู้ใช้ล่วงหน้า และให้ลบได้ด้วยคลิกเดียว
      การลด “approval fatigue” อาจเป็นประโยชน์ต่อ Anthropic ในระยะสั้น แต่ในระยะยาวไม่ได้เป็นผลดีต่อผู้ใช้
      น่าจะดีกว่าถ้าหยุดรูปแบบนี้ก่อนที่มันจะกลายเป็นเรื่องปกติ
    • อยากให้มี container image สำหรับ Claude sandbox แบบทางการหรือกึ่งทางการ และน่าจะดีถ้านำ Cowork VM ไปใช้นอกระบบได้ด้วย
    • คำอธิบายยอดเยี่ยม แต่ในทางปฏิบัติมีเสียงบ่นว่า Cowork ทำให้เกิด ปัญหาประสิทธิภาพตกและกินพลังงาน
    • ก่อนหน้านี้ไม่รู้เลยว่า Cowork รันอยู่บน VM ถ้าฝั่งการตลาดสื่อสารเรื่องนี้ให้ชัดกว่านี้ ฉันน่าจะลองใช้ไปนานแล้ว
    • เคยพยายามรันจาก Claude Desktop ไปยัง Mac VM (ภายใน UTM) แล้วเจอ error เกี่ยวกับ Apple Virtualization Framework
      ดูเหมือนว่าจะเกิด nested virtualization error เพราะตัวมันเองก็รันอยู่ใน VM แล้ว น่าจะปรับปรุงข้อความ error หรือถ้าตรวจพบว่าอยู่ใน VM อยู่แล้ว ให้ Cowork ข้ามการสร้าง VM ของตัวเองไป
  • ช่วงนี้น่าตกใจที่แอปต่าง ๆ ใช้การเข้าถึงดิสก์กันเกินจำเป็น
    ตัวอย่างเช่น Apple Podcasts ดาวน์โหลด ไฟล์พอดแคสต์ 120GB โดยไม่มีเหตุผลและไม่ยอมลบออก มันถูกแสดงเป็น “System Data” จนต้องไปไล่หาในไดรฟ์ภายนอก

    • ปัญหา “System Data” ของ macOS แย่มากจริง ๆ เพราะ Docker, คลังเพลง, แคช ฯลฯ ทำให้ทุก ๆ 1~2 ปีต้อง ลงเครื่องใหม่แบบคลีน
    • ถ้าลองดูโฟลเดอร์ ~/Library/Messages จะพบว่าการซิงก์ iMessage กินเกิน 100GB เรื่องแบบนี้ควร โยนไปเก็บบนคลาวด์
    • นี่ก็ยุค 5G แล้ว แต่ก็ยังไม่เข้าใจว่าทำไมยังดาวน์โหลดไฟล์เสียงเป็นค่าปริยายอยู่ แค่สตรีมก็น่าจะพอ
    • ฉันก็เคยเจอปัญหา Time Machine backup จนจาก 512GB มี 300GB ถูกแสดงเป็น “System Data” และทำให้เสียงานไปทั้งวัน
    • เพื่อแก้ปัญหาแบบนี้ ฉันใช้เครื่องมืออย่าง Mole และยังใช้ warp/gemini CLI เพื่อตามหาแคชที่ไม่จำเป็นแล้วลบทิ้ง
  • ตอนนี้กำลังสัมผัสทั้งพรและคำสาปของ “vibe coding” ไปพร้อมกัน เรียกได้ว่าเป็น สองด้านของการเขียนโค้ดตามฟีล อย่างแท้จริง

  • VM sandbox คือแกนหลักของ Cowork ถ้าจะให้ความสามารถสร้างโค้ดได้อย่างปลอดภัย ก็จำเป็นต้องมี สภาพแวดล้อมแบบแยกส่วน
    ขอเสนอ UI ที่ให้ผู้ใช้กำหนดสิทธิ์เข้าถึงได้เฉพาะบางโฟลเดอร์ และแสดงคำเตือนเมื่อจำเป็นต้องใช้สิทธิ์เขียน

  • จริง ๆ แล้วต่อให้ไม่มี LLM การพัฒนาก็ควรทำใน VM อยู่ดี
    เครื่องมืออย่าง Vagrant ก็ยังมีประโยชน์อยู่
    กลุ่มเป้าหมายหลักของ Cowork คือผู้ที่ไม่ใช่นักพัฒนา และควรมองมันเป็น AI ผู้ช่วยที่เขียนโค้ดได้
    ผู้เชี่ยวชาญอาจทำงานบน Mac Mini แยกต่างหาก แต่ผู้ใช้ทั่วไปทำแบบนั้นไม่ได้ ดังนั้น VM จึงเป็นทางออกที่สมจริง

    • ทุกวันนี้มีผู้ให้บริการ VPS มากมาย จึงสร้าง environment ได้ง่ายจากที่อย่าง exe.dev, sprites.dev, shellbox.dev
    • สำหรับโปรเจกต์ที่ซับซ้อน ฉันชอบ devcontainer มากกว่า ถ้าใช้ Docker กับ NixOS ก็จะได้สภาพแวดล้อมการพัฒนาที่เบากว่าและยืดหยุ่นกว่า
    • บน macOS นั้น Lima เป็นตัวเลือกที่ดีที่สุดสำหรับฉัน ฉันเก็บ Claude Code ไว้เป็น image และ mount เฉพาะไดเรกทอรีที่ต้องใช้ มันลื่นไหลกว่า Vagrant มาก
    • ถึงขั้นมีคนเล่นมุกว่า “แล้วตอนเขียนโปรแกรมก็ใส่ถุงยางด้วยไหม?” เพื่อแซวว่า ความหมกมุ่นเรื่องความปลอดภัย มันมากเกินไป
  • ได้ยินมาว่าพนักงาน Anthropic กำลังใช้ Claude Code เพื่อพัฒนา Claude Code
    AI ช่วยเพิ่มความสมบูรณ์ของผลิตภัณฑ์ได้ แต่ปัญหาคือ คุณภาพที่ลดลง สุดท้ายก็ยังต้องพึ่งนักพัฒนาที่มีทักษะอยู่ดี
    ผู้ใช้กลุ่มแรก ๆ ต้องรับบทเป็นหนูทดลองเพื่อช่วยทดสอบผลิตภัณฑ์

    • สงสัยว่าผลิตภัณฑ์ 1st party แบบนี้จะแข่งกับโอเพนซอร์สได้จริงหรือไม่ ในเมื่อมีทางเลือกฟรีที่ดีกว่าอยู่แล้ว ก็ไม่มีเหตุผลมากนักที่จะต้องใช้
    • ถ้าดูจากปัญหาคุณภาพภายใน Anthropic พนักงานส่วนใหญ่ดูเหมือนจะอยู่ในระดับ ต่ำกว่าจูเนียร์ ด้วยซ้ำ มีเพียงทีม Bun ที่ดูเป็นข้อยกเว้น
  • ช่วง 30 นาทีที่ผ่านมา ฉันกำลังจัดระเบียบโน้ตบุ๊กด้วย DaisyDisk แล้วก็เจอ VM 10GB ของ Cowork
    หลายแอปมักกินพื้นที่เก็บข้อมูลโดยไม่จำเป็น และแทบไม่มีฟังก์ชันช่วยจัดการเลย
    Xcode เองก็ยังเก็บ SDK และ simulator สำหรับหลาย OS ไว้ ทั้งที่ไม่ได้เปิดใช้งานมานานแล้ว

    • ถ้าจะจัดการปัญหาแบบนี้ ใช้ DevCleaner ได้เลย
    • บน macOS ก็มี crond กับ find อยู่แล้ว เลยสงสัยว่าทำไมไม่ทำงานล้างพวกนี้ให้เป็นอัตโนมัติ
  • เนื่องจาก Cowork ใช้ Apple Virtualization Framework จึงเกิด nested VM error ได้
    ส่งผลให้มีข้อจำกัดของฟีเจอร์ เปลืองพื้นที่ และเกิดความหน่วง ทางเลือกที่ดีกว่าอาจเป็น Seatbelt sandbox ที่ OpenAI ใช้อยู่
    ลิงก์ที่เกี่ยวข้อง

    • แต่ฉันคิดว่า Seatbelt แทบไม่มีประโยชน์เลย ทำไมถึงต้องพยายามรัน Cowork ใน VM อยู่ด้วยล่ะ ใช้ VM ของมันเองก็พอไม่ใช่เหรอ?
    • แถม Seatbelt ยัง แทบไม่มีเอกสาร อีกด้วย
  • แม้จะไม่สะดวก แต่วิธีทำ sandbox แบบนี้แหละคือ แก่นแท้ของเครื่องมือแบบ agent
    เครื่องมือที่รันโดยไม่มี sandbox ในตัว สักวันหนึ่งจะนำไปสู่ การสูญหายของข้อมูล

  • เดาว่าข้างใน Anthropic คงมีคนโยนพรอมป์ต์แนว “ปรับปรุงประสิทธิภาพแอป” เข้าไป แล้วผลลัพธ์ถึงออกมาเป็นแบบนี้