[BUG] Cowork (macOS): sandbox VM never releases host file handles in mounted folders. Blocks OneDrive "Free Up Space" and the handle count grows without limit

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

What's Wrong?

On macOS, the Cowork VM process (com.apple.Virtualization.VirtualMachine) keeps a read-only file descriptor open on every file and folder the sandbox has accessed in a mounted folder. It never closes them while Desktop is running. Archiving the sessions that touched the files releases nothing.

Consequences:

Cloud-storage "free up space" fails on any file the sandbox has touched. OneDrive Files On-Demand eviction (FileManager.evictUbiquitousItem, the same operation as Finder's Free Up Space) is refused with NSCocoaErrorDomain 255 (file locking error), because macOS won't evict an open file. Asking the agent to "close the file" can't help: the handle is on the host side of the share.
The number of open files only goes up.
The VM process has 27,745 open file descriptors. That's about three quarters of every open file on the Mac (kern.num_files 36,130), against a per-process limit of 61,440 (kern.maxfilesperproc).
One OneDrive folder mounted into sessions went from 1,081 handles on the first evening to 4,884 the next day.
A mounted project folder accounts for 22,752 of the total.
Left long enough, the VM process should run into the per-process limit (EMFILE), and the Mac could run short of files system-wide.
Nothing inside the sandbox can release them:

The sandbox user is unprivileged (uid=1089), so it can't run echo 2 > /proc/sys/vm/drop_caches.
The sandbox sees the folders as FUSE mounts served by coworkd, not the virtiofs share directly, e.g. /proc/self/fd/3 … fuse rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other.

Counts over time for the OneDrive folder (VM started 2026-09-24 18:30 BST, no restart since):

1,081 on the evening of 24 Sep
4,760 on 25 Sep
4,884 later that day
still 4,884 after archiving both sessions that had used the file, checked twice 75 s apart (last at 14:08 BST)

What Should Happen?

The host should only hold files the sandbox actually has open. Handles for files it merely looked up should be released, either promptly or when the session that touched them ends. Ending or archiving a session should, at minimum, release every handle taken for its mounts.

Error Messages/Logs

$ lsof -F pcf "<file in mounted OneDrive folder>"
p33013
ccom.apple.Virtualization.Virtua
f618
(in `lsof -p 33013` the same descriptor shows as 618r: open read-only)
evictUbiquitousItem → NSCocoaErrorDomain Code=255 (file locking error)
$ lsof -p 33013 | awk '/CloudStorage\/OneDrive-/' | wc -l
4884
$ lsof -p 33013 | tail -n +2 | wc -l
27749
$ sysctl kern.maxfilesperproc kern.maxfiles kern.num_files
kern.maxfilesperproc: 61440
kern.maxfiles: 122880
kern.num_files: 36130

Steps to Reproduce

In Cowork, give a session a local folder that holds many files (a project folder, or a OneDrive / iCloud Drive folder).
Ask the agent to search or read files in it, e.g. grep -r something ., or open a spreadsheet with Python.
On the Mac, run lsof -p "$(pgrep -f com.apple.Virtualization.VirtualMachine)" | wc -l. The count rises with every file touched and never falls.
Run lsof "<one of those files>". The VM process holds it open (r), long after the agent has finished with it.
Archive the session and wait. The count and the hold stay the same.
For a OneDrive Files On-Demand folder: right-click the file in Finder and choose Free Up Space, or call FileManager.evictUbiquitousItem(at:). It fails while the VM holds the file.
Quitting Desktop should release everything by stopping the VM, but that's the only release I have found.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.280 (as part of Claude Desktop 2.7032.0 )

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Other

Additional Information

The VM holds these files read-only (618r etc.), so there's no data-integrity problem. The cost is in eviction, and in the number of files the Mac has open.

The pattern looks like the virtiofs layer keeping a handle for every lookup the guest has made, which is never forgotten because the guest is under no memory pressure and ending a session doesn't unmount and forget its entries. That's inferred from the numbers, not from Desktop's code.

Possible fixes:
On session end, unmount the session's FUSE mounts and make sure the underlying virtiofs inodes are forgotten.
Periodically trim the guest's cache of looked-up files.
Close host handles for files that aren't open in the guest.