[BUG] EDEADLK on all pre-existing files in user-mounted folders after session resume (Cowork mode)

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?

In Cowork mode, after resuming a session that was created under app version 2.1.170 with the current version 2.1.187, all read() calls on pre-existing files in user-mounted folders (added via --add-dir) fail with EDEADLK (errno 35, "Resource deadlock avoided").

The previous session on the same project survived 4 version upgrades (2.1.142 through 2.1.170) across 5 dates with zero EDEADLK errors on the same mounted folder.

Affected: user-mounted folders only. System-managed mounts (.auto-memory, .claude/skills) work fine on the same session.

Symptoms:

• open() succeeds on affected files, read() fails with errno 35
• stat() returns Blocks: 0 on affected files (incorrect for files with known non-zero size)
• Files created during the resumed session read/write normally on the same FUSE mount
• rm returns "Operation not permitted" on all files regardless of age
• ls, stat, mv (rename) work on all files
• /proc/self/fd/3 points to /proc/121/fd but PID 121 does not exist
• /dev/fuse does not exist in the sandbox
• 15 FUSE connections active in /sys/fs/fuse/connections/ (42-56)

Session ID: 6481a952-903c-437e-a9ea-15892afd993d
Previous (working) session ID: 04073348-cf9d-411c-ac81-24b552c1d11c

Version history (previous session, zero deadlocks):
May 20: 2.1.142 | Jun 2-3: 2.1.160 | Jun 7: 2.1.165 | Jun 15: 2.1.170

Version history (current session, deadlocked):
Jun 16: 2.1.170 (worked) | Jun 27: 2.1.187 (all pre-existing file reads fail)

What Should Happen?

Resuming a Cowork session should allow reading all files in user-mounted folders, regardless of whether they existed before the resume or were created after. The file system bridge should fully re-initialize file handles for user-mounted directories on session resume, the same way it does for system-managed mounts.

Error Messages/Logs

$ cat '/sessions/compassionate-happy-brown/mnt/FTC Portugal Off-Season Event/2026-03-29_Style_Guidelines.md'
cat: '/sessions/compassionate-happy-brown/mnt/FTC Portugal Off-Season Event/2026-03-29_Style_Guidelines.md': Resource deadlock avoided

$ python3 -c "
import os
fd = os.open('...Style_Guidelines.md', os.O_RDONLY)
print(f'open() SUCCEEDED, fd={fd}')
data = os.read(fd, 10)
"
open() SUCCEEDED, fd=3
OSError: [Errno 35] Resource deadlock avoided

$ stat '...Style_Guidelines.md'  # PRE-EXISTING, BROKEN
  Size: 22839       Blocks: 0          IO Block: 4096   regular file

$ stat '...CLAUDE.md'  # CREATED THIS SESSION, WORKS
  Size: 12510       Blocks: 32         IO Block: 4096   regular file

$ ls -la /proc/self/fd/3
/proc/self/fd/3 -> /proc/121/fd

$ ls /proc/121/
ls: cannot access '/proc/121/': No such file or directory

$ ls /dev/fuse
ls: cannot access '/dev/fuse': No such file or directory

Steps to Reproduce

1. Open the Claude desktop app (Cowork mode) with a user-selected folder mounted via the standard folder picker
2. Start a Cowork session. All files in the mounted folder are readable (Read tool, cat, head, etc. all work)
3. Work in the session over multiple days. Session survives app version upgrades (tested: 2.1.142 through 2.1.170, all fine)
4. Session context compacts (automatic, after extended use). Session resumes normally
5. Claude desktop app updates from version 2.1.170 to 2.1.187 between sessions
6. Resume the same session after the app update
7. Attempt to read ANY pre-existing file in the user-mounted folder:

$ cat "/sessions/.../mnt/ProjectFolder/any-file.md"
cat: error reading: Resource deadlock avoided

1. Result: EDEADLK (errno 35) on ALL pre-existing files in user-mounted folders. Files created during the current session work fine.

Reproduction rate: 100% after session resume on version 2.1.187

Key diagnostics:

• stat on affected files shows Blocks: 0 (vs normal nonzero for readable files)
• open() succeeds but read() fails with errno 35
• Files in system-managed mounts (.auto-memory/, .claude/) are NOT affected
• Only user-mounted folder files (the folder selected in Cowork UI) are affected
• Previous session (different session ID) survived 4 app version upgrades (2.1.142 to 2.1.170) with zero EDEADLK errors
• Current session worked fine on 2.1.170 (Jun 16), broke on 2.1.187 (Jun 27)

Related: This appears to be the same root cause as #26369, which was auto-closed as duplicate of #23795. However, #23795 ("Incomplete bug report submission") does not appear to be the correct parent issue. This report provides additional version-correlation data.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.170

Claude Code Version

2.1.187 (Claude Desktop / Cowork mode)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Context: This is Cowork mode (Claude Desktop app), not CLI Claude Code. The user selected a project folder via the Cowork folder picker UI. The session ran successfully across multiple days and multiple app version upgrades (2.1.142 through 2.1.170) before the EDEADLK appeared.

Version correlation data (mined from session transcript JSONL files):

• Previous session (ID: 04073348): app versions 2.1.142, 2.1.160, 2.1.165, 2.1.170 across May 20 - Jun 15. Zero EDEADLK errors across 83MB of transcript.
• Current session (ID: 6481a952): version 2.1.170 on Jun 16 (files worked), version 2.1.187 on Jun 27 (all pre-existing files deadlocked). 4 context compactions occurred before the first EDEADLK.

Sandbox details:

• /proc/self/fd/3 symlinks to /proc/121/fd but PID 121 does not exist in the sandbox
• /dev/fuse does not exist in the sandbox
• Sandbox runs inside bwrap (bubblewrap) with --unshare-pid, --unshare-net
• Mount type for user folder: fuse.bindfs (same type as .claude/ which works fine)

Impact: Cannot read any pre-existing project files. Cannot append to them. Cannot delete them (rm returns "Operation not permitted"). Can only create new files and read those. Workaround: start a new session (loses conversation context).

Related issue: #26369 (identical symptoms, auto-closed as duplicate of #23795 which appears to be a false match)