Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] # VirtioFS deadlock (errno 35) in Claude Desktop cowork sessions — files unreadable after first access [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48043•Fetched 2026-04-15 06:34:56
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
gtrideoutgtrideout
Participants
github-actions[bot]github-actions[bot]gtrideoutgtrideout
Timeline (top)
labeled ×4commented ×1

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).

Error Message

  • 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.

Root Cause

Likely root cause

Fix Action

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.

Code Example

#!/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

---

# 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

---
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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

extent analysis

TL;DR

The most likely fix involves addressing the VirtioFS implementation issue in Apple's Virtualization.framework, which causes a kernel-level inode reference conflict when both the host and guest VM access the same file.

Guidance

  • Investigate the VirtioFS implementation in Apple's Virtualization.framework to identify the root cause of the inode reference conflict.
  • Consider implementing a mechanism to refresh or release kernel-level inode references when the host or guest VM accesses a file, to prevent stale vnode cache entries.
  • Evaluate the provided workaround script that rotates every file's inode by copying, deleting, and re-copying, as a temporary solution to mitigate the issue.
  • Collaborate with Apple or the Virtualization.framework community to resolve the underlying issue, as similar reports exist for Docker Desktop and other consumers.
  • Test and verify any potential fixes or workarounds to ensure they resolve the deadlock issue and allow for concurrent file access between the host and guest VM.

Example

The provided workaround script can be used as a temporary solution:

#!/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 script should be run before each desktop app session to rotate the inodes and prevent the deadlock.

Notes

The issue is specific to the VirtioFS implementation in Apple's Virtualization.framework and may require collaboration with Apple or the community to resolve. The provided workaround script is not a permanent fix and may have performance implications.

Recommendation

Apply the workaround script as a temporary solution to mitigate the issue, while investigating and addressing the underlying VirtioFS implementation issue in Apple's Virtualization.framework. This will allow users to continue using the cowork mode, albeit with some limitations, until a permanent fix is available.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

#api#search optimization#API routing#API middleware#SSR setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING