[BUG] Cowork device bridge: iCloud-evicted files list normally but are unreadable, with no way to materialise

Product: Claude Cowork, device bridge / connected folders (macOS desktop app)
Date observed: 2026-08-10 · App version: 1.26832.0 (Electron 42.7.0), macOS arm64

Summary

A connected folder inside iCloud Drive lists normally and reports plausible file sizes, but
every file is unreadable: staging reports a cloud placeholder, and shell reads fail with
Resource deadlock avoided. There is no way to trigger materialisation from the session,
and nothing in the directory listing indicates the contents are not present.

Reproduction

1. Connect a folder that lives in iCloud Drive and whose contents have been evicted

("Optimize Mac Storage").

1. List it — this succeeds and looks entirely normal:

device_list_dir ~/Documents/<folder>
→ {"name":"App.tsx","type":"file","size":2487,"mtimeMs":...}

1. Try to read or stage anything:

$ head -c 120 src/App.tsx
head: error reading 'src/App.tsx': Resource deadlock avoided

$ tar czf /tmp/x.tar.gz .
tar: ./src/App.tsx: Read error at byte 0, while reading 2487 bytes: Resource deadlock avoided
   (repeated for every file)

device_stage_files [...]
→ Error: /Users/<user>/Documents/<folder>/README.md is a cloud placeholder
  (not downloaded). Open it in Finder to download it first.

A sibling folder in the same parent directory, not evicted, reads perfectly — so this is
per-file eviction state, not a permissions or path problem.

Expected

At least one of:

• device_list_dir marks files whose contents are not local, so the state is visible before

a read is attempted rather than after;

• the bridge triggers materialisation on read (macOS supports this — an ordinary local app

opening the file causes a download);

• the shell-side error names the actual cause. Resource deadlock avoided is technically

what the syscall returned, but it gives no hint that the fix is "download the file".

Impact

Blocked a code review entirely. The failure mode is also misleading in a specific way:
because listing works and sizes look right, the natural first hypothesis is that the files
are empty or that something is wrong with the analysis, not that the bytes are elsewhere. I
spent several attempts on the wrong theory before staging returned the placeholder message,
which was the only output that named the real cause.

Workaround

The user opens the folder in Finder and forces a download (select all → Download Now), or
disables "Optimize Mac Storage" for that folder. Neither is discoverable from the errors.