[BUG] Claude Desktop VMs leak ~6,200 file descriptors/hour via Virtualization.framework, exhausting system limit in ~3.5 days

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

Related Issues

#29573 reports the same symptom (ENFILE / "Operation not permitted") but without root cause analysis. This issue provides the diagnostic data.

What is Wrong?

Each Claude Desktop project spawns a com.apple.Virtualization.VirtualMachine XPC process. These VM processes accumulate REG and DIR file descriptors across the host filesystem and never release them. The FDs span the entire home directory -- they are not limited to the project directory.

Over time, these leaked FDs exhaust the system-wide limit (kern.maxfiles = 524,288), causing ENFILE errors across the entire system. All processes -- not just Claude -- fail to open files, spawn processes, or accept network connections.

Measured Leak Rate

With 4 Claude Desktop projects open:

| Project VM | FDs Accumulated | Uptime | Leak Rate |
|------------|----------------|--------|-----------|
| assistant | 108,069 | 42h | ~2,573/hr |
| jira-ai | 75,825 | 43h | ~1,767/hr |
| bookkeeper | 53,548 | 67h | ~806/hr |
| agenticsearch | 47,611 | 43h | ~1,116/hr |
| Combined | 285,053 | | ~6,200/hr |

At this rate, the system limit is exhausted in approximately 3.5 days from a fresh start.

How to Reproduce

1. Open 3-4 Claude Desktop projects
2. Wait 24-48 hours (normal use, do not need to actively use all of them)
3. Check system FD usage: sysctl -n kern.num_files
4. Find the leaking processes:

pgrep -f "com.apple.Virtualization.VirtualMachine" | while read pid; do
    count=$(lsof -p "$pid" 2>/dev/null | wc -l | tr -d ' ')
    project=$(lsof -p "$pid" 2>/dev/null | grep "claudevm.bundle" | head -1 | \
        sed -n 's|.*Claude-\([^/]*\)/vm_bundles.*|\1|p')
    uptime=$(ps -o etime= -p "$pid" 2>/dev/null | tr -d ' ')
    echo "PID=$pid Project=${project:-unknown} FDs=$count Uptime=$uptime"
done

1. Sample the FD types being leaked:

lsof -p <any_vm_pid> 2>/dev/null | awk '{print $5}' | sort | uniq -c | sort -rn | head -5
# Output shows mostly REG and DIR entries spanning the entire home directory

Impact

When the system FD limit is reached:

• All processes fail with ENFILE (not just Claude)
• PM2-managed services crash and cannot restart
• Terminal commands (ls, cat, etc.) fail with "Operation not permitted"
• Only fix is restarting Claude Desktop (or rebooting)
• This happens every 2-3 days with 4 projects open

What Should Happen?

VM processes should not accumulate unbounded file descriptors. FDs should be released after use, or the VM filesystem scan should be scoped to the project directory rather than traversing the entire home directory.

Workaround

We built a cron-based FD pressure monitor (every 10 minutes) that:

1. Checks system FD count against thresholds (WARNING at 350K, CRITICAL at 450K)
2. Shows a macOS dialog identifying which specific Claude Desktop project VM has the most FDs
3. Sends a push notification as backup

This gives enough warning to save work and restart Claude Desktop before the system crashes.

Error Messages/Logs

ENFILE: file table overflow
Error: Working directory "/path/to/project" no longer exists.
ls: .: Operation not permitted
error: An unknown error occurred, possibly due to low max file descriptors

Environment

• macOS 26.3 (Build 25D125)
• Apple Silicon (M-series)
• Claude Desktop (latest as of March 1, 2026)
• kern.maxfiles: 524,288
• kern.maxfilesperproc: 245,760