Cowork feature creates 10GB VM bundle that severely degrades performance

Worse part is this VM is running and eating memory even when Cowork is disabled ...

<img width="550" height="102" alt="Image" src="https://github.com/user-attachments/assets/24bfe7e9-b238-4a88-8165-253835c4fcae" />

Why is a virtual machine necessary at all?

Mine is 21.47GB and counting...

Just found the same 10GB VM bundle and a cache stuffed with over 15,000 files, no wonder things were getting sluggish with opening the desktop app. Worse it just came back within a single launch and reboot cycle without ever touching Cowork. It’s silently re-provisioning on cold launch and getting bigger 13GB. The rootfs.img.zst being retained alongside the decompressed rootfs.img is wasteful, leaving the compressed source sitting there after it's already been extracted. No cleanup at all. Have to nuke this.

I've never used Co-work, yet I still just deleted a 10gb bundle. This is such an obvious memory leak.
Pretty disappointing.

lol, didn't think I'd be typing rm -r ~/Library/Application Support/Claude today but this was my last straw to fully switch to terminal-based workflows

Same on Windows, at ~\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx (and associated zst file). Should be possible to disable this by disabling Cowork. I get that this is needed to provide isolation from the FS other than the mounted folder, but it's pretty extreme and if the user's space on C drive is limited (which mine is) it's pretty problematic.

Cowork should work in the same way as Claude Code, with access to the terminal (whether bash or PowerShell) and a hard-coded block if attempting to cd up out of the current working directory. Hell, if you can't train it to use PowerShell (or macOS variant of bash), then use git bash rather than running your own huge custom OS.

I have a free account, not paid. Have never used cowork and the Claude desktop app on macOS is downloading a VM file ranging between 14 and 25 GB to my machine. Nothing seems to be able to stop it.

File: claudevm.bundle

Located at: /Users/[user]/Library/Application Support/Claude/vm_bundles

And "Virtual Machine Service for Claude" is also now using more memory than anything else on my computer.

On my Mac OS system Claude is using 13 GB under Application Support.

It’s wild that anyone thought it was acceptable to ship an app that requires upwards of 10GB of disk space – 24gb for me – for a feature that many people will never use and that can't be disabled.

It’s almost Adobe-like in its user hostility.

Worse part is this VM is running and eating memory even when Cowork is disabled ...

Finally someone else said it and not just me. Running claude desktop on my 16GB macbook is kinda a pain. I dont use co-work, nor do I plan to. Why is this VM running eating 2gb of system memory? How can i disable this? Honestly if it wasn't for MCP stuff, id just use the webpage.

Also seeing 10GB+ being used, going to have to uninstall the claude app and just stick to terminal usage for now

Didn't realize this issue was open against "claude code", the fact that it was open by "claude code" apparently makes it even funnier but apparently they don't have a "claude-desktop" repository, or even "claude-desktop-issues" ...

Honestly if it wasn't for MCP stuff, id just use the webpage.

Yeah we don't have much enabled on the mcp side here so i simply switched back the the webui, the macbook is thanking me

Running claude desktop on my 16GB macbook is kinda a pain.

It's a pain even on 32G ones...

Why is there not a simple toggle to disable cowork? I dont want a VM running, taking resources, for a feature I'll never use.

There is a toggle, it just doesn't do anything about the VM
Which is concerning at multiple level

Quite shocking this can't be disabled.

Please can a configuration toggle be added to disable/remove the VM.

I am so glad I'm not the only one annoyed by this. I don't use cowork, I use chat and code. Sure it uses up 10 GB of storage space, but just having the app open in chat has it sitting at almost 4 GB of App Memory. It redownloads the bundle if you delete it. I'm in the terminal with claude code and it's only using ~600 MB of app memory. That's like 6.6x less memory. I was shocked there wasn't a simple toggle somewhere.

No fix in the latest update to Claude desktop app. App is sitting there unused in the background, and again I've never used cowork.

<img width="447" height="130" alt="Image" src="https://github.com/user-attachments/assets/8ad3ee1f-3cf8-4430-893c-2f809e3511e3" />

Has anyone tried sudo chown -R root:wheel ~"/Library/Application Support/Claude/vm_bundles/" or santa to lock Claude down?

Mine is 21.47GB and counting...

Bro, same. That thing grows faster than my salary. =))

<img width="968" height="210" alt="Image" src="https://github.com/user-attachments/assets/27010273-e248-4d0d-8985-dd08e37df369" />

That calmed me I'm not only the one who is experiencing this issue. Switching to terminal-based usage.

It looks like it is fine to remove the vm_bundles, it is specifically used for computer use / agent mode. The code feature uses claude-code-vm.

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

Yeah, it's totally fine to delete it. Although, it will just re-build itself

Yeah, it's totally fine to delete it. Although, it will just re-build itself

That will probably give us some time:

touch ~/Library/Application\ Support/Claude/vm_bundles/.auto_reinstall_attempted

I found it on my machine after a few failed attempts to reinstall the VM.

10GB+ for a cowork VM bundle is definitely excessive. This kind of unexpected disk usage is especially frustrating on macOS where developers already have limited SSD space due to other tool caches.

For anyone hitting this and needing to reclaim space immediately:

# Find the VM bundles
find ~ -name "*.vmem" -o -name "*.vmdk" -o -name "*cowork*" 2>/dev/null | head -20

# Check Claude-related disk usage
du -sh ~/Library/Application\ Support/Claude/ 2>/dev/null
du -sh ~/.claude/ 2>/dev/null

# General approach: find large files created recently
find ~ -size +1G -mtime -7 -type f 2>/dev/null | head -20

The 10GB is significant in context on a typical macOS dev machine, you're already dealing with:

• Xcode/DerivedData: 5-20GB
• Docker Desktop: 10-30GB
• node_modules across projects: 5-15GB
• Various package manager caches: 5-10GB

Adding another 10GB for Claude cowork can push people over the edge on 256GB/512GB machines.

For anyone wanting a quick audit of what's eating their disk across all developer tools, ClearDisk is a free open-source macOS menu bar app that scans developer caches and large directories. Shows the full breakdown so you can identify the biggest offenders and prioritize cleanup.

10GB+ for a cowork VM bundle is definitely excessive. This kind of unexpected disk usage is especially frustrating on macOS where developers already have limited SSD space due to other tool caches. For anyone hitting this and needing to reclaim space immediately: # Find the VM bundles find ~ -name ".vmem" -o -name ".vmdk" -o -name "cowork" 2>/dev/null | head -20 # Check Claude-related disk usage du -sh ~/Library/Application\ Support/Claude/ 2>/dev/null du -sh ~/.claude/ 2>/dev/null # General approach: find large files created recently find ~ -size +1G -mtime -7 -type f 2>/dev/null | head -20 The 10GB is significant in context on a typical macOS dev machine, you're already dealing with: Xcode/DerivedData: 5-20GB Docker Desktop: 10-30GB node_modules across projects: 5-15GB Various package manager caches: 5-10GB Adding another 10GB for Claude cowork can push people over the edge on 256GB/512GB machines. For anyone wanting a quick audit of what's eating their disk across all developer tools, ClearDisk is a free open-source macOS menu bar app that scans developer caches and large directories. Shows the full breakdown so you can identify the biggest offenders and prioritize cleanup.

Disk Inventory X is what one needs. Despite slightly dated UI, it beats anything (paid or otherwise) when it comes to productivity and speed.

P.S. WinDirStat is a similar idea but for Windows. Can't recommend more!

@paaloeye I would recommend GrandPerspective on Mac as it's more recent than Disk Inventory X.

WizTree is my preference over WinDirStat on Windows, it's significantly faster.

guys, buy more RAM, it's cheap

I created a macOS configuration profile that disables the Cowork feature. Quit the app, ran the delete commands from the original post, then applied the profile.

After 1 hour of having Claude desktop open, the VM storage was not recreated. The Cache and Code Cache came back immediately.

I've attached the profile here, you can open it in any text editor to validate it, and the documentation for the profile keys is here: https://support.claude.com/en/articles/12622667-enterprise-configuration

Claude - Disable Cowork.mobileconfig.zip

Hi, Felix from Anthropic here. I work on Claude Cowork and Claude Code.
Claude Cowork uses the Claude Code agent harness running inside a Linux VM (with additional sandboxing, network controls, and filesystem mounts). We run that through Apple's virtualization framework or Microsoft's Host Compute System. This buys us three things we like a lot:

(1) A computer for Claude to write software in, because so many user problems can be solved really well by first writing custom-tailored scripts against whatever task you throw at it. We'd like that computer to not be _your_ computer so that Claude is free to configure it in the moment.

(2) Hard guarantees at the boundary: Other sandboxing solutions exist, but for a few reasons, none of them satisfy as much and allow us to make similarly sound guarantees about what Claude will be able to do and not to.

(3) As a product of 1+2, more safety for non-technical users. If you're reading this, you're probably equipped to evaluate whether or not a particular script or command is safe to run - but most humans aren't, and even the ones who are so often experience "approval fatigue". Not having to ask for approval is valuable.

It's a real trade-off though and I'm thankful for any feedback, including this one. We're reading all the comments and have some ideas on how to maybe make this better - for people who don't want to use Cowork at all, who don't want it inside a VM, or who just want a little bit more control. Thank you!

i think thats valid but a heads up is necessary especially for ppl with like 256gb of space.

We need to be able to disable Cowork if it requires that much storage space. Not all of us have huge amounts of storage space on our Macs (mainly because of Apple…).

Thanks for the detailed explanation, @felixrieseberg - I appreciate the thoughtful design behind the VM sandboxing approach.

As a user (and social scientist), I just want to offer a perspective on the trust/transparency trade-off here:

While I understand the goal of reducing approval fatigue and making Cowork 'just work' when users need it, the current implementation actually creates a different trust problem.

When users discover that Claude Desktop is consuming 12-20GB of disk space and 2GB of active memory for features they've never used, all with no advance notice, no clear explanation in-app, and no way to disable it or even find out what it is, that undermines trust in the product more than approval prompts would.

I'm not a developer. I found this by accident during routine disk space management. Many users won't even realize it's happening, and when they do find out, it feels like the app is doing things behind their back that impact aspects of their digital lives beyond what they would have expected.

A few suggestions that might help:

• Disclosure: Inform users during installation or first launch that enabling Pro features will download a 12-20GB VM and use 2GB RAM, even when not actively using Cowork

• Opt-in for VM pre-provisioning: Let users choose whether to pre-download the VM or download on first Cowork use (with clear wait-time expectations)

• Settings toggle: Provide a way to remove the VM when users know they won't be using Cowork, with clear info about what features will be unavailable

Low friction is valuable, but so is transparency. Users who understand why the VM exists and what it enables are more likely to accept the trade-off than users who just see unexplained resource consumption.

Thanks for listening to feedback on this. I genuinely (obviously) love the things you all make and use them with delight.

A workaround to never get it back:

1. Close Claude Desktop
2. rm -rf ~/Library/Application\ Support/Claude/vm_bundles/*
3. chmod 000 ~/Library/Application\ Support/Claude/vm_bundles/

This will prevent Claude from creating another vm bundle. Works for me.

for future people on windows,
here is a reg file that completely disables claude cowork to save space and cpu usage.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Claude]
"secureVmFeaturesEnabled"=dword:00000000

Judging from a quick test, it looks like this works on macOS too.

"secureVmFeaturesEnabled":false should be added to preferences object in ~/Library/Application Support/Claude/claude_desktop_config.json

for future people on windows, here is a reg file that completely disables claude cowork to save space and cpu usage. `` Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Claude] "secureVmFeaturesEnabled"=dword:00000000 ``

I have found that it is also downloading extra copies into C:\Users\****\AppData\Local\Temp and not cleaning them up even after blocking the application from writing to the folder. I don't use this feature at all.

<img width="1242" height="141" alt="Image" src="https://github.com/user-attachments/assets/a8b21acb-4244-4454-add1-8343ffbbe0eb" />

I noticed this problem when I received a low free disk space system notification. The activity monitor showed that Claude Desktop had downloaded over 10 GB. I used the Claude CLI to investigate what and where exactly the issue was. The solution turned out to be a reboot. Unfortunately, the Claude CLI did not survive this; it attempted to auto-update, and due to the lack of free space, it corrupted the installation and essentially self-deleted.

Judging from a quick test, it looks like this works on macOS too. "secureVmFeaturesEnabled":false should be added to preferences object in ~/Library/Application Support/Claude/claude_desktop_config.json > for future people on windows, here is a reg file that completely disables claude cowork to save space and cpu usage. > `` > > Windows Registry Editor Version 5.00 > > [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Claude] > "secureVmFeaturesEnabled"=dword:00000000 > ``

<img width="461" height="232" alt="Image" src="https://github.com/user-attachments/assets/85bd7fe8-c242-4c3c-92ea-534dbce6053b" />

Windows workaround: move vm_bundles to another drive via junction

On Windows, the vm_bundles directory lives at:

%APPDATA%\Claude\vm_bundles\

It grows to ~13GB (rootfs.vhdx alone is ~10GB). If your C: drive is space-constrained, you can relocate it to another drive using an NTFS junction (transparent to Claude):

# 1. Fully close Claude Desktop / Claude Code
# 2. Move the folder to another drive
Move-Item "$env:APPDATA\Claude\vm_bundles" "D:\claude\vm_bundles"
# 3. Create a junction (requires admin)
New-Item -ItemType Junction -Path "$env:APPDATA\Claude\vm_bundles" -Target "D:\claude\vm_bundles"

Claude sees the original path, but the data lives on D:\. No config changes needed, survives updates.

Workaround: CPU/RAM Monitor to Prevent Crashes on macOS + M1

Hope this helps someone. It won't fix the underlying bug but it gives you
enough warning to save your work and start a fresh thread before the crash hits.
It's working for me anyway...

If you're hitting the macOS 26.3 + M1 crash issue with Cowork, I built a
lightweight background monitor that watches Claude Desktop's CPU and RAM usage
and fires a native macOS notification before things go sideways. It gives you
time to wrap up your thread and start a fresh one before the crash happens.

What it does:

• Runs silently in the background whenever Claude Desktop is open
• Checks CPU and RAM usage every 30 seconds
• Sends a macOS banner notification if CPU exceeds 75% or RAM exceeds 3GB
• Automatically stops when you quit Claude Desktop
• Does NOT use KeepAlive (won't cause the infinite restart loop some people

have experienced)

Tested on: MacBook Pro M1, 16GB RAM, macOS Tahoe 26.3

---

Installation (3 steps)

Step 1 — Download these 3 files and put them in the same folder
(e.g. your Desktop):

• claude-monitor.py
• com.jay.claudemonitor.plist
• install-claude-monitor.sh

Step 2 — Open Terminal and run:

bash ~/Desktop/install-claude-monitor.sh

(If you saved the files somewhere else, replace ~/Desktop with that path.
Tip: type bash then drag the .sh file into Terminal to auto-fill the path.)

Step 3 — Done. The monitor starts immediately and will restart
automatically every time you log into your Mac.

---

To stop it mid-session

Open Terminal and type:

stop-claude-monitor

(This alias is added automatically during installation.)

---

The 3 files

claude-monitor.py

#!/usr/bin/env python3
"""
Claude Desktop Monitor
Watches Claude Desktop CPU and RAM usage and fires macOS notifications
when thresholds are crossed. Automatically starts/stops with Claude Desktop.
"""

import subprocess
import time
import sys

# Thresholds
CPU_WARN_PERCENT   = 75    # Warn when Claude process CPU exceeds this
RAM_WARN_MB        = 3000  # Warn when Claude process RAM exceeds 3GB
POLL_INTERVAL_SEC  = 30    # Check every 30 seconds
NOTIFY_COOLDOWN    = 120   # Don't repeat same warning for 2 minutes

CLAUDE_PROCESS = "Claude"


def notify(title, message):
    script = f'display notification "{message}" with title "{title}" sound name "Basso"'
    subprocess.run(["osascript", "-e", script], capture_output=True)


def get_claude_pids():
    result = subprocess.run(
        ["pgrep", "-x", CLAUDE_PROCESS],
        capture_output=True, text=True
    )
    if result.returncode != 0:
        return []
    return [p.strip() for p in result.stdout.strip().split("\n") if p.strip()]


def get_process_stats(pids):
    total_cpu = 0.0
    total_mem_mb = 0.0
    for pid in pids:
        result = subprocess.run(
            ["ps", "-p", pid, "-o", "pcpu=,rss="],
            capture_output=True, text=True
        )
        if result.returncode != 0:
            continue
        parts = result.stdout.strip().split()
        if len(parts) >= 2:
            try:
                total_cpu    += float(parts[0])
                total_mem_mb += float(parts[1]) / 1024
            except ValueError:
                pass
    return total_cpu, total_mem_mb


def main():
    last_cpu_notify = 0
    last_ram_notify = 0
    was_running     = False

    print(f"Claude Desktop Monitor started. Polling every {POLL_INTERVAL_SEC}s.")

    while True:
        pids = get_claude_pids()

        if not pids:
            if was_running:
                print("Claude Desktop closed. Waiting for relaunch...")
                was_running = False
            time.sleep(POLL_INTERVAL_SEC)
            continue

        if not was_running:
            print(f"Claude Desktop detected (PID: {', '.join(pids)}). Monitoring started.")
            was_running = True

        cpu, mem_mb = get_process_stats(pids)
        now = time.time()

        print(f"Claude: CPU={cpu:.1f}%  RAM={mem_mb:.0f}MB")

        if cpu >= CPU_WARN_PERCENT and (now - last_cpu_notify) > NOTIFY_COOLDOWN:
            notify(
                "Claude Desktop - High CPU",
                f"CPU at {cpu:.0f}%. Consider wrapping up this thread soon."
            )
            last_cpu_notify = now

        if mem_mb >= RAM_WARN_MB and (now - last_ram_notify) > NOTIFY_COOLDOWN:
            notify(
                "Claude Desktop - High Memory",
                f"RAM at {mem_mb:.0f}MB. Start a new thread to avoid a crash."
            )
            last_ram_notify = now

        time.sleep(POLL_INTERVAL_SEC)


if __name__ == "__main__":
    try:
        main()
    except KeyboardInterrupt:
        print("Monitor stopped.")
        sys.exit(0)

---

com.jay.claudemonitor.plist

Before using this file, replace YOUR_MAC_USERNAME with your actual Mac username. You can find it by opening Terminal and typing whoami.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.jay.claudemonitor</string>

  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/python3</string>
    <string>/Users/YOUR_MAC_USERNAME/scripts/claude-monitor.py</string>
  </array>

  <key>RunAtLoad</key>
  <true/>

  <!-- KeepAlive is intentionally false — avoids infinite restart loop -->
  <key>KeepAlive</key>
  <false/>

  <key>StandardOutPath</key>
  <string>/Users/YOUR_MAC_USERNAME/scripts/claude-monitor.log</string>

  <key>StandardErrorPath</key>
  <string>/Users/YOUR_MAC_USERNAME/scripts/claude-monitor-error.log</string>

  <!-- Low priority — won't compete with Claude for resources -->
  <key>Nice</key>
  <integer>20</integer>
</dict>
</plist>

---

install-claude-monitor.sh

This script fills in your username automatically — you don't need to edit the plist manually if you use the installer.

#!/bin/bash
set -e

SCRIPTS_DIR="$HOME/scripts"
PLIST_NAME="com.jay.claudemonitor"
PLIST_DEST="$HOME/Library/LaunchAgents/$PLIST_NAME.plist"
SCRIPT_DEST="$SCRIPTS_DIR/claude-monitor.py"

echo "Installing Claude Desktop Monitor..."

mkdir -p "$SCRIPTS_DIR"

cp "$(dirname "$0")/claude-monitor.py" "$SCRIPT_DEST"
cp "$(dirname "$0")/com.jay.claudemonitor.plist" "$PLIST_DEST"

# Fix username in plist
sed -i '' "s|YOUR_MAC_USERNAME|$(whoami)|g" "$PLIST_DEST"

chmod +x "$SCRIPT_DEST"

launchctl unload "$PLIST_DEST" 2>/dev/null || true
launchctl load "$PLIST_DEST"

ALIAS_LINE='alias stop-claude-monitor="launchctl unload ~/Library/LaunchAgents/com.jay.claudemonitor.plist && echo Monitor stopped."'
if ! grep -q "stop-claude-monitor" "$HOME/.zshrc" 2>/dev/null; then
  echo "" >> "$HOME/.zshrc"
  echo "# Claude Desktop Monitor" >> "$HOME/.zshrc"
  echo "$ALIAS_LINE" >> "$HOME/.zshrc"
fi

echo ""
echo "Done. Claude Desktop Monitor is running."
echo "To stop it: open Terminal and type stop-claude-monitor"

---

Hope this helps someone. It won't fix the underlying bug but it gives you
enough warning to save your work and start a fresh thread before the crash hits.

I just came here to say thank you to whoever gave a solution to clear out the VM cache. I can actually use co work again.

My pleasure. Happy to help.

On Tue, Mar 10, 2026 at 5:50 PM enoteware @.***> wrote:

enoteware left a comment (anthropics/claude-code#22543) <https://github.com/anthropics/claude-code/issues/22543#issuecomment-4034687961> I just came here to say thank you to whoever gave a solution to clear out the VM cache. I can actually use co work again. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/22543#issuecomment-4034687961>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B5E3MSIPGMUV5DHA5UJB5JD4QCE2VAVCNFSM6AAAAACTVW47QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMZUGY4DOOJWGE> . You are receiving this because you commented.Message ID: @.***>

An option to move/install Claude desktop app in a different drive other than C: would be greatly appreciated.

Adding detailed diagnostic data from inside the VM that may help the team scope a fix.

TL;DR: The root partition is 86% full on a freshly regenerated sessiondata.img — before the user installs anything. Only ~940 MB (10%) is available for actual user work.

Where the 9.6 GB goes

| Category | Size | % of disk |
|---|---|---|
| System packages (/usr) | ~6,400 MB | 67% |
| Snap (dual revisions, incl. LXD) | ~1,400 MB | 15% |
| Logs + caches (/var) | ~650 MB | 7% |
| Boot + EFI | ~210 MB | 2% |
| Free for user | ~940 MB | 10% |

Meanwhile, the /sessions volume (/dev/nvme0n1, 10 GB) sits at 0.01% usage.

Quick wins (potential ~1.7 GB savings)

• /usr/lib/firmware — 1.1 GB of hardware firmware blobs, unnecessary in a virtual machine
• lxd snap — 370 MB (2 revisions), unlikely needed in sandboxed VM
• /usr/share/doc — 170 MB, not needed at runtime
• Duplicate opencv-python-headless alongside opencv-python — 81 MB
• snap set system refresh.retain=1 — save one revision per snap

Compounding factors for power users

• Plugin caches duplicated per session, never cleaned (#30751)
• pip install/npm install writes to root partition, doesn't persist across sessions → users reinstall every time → each session burns tens to hundreds of MB of non-recoverable space

I've filed a comprehensive report with full diagnostics, user remediation timeline, and architectural recommendations: #37860

Create a broken symlink at vm_bundles pointing to a non-existent target. This silently prevents Claude Desktop from downloading the VM

在 vm_bundles 目录下创建一个指向不存在目标的失效符号链接。这会静默地阻止 Claude Desktop 下载虚拟机​​。

All other functions operate perfectly normally and are completely unaffected.

The 10GB VM bundle is a known pain point. Until Anthropic adds automatic cleanup, here are practical workarounds:
Workaround 1 — Periodic cleanup script:

VM_DIR="$HOME/Library/Application Support/Claude/vm_bundles"
CACHE_DIR="$HOME/Library/Application Support/Claude/Cache"
CODE_CACHE="$HOME/Library/Application Support/Claude/Code Cache"
for dir in "$VM_DIR" "$CACHE_DIR" "$CODE_CACHE"; do
  if [ -d "$dir" ]; then
    size=$(du -sh "$dir" 2>/dev/null | cut -f1)
    echo "Cleaning $dir ($size)"
    find "$dir" -type f -delete
  fi
done
echo "Done. Restart Claude Desktop for best results."

Run this whenever performance degrades, or schedule it:

crontab -e

Workaround 2 — Limit VM bundle size with a disk quota (macOS):
On APFS, you can't set per-directory quotas, but you can create a small disk image that limits growth:

hdiutil create -size 2g -fs APFS -volname "ClaudeVM" ~/ClaudeVM.dmg
hdiutil attach ~/ClaudeVM.dmg -mountpoint "/tmp/claude-vm-mount"
mv ~/Library/Application\ Support/Claude/vm_bundles ~/Library/Application\ Support/Claude/vm_bundles.bak
ln -s /tmp/claude-vm-mount ~/Library/Application\ Support/Claude/vm_bundles

This caps the VM bundle at 2GB. Cowork may error when it hits the limit, but it prevents the 10GB growth.
Workaround 3 — Disable Cowork if you don't use it:
If you primarily use Claude Code via the CLI and don't need Cowork, you can prevent VM bundle creation entirely by not enabling the Cowork feature. The bundle only generates when Cowork is used.
Key finding from your investigation: The ~75% performance improvement after cleanup confirms the VM bundle is the bottleneck. If Anthropic added automatic garbage collection (e.g., delete VM data older than 24 hours), this would solve the issue for most users.

I hate to say it, but though I very much like Cowork, the simple fact that it cannot be loaded on a separate drive is wasting a lot of time and money for me. I have to constantly tend to its voracious appetite for diskspace and as a result several issues compound: I lose the thread of logic that's in my head, I lose time from inane and ill-suited techno gook (for my line of work), and I get exceedingly frustrated with having to deal with something that has nothing to do with what I sat down to do.

It all stacks to create the taste of bile in my memory.

Whatever the technicians and architects believe about the benefits of the current setup: if you can't solve for a straightforward "hands out of the engine bay" design criteria, it's not a good solution for market. Let us operate this program in SOME OTHER (EXTENDABLE) MOUNTED PARTITION. Simple solution.

> 在 vm_bundles 目录下创建一个指向不存在目标的失效符号链接。这会静默地阻止 Claude Desktop 下载虚拟机​​。 All other functions operate perfectly normally and are completely unaffected.

Don't do this.
That instruction is designed to break Cowork permanently by tricking Claude Desktop into thinking the VM bundle exists when it doesn't — so it never downloads a fresh one. It's sabotage, not a fix.
Where did you see this? That's the important question. If it came from a forum, Discord, or someone offering a "fix" — it's either malicious or someone who misunderstood what they were doing.
What you actually want is the opposite — a clean VM that rebuilds correctly. You already did that by deleting claudevm.bundle. Cowork will rebuild it fresh on next healthy launch.
Don't run that command.

> > 在 vm_bundles 目录下创建一个指向不存在目标的失效符号链接。这会静默地阻止 Claude Desktop 下载虚拟机​​。 > > > All other functions operate perfectly normally and are completely unaffected. Don't do this. That instruction is designed to break Cowork permanently by tricking Claude Desktop into thinking the VM bundle exists when it doesn't — so it never downloads a fresh one. It's sabotage, not a fix. Where did you see this? That's the important question. If it came from a forum, Discord, or someone offering a "fix" — it's either malicious or someone who misunderstood what they were doing. What you actually want is the opposite — a clean VM that rebuilds correctly. You already did that by deleting claudevm.bundle. Cowork will rebuild it fresh on next healthy launch. Don't run that command.

I'm not saying this or isn't is the correct approach to tackling the problem but many here don't want to use Cowork, and resent the fact that their disk space still takes the hit for it. Breaking it therefore isn't such a big deal for those people

> > > 在 vm_bundles 目录下创建一个指向不存在目标的失效符号链接。这会静默地阻止 Claude Desktop 下载虚拟机​​。 > > > > > > All other functions operate perfectly normally and are completely unaffected. > > > Don't do this. That instruction is designed to break Cowork permanently by tricking Claude Desktop into thinking the VM bundle exists when it doesn't — so it never downloads a fresh one. It's sabotage, not a fix. Where did you see this? That's the important question. If it came from a forum, Discord, or someone offering a "fix" — it's either malicious or someone who misunderstood what they were doing. What you actually want is the opposite — a clean VM that rebuilds correctly. You already did that by deleting claudevm.bundle. Cowork will rebuild it fresh on next healthy launch. Don't run that command. I'm not saying this or isn't is the correct approach to tackling the problem but many here don't want to use Cowork, and resent the fact that their disk space still takes the hit for it. Breaking it therefore isn't such a big deal for those people

Yes, I completely agree. This action is not irreversible; it was simply taken to avoid that 10GB of memory usage, so it can certainly be restored if needed.

For me this directory took up 12.5 gb without even using claude code

Exclude it + the caches from timemachine!

Hi, I tried Cowork but stopped using it because of the heavy quota consumption. However, vm_bundles still recreates itself on every launch and takes up 12GB on my disk. Is there an ETA for a fix or an opt-out option for users who don't want Cowork? Thanks!

Yes I have this same problem. I cant even open up tabs on chrome - though safari works - when this lag starts happening. It happens out of the blue. Then when i exit Claude Desktop and open again, it doesn't work. This is becoming very tedious and irritating - and im running the latest macbook pro..

The fix is clear it, run lean, new chats fast. 10 15min tops, update
memory, optimization, QA, Iterate until desired outcomes. Next task to
complete north star.

On Mon, Apr 13, 2026 at 1:05 AM odetoazam @.***> wrote:

odetoazam left a comment (anthropics/claude-code#22543) <https://github.com/anthropics/claude-code/issues/22543#issuecomment-4233971351> Yes I have this same problem. I cant even open up tabs on chrome - though safari works - when this lag starts happening. It happens out of the blue. Then when i exit Claude Desktop and open again, it doesn't work. This is becoming very tedious and irritating - and im running the latest macbook pro.. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/22543#issuecomment-4233971351>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B5E3MSKFH7VOWICRNQE66PD4VRYTNAVCNFSM6AAAAACTVW47QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMZTHE3TCMZVGE> . You are receiving this because you commented.Message ID: @.***>

@jayrockliffe-defused sorry i'm not that super tech savvy - could you plz explain what you mean in simple terms.. what do i need to do?

i'm not sure if anyone has mentioned this yet, but editing ~/Library/Application Support/Claude/claude_desktop_config.json to add "secureVmFeaturesEnabled": false has been treating me nicely.

<img width="646" height="418" alt="Image" src="https://github.com/user-attachments/assets/c8d01d8d-2a93-4c7c-9d1d-ea875a0ff802" />

<img width="363" height="230" alt="Image" src="https://github.com/user-attachments/assets/2609fb42-753a-4ab5-9278-aa5af7ae472e" />

This does not work on windows, though.

On Tue, Apr 14, 2026 at 2:45 AM yeowool @.***> wrote:

LPFchan left a comment (anthropics/claude-code#22543) <https://github.com/anthropics/claude-code/issues/22543#issuecomment-4240319202> i'm not sure if anyone has mentioned this yet, but editing ~/Library/Application Support/Claude/claude_desktop_config.json to add "secureVmFeaturesEnabled": false has been treating me nicely. SCR-20260414-icto.png (view on web) <https://github.com/user-attachments/assets/c8d01d8d-2a93-4c7c-9d1d-ea875a0ff802> SCR-20260414-icpz.png (view on web) <https://github.com/user-attachments/assets/2609fb42-753a-4ab5-9278-aa5af7ae472e> — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/22543#issuecomment-4240319202>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKMMAYQHUORDZMYKGPX67P34VV33DAVCNFSM6AAAAACTVW47QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENBQGMYTSMRQGI> . You are receiving this because you commented.Message ID: @.***>

Also hitting this. Apple Silicon, Claude.app 1.3883.0. Reinstalled yesterday and within a day rootfs.img was at 7.1 GB actual (10 GB sparse), with 14 Claude helper processes running even with no conversations open. UI got sluggish.

Wiping via Developer > Troubleshooting > Delete VM Bundle and Restart restored perf.

Two things in case they help:

• 7 of my 14 helpers were from Desktop Extensions (each MCPB runs a Node child). Trimming extensions helps with helper count on its own, independent of the VM.
• The .zst seed (2 GB) survives the wipe and re-decompresses to a fresh rootfs in under a minute, so there's no real cost to resetting regularly.

Happy to capture logs from a reinstall-to-degraded cycle if that'd help track down what's accumulating.

the 10GB VM for filesystem isolation is wildly overkill for what cowork actually does. macOS has native sandbox primitives (App Sandbox, sandbox-exec, endpoint security framework) that give real process isolation at a few MB. the team likely went with a full VM for cross-platform parity with Windows (same WSL-style VM there per the comments) but that tradeoff punishes macOS users. for parallel agent isolation, git worktrees per session plus a read-only mount outside the working dir gets 95% of the safety at 0.1% of the disk cost. the missing disable toggle that actually kills the VM is the bigger smell, looks like the feature shipped before the off-switch was wired up.

but that tradeoff punishes macOS users.

Nope, windows has the same issue.

yep

On Fri, Apr 24, 2026 at 10:10 AM borng @.***> wrote:

borng left a comment (anthropics/claude-code#22543) <https://github.com/anthropics/claude-code/issues/22543#issuecomment-4311336690> but that tradeoff punishes macOS users. Nope, windows has the same issue. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/22543?email_source=notifications&email_token=BKMMAYTUTWPAA5HCJXX5ZID4XMHP3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZRGEZTGNRWHEYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4311336690>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKMMAYTIH4J4HMJXSIHGSN34XMHP3AVCNFSM6AAAAACTVW47QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMJRGMZTMNRZGA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BKMMAYQBEKDRXUMO5J3B2A34XMHP3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZRGEZTGNRWHEYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BKMMAYSFT5EA4PUV4K5YXB34XMHP3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZRGEZTGNRWHEYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>

I ran into the same issue on macOS with Claude Desktop.

In my case, the large disk usage came from:

~/Library/Application Support/Claude/vm_bundles/claudevm.bundle

It contained a VM root filesystem image, and the directory reached ~12GB.

One workaround I found is to disable the scheduled Cowork / Claude Code Desktop task flags in:

~/Library/Application Support/Claude/claude_desktop_config.json

Change:

  {
    "preferences": {
      "coworkScheduledTasksEnabled": true,
      "ccdScheduledTasksEnabled": true
    }
  }

  to:

  {
    "preferences": {
      "coworkScheduledTasksEnabled": false,
      "ccdScheduledTasksEnabled": false
    }
  }

Then fully quit Claude Desktop and remove the existing VM bundle:

rm -rf "$HOME/Library/Application Support/Claude/vm_bundles"

After doing this, my Claude application support directory dropped from ~12GB+ to a few hundred MB.

Important caveats:

• This does not fully disable Cowork.
• If Cowork / Claude Code on Desktop is started again, the VM bundle may be regenerated.
• Setting secureVmFeaturesEnabled=false via defaults does prevent the secure VM feature, but it also breaks Claude Code /

Cowork functionality in Desktop, so it is not a good workaround if you still want Desktop Claude Code to work.

• Standalone Claude Code CLI and IDE extensions appear to be separate from Claude Desktop. On my machine, the CLI lives

under ~/.local/share/claude and ~/.claude, so I avoided deleting those.

So this is only a mitigation for unwanted scheduled/background Cowork activity and disk cleanup, not a real fix. Ideally Claude Desktop should expose this in the UI, document the disk requirement, and provide a supported purge/cleanup command for vm_bundles.

Running Windows inside Proxmox. Cowork activates Hyper-V on startup even when idle, which triggers nested virtualization and causes severe performance degradation across the entire VM — before Cowork is even used.
I want to use Cowork, but the current implementation makes it unusable in a type-1 hypervisor (Proxmox, ESXi, etc.). Would it be possible to support an alternative sandboxing path that doesn't require nested virt — e.g. only initializing the VM on demand, or detecting that the host is already a VM and adjusting accordingly?

Adding suggestion to what @vbiroshak already gave for space problem:

• Add a config setting for the user change at least the VM folder. Could also be a tool, or a script based on things like this one (it would need to be OS specific).

Experiencing this issue and can confirm it's severe enough to cause repeated macOS kernel panics on a MacBook Pro 16,1 (2019).

The rootfs.img grows unboundedly during Claude Code sessions in the VSCode Extension and eventually fills the disk completely. When the disk hits ~99% capacity, macOS can no longer write swap files, which causes a watchdog timeout kernel panic (AppleSMC stops responding). This happened three times in succession, with the machine crashing faster each time as available disk space decreased.

The vm_bundles directory reached 10GB+ and was actively growing during sessions. After discovering the cause, deleting the Docker leftover data and the vm_bundles directory freed up significant space, but rootfs.img regrows to 10GB within a single session.

Current workaround before each session:

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

This issue isn't just a performance problem — on machines with limited free disk space it causes kernel panics and data loss risk. Would strongly recommend this be treated as a critical stability bug in addition to the performance impact already documented here.

I just stumbled upon mine wondering where all my disk space went and it's a whopping 25GB. That's pretty ridiculous.

Yeah

On Wed, May 27, 2026 at 6:54 PM liam-k @.***> wrote:

liam-k left a comment (anthropics/claude-code#22543) <https://github.com/anthropics/claude-code/issues/22543#issuecomment-4556221851> I just stumbled upon mine wondering where all my disk space went and it's a whopping 25GB. That's pretty ridiculous. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/22543?email_source=notifications&email_token=BKMMAYWOHNAANMG2Y33SB6T444FUVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVGYZDEMJYGUY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4556221851>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKMMAYWSRFPKFIGOE3Y6PYL444FUVAVCNFSM6AAAAACTVW47QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNJWGIZDCOBVGE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BKMMAYXORK25CVD76FSFOAL444FUVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVGYZDEMJYGUY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BKMMAYVWKJPC2MX5GJSEIP3444FUVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVGYZDEMJYGUY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>

Can't Mythos fix this? please

Lol

On Thu, May 28, 2026 at 4:03 AM José Díaz @.***> wrote:

jdiaz97 left a comment (anthropics/claude-code#22543) <https://github.com/anthropics/claude-code/issues/22543#issuecomment-4559958128> Can't Mythos fix this? please — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/22543?email_source=notifications&email_token=BKMMAYQSTLZE4LBMTZ5XM4L446F4HA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVHE4TKOBRGI4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4559958128>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKMMAYU7SDSIZC3CZH7VR5D446F4HAVCNFSM6AAAAACTVW47QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNJZHE2TQMJSHA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BKMMAYUERUVBZNU43LAVKAT446F4HA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVHE4TKOBRGI4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BKMMAYWHY4ZXS7D4N6SZESL446F4HA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVHE4TKOBRGI4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>

still not yet solve? was hoping to see some solution

too

on macOS I did this:
chmod 000 ~/Library/Application\ Support/Claude/vm_bundles
to prevent Claude from writing to this folder. It's working fine so far, probably because I don't use Cowork, at all.

To be clear, is this for Claude Desktop only? If I onlly use Claude Code CLI, is it safe to purge it?