[BUG] # VirtioFS deadlock (errno 35) in Claude Desktop cowork sessions — files unreadable after first access

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?

VirtioFS deadlock (errno 35) in Claude Desktop cowork sessions — files unreadable after first access

Summary

The Claude Desktop app's cowork/local agent mode runs a Linux VM via Apple's Virtualization.framework with VirtioFS file sharing. Files shared into the VM become permanently unreadable (errno 35, EDEADLK — "Resource deadlock avoided") after being accessed by the host macOS. The deadlock persists across app restarts, new conversations, and VM reboots. Only a full system reboot or manual inode rotation clears it.

This makes cowork mode unreliable for any workflow where files are also accessed on the host (by the CLI, editors, or other tools).

Environment

• Claude Desktop: v1.2278.0
• macOS: 26.2 (build 25C56)
• Hardware: MacBook Pro M3 Pro, 18 GB RAM
• VM process: com.apple.Virtualization.VirtualMachine using claudevm.bundle
• Shared folder: /Users/gtr20/Documents/Claude (set via userSelectedFolders in session config)

Steps to reproduce

1. Open a cowork session in Claude Desktop with a folder shared (e.g. /Users/gtr20/Documents/Claude)
2. From the host macOS, read or edit any file in that folder (via CLI, terminal, text editor — anything)
3. In the cowork session, ask Claude to read that same file
4. Result: Claude reports a filesystem lock / cannot read the file. The VM gets errno 35 (EDEADLK) on the VirtioFS mount.

Observed behavior

• New files written by the VM itself are readable. The deadlock only affects files whose inodes were accessed by the host.
• The deadlock is per-inode, not per-path. Proof: deleting a file and recreating it at the same path (which assigns a new inode) makes it readable again — until the host touches it.
• The deadlock survives: app quit + relaunch, killing the VM process (com.apple.Virtualization.VirtualMachine), starting new conversations within the same cowork session.
• The deadlock does NOT survive: full system reboot, or manual inode rotation (delete + recreate every file).
• The Claude Desktop app surfaces this as "I'm running into a filesystem lock on all the files in your workspace" and falls back to working without file access.

Expected behavior

Files shared via VirtioFS should remain readable by the VM regardless of host access. The host and guest should be able to read/write the same files concurrently.

Workaround

A script that rotates every file's inode by copying, deleting, and re-copying:

#!/bin/bash
cd /Users/gtr20/Documents/Claude || exit 1
find . -type f | while read f; do
  tmp="/tmp/_inode_rotate_$$_$(basename "$f")"
  cp "$f" "$tmp" && rm "$f" && mv "$tmp" "$f"
done

This must be run before each desktop app session. It is not a fix — the deadlock will recur as soon as the host accesses any file again.

Diagnostic evidence

# Host lsof shows the VM has the shared directory open:
com.apple  [PID] gtr20  14r  DIR  1,13  /Users/gtr20

# No file-level locks exist (tested with fcntl.LOCK_EX|LOCK_NB on every file — all pass)
# No lock files present in the directory
# The deadlock is at the kernel VirtioFS layer, not userspace

Impact

This effectively breaks cowork mode for users who also use Claude Code CLI, text editors, or any other tool on the same files — which is likely most users. The $20/month Pro plan's flagship collaborative feature becomes unusable for real workflows where files are actively being worked on.

Likely root cause

Apple's Virtualization.framework VirtioFS implementation appears to hold kernel-level inode references that conflict when both the host and guest VM access the same file. This is consistent with known VirtioFS issues on macOS (similar reports exist for Docker Desktop and other Virtualization.framework consumers). The per-inode nature of the deadlock and the fact that it survives process restarts but not reboots points to stale vnode cache entries in the kernel's VFS layer.

What Should Happen?

Files shared via VirtioFS should remain readable by the VM regardless of host access. The host and guest should be able to read/write the same files concurrently.

Error Messages/Logs

Steps to Reproduce

Open a cowork session in Claude Desktop with a folder shared (e.g. /Users/gtr20/Documents/Claude)
From the host macOS, read or edit any file in that folder (via CLI, terminal, text editor — anything)
In the cowork session, ask Claude to read that same file
Result: Claude reports a filesystem lock / cannot read the file. The VM gets errno 35 (EDEADLK) on the VirtioFS mount.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.2278.0 (e5213f) 2026-04-13T17:49:21.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_