[BUG] File read failure on macOS FileProvider-backed paths (Google Drive, iCloud, etc.)

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?

Summary

When a user mounts a folder that resides on a macOS FileProvider-backed filesystem (e.g., Google Drive, iCloud Drive, Dropbox, OneDrive), Cowork's sandbox can list directory contents and read file metadata, but all attempts to read file contents fail with EDEADLK (errno 35, "Resource deadlock avoided"). This makes cloud-storage-backed folders effectively unusable as Cowork workspace folders.

Environment

• Cowork sandbox: Ubuntu 22 Linux VM (ext4 on NVMe)
• User filesystem: macOS with Google Drive (FileProvider)
• Mount mechanism: fuse.bindfs via Cowork's network bridge
• Mount entry: bindfs /sessions/.../mnt/Funny fuse.bindfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other

Observed Behavior

Directory listing works:

$ ls -la /sessions/.../mnt/Funny
total 4
drwx------    12 user user     384 Aug 11  2011 .
-rw-------     1 user user   13618 Aug 25  2004 olympicmoment.html
-rw-------     1 user user  240764 Oct 13  2008 screenshot.png
... (10 files visible)

File metadata works:

$ stat /sessions/.../mnt/Funny/olympicmoment.html
  File: /sessions/.../mnt/Funny/olympicmoment.html
  Size: 13618       Blocks: 0          IO Block: 4096   regular file
  Access: (0600/-rw-------)
  Modify: 2004-08-25 12:36:18.000000000 -0400

Note: Blocks: 0 is a telltale sign of a dataless/dehydrated FileProvider file.

File reads fail:

$ cat /sessions/.../mnt/Funny/olympicmoment.html
cat: Resource deadlock avoided
 
$ cp /sessions/.../mnt/Funny/olympicmoment.html /tmp/
cp: error reading '...': Resource deadlock avoided
 
$ dd if=/sessions/.../mnt/Funny/olympicmoment.html of=/tmp/test
dd: error reading '...': Resource deadlock avoided
0+0 records in, 0+0 records out
 
$ python3 -c "import os; fd=os.open('...', os.O_RDONLY); os.read(fd, 1024)"
OSError: [Errno 35] Resource deadlock avoided

Every method of reading file contents — cat, cp, dd, Python os.read(), Node.js fs.readFileSync() — fails with the same errno 35.

What Should Happen?

File contents should be readable, just as they are when the folder is on a local (non-cloud) macOS filesystem.

Error Messages/Logs

See above.

Steps to Reproduce

1. On macOS, ensure Google Drive is installed and syncing via FileProvider (the default for modern Google Drive installations, which stores files under ~/Library/CloudStorage/GoogleDrive-*/).
2. In Cowork, select a folder from within Google Drive as the workspace folder.
3. Attempt to read any file in the mounted folder.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude 1.1.9493 (b58a0b) 2026-03-29T03:33:07.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Root Cause Analysis

macOS FileProvider is a virtual filesystem where files can be "dataless" (dehydrated). The directory entry and metadata are cached locally, but the actual file content resides on the cloud provider's servers and is only downloaded ("materialized") on demand when a process reads the file.

The architecture of the mount is:

Mac folder (FileProvider/Google Drive)
    -> Cowork network bridge (Mac-side daemon)
        -> bindfs (FUSE, Linux VM)
            -> sandbox process read()

When a read() syscall reaches the Mac side of the bridge, the FileProvider extension needs to download the file content from Google Drive before it can serve the data. This on-demand materialization appears to deadlock or fail within the bridge's process context, likely because:

1. The bridge is not using NSFileCoordinator for file access. macOS requires coordinated file access for FileProvider-backed files. Without coordination, the FileProvider extension may not be triggered to materialize the content, or the read may conflict with the FileProvider's internal locking.

1. The bridge may be holding a lock while issuing a synchronous read. If the FileProvider needs to call back into the same process or locking domain to signal completion, this creates a classic deadlock (hence EDEADLK).

1. The Blocks: 0 in stat output confirms the files are dehydrated. The metadata is available from the local FileProvider cache, but no data blocks are allocated because the content hasn't been downloaded.

Proposed Fixes

Fix 1: Use NSFileCoordinator (Recommended)

The Mac-side bridge component should wrap all file reads in an NSFileCoordinator coordinated read:

NSFileCoordinator *coordinator = [[NSFileCoordinator alloc] initWithFilePresenter:nil];
[coordinator coordinateReadingItemAtURL:fileURL
                                options:0
                                  error:&error
                             byAccessor:^(NSURL *newURL) {
    // FileProvider has materialized the content; read from newURL
    NSData *data = [NSData dataWithContentsOfURL:newURL];
    // ... send data through the bridge
}];

This tells macOS "I need this file's content now" and the system ensures the FileProvider extension downloads it before the accessor block runs. This is the correct and Apple-recommended approach for accessing FileProvider-managed files.

Scope: All user-mounted folder reads should go through NSFileCoordinator, not just cloud-backed ones. This is safe for local files too (it's a no-op for non-coordinated files) and future-proofs against any file coordination issues.

Fix 2: Explicit Materialization on Mount

When a user selects a folder under ~/Library/CloudStorage/ (the standard macOS path for FileProvider-based storage), the Cowork desktop app could proactively materialize files using the FileProvider APIs:

let manager = NSFileProviderManager(for: domain)
// Request download of items before exposing through bridge

Trade-off: This could be slow for large folders and would download files the user may never access. Better suited as an opt-in behavior or applied lazily on first access.

Fix 3: Retry on EDEADLK (Quick Patch)

If the bridge receives EDEADLK from the Mac filesystem, it could retry with exponential backoff (e.g., 100ms, 500ms, 2s). The initial read attempt may trigger FileProvider to begin downloading, and a retry might succeed once the content is available.

Trade-off: Unreliable — the materialization may take longer than any reasonable retry window, and it doesn't address the underlying coordination issue.

Fix 4: Detection and User Warning (Minimum Viable)

At minimum, detect when a mounted path is under ~/Library/CloudStorage/ and display a warning to the user that cloud-storage-backed folders may not work correctly. This prevents user confusion while a proper fix is developed.

Affected Providers

This likely affects all macOS FileProvider-based cloud storage, including:

• Google Drive (confirmed)
• iCloud Drive
• Dropbox (modern versions use FileProvider)
• OneDrive
• Box Drive
• Any third-party app using the macOS FileProvider API

Additional Notes

• The .gdoc files in the test folder (Google Docs shortcut files) would have the same read issue, though those are just small JSON pointers and not typically useful outside of Google's ecosystem.
• The subfolder in the test directory showed 65535 links in ls output, which is another artifact of the FileProvider virtual filesystem not reporting accurate link counts.
• This issue would not affect files that are already "pinned" or downloaded locally by Google Drive's "Available offline" feature, since those files would have their content blocks allocated locally. However, Cowork should not depend on this user-side workaround.

Related

• #29914