Cowork: `Read` fails with misleading `EINTR` on user-owned files created outside the Cowork session (correlates with `com.apple.macl` absence on macOS)

Summary

In Cowork mode (research preview, Claude desktop app on macOS), the Read tool fails with EINTR: interrupted system call on user-owned files that exist outside Cowork's own write history. The same file reads cleanly in vanilla Claude Code (CLI) and Terminal. EINTR is the wrong error code — it implies "transient, retry will succeed" — and sent diagnosis down two dead ends (xattr cleanup, chmod 644) before the actual pattern was found.

Empirically the gate correlates exactly with com.apple.macl extended-attribute presence: every file Cowork wrote itself carries com.apple.macl and reads fine; pre-existing user-owned files in the same directory lack com.apple.macl and fail. The Claude desktop app and its helper processes are not App-Sandboxed (no com.apple.security.app-sandbox entitlement, no ~/Library/Containers/Claude directory) and there are no kernel sandbox-deny entries in log show for the affected reads, so the gate appears to be in Cowork's bridge code rather than the kernel sandbox layer. Happy to redirect this issue if a public repo isn't the right channel.

Reproduction (macOS 26.4.1, arm64, Claude desktop 1.6608.2)

1. In Cowork, attempt Read on any user-owned file created outside Cowork (e.g., a .md in a normal git repo). Result: EINTR: interrupted system call, deterministic across many retries over 20+ minutes.
2. In the same Cowork session, write a probe file to the same directory via Write. Read on the probe succeeds immediately.
3. From Terminal: xattr -l <unreadable_file> shows no com.apple.macl. xattr -l <Cowork-written_file> shows com.apple.macl (72 bytes) plus com.apple.provenance (11 bytes).
4. Glob of the form **/*.md silently filters the unreadable file out (no error surfaced).
5. chmod 644 on the unreadable file: no effect. xattr -c to clear other xattrs: no effect.
6. Read in vanilla Claude Code (CLI, this is what I'm running in) reads the same file with no issue.

Evidence

Two adjacent files in the same directory, same POSIX mode (0644), same owner, same volume:

$ xattr -lx <Cowork-written-file>
com.apple.macl:
00000000  00 C1 47 87 82 7A E2 AE 49 30 AC 4E 25 CE 17 F1  |..G..z..I0.N%...|
00000010  10 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |.9..............|
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00                          |........|
00000048
com.apple.provenance:
(11 bytes; content elided — present on both readable and unreadable files,
so not material to the access decision)

$ xattr -l <unreadable-file>
(empty)

First 16 bytes of com.apple.macl are the granting container/app UUID: 00 C1 47 87 82 7A E2 AE 49 30 AC 4E 25 CE 17 F1. Engineering can compare against Cowork's bundle ID / sandbox container ID.

ls -le@O on both files shows no POSIX ACL (+) and no BSD flags (-). The com.apple.macl xattr is the only material filesystem difference.

log show --predicate 'subsystem == "com.apple.sandbox"' --last 4h returns no sandbox-deny entries naming the unreadable file path or the Claude process — consistent with the helpers not being App-Sandboxed (codesign -d --entitlements on Claude Helper (Renderer).app shows only com.apple.security.cs.allow-jit).

This points to Cowork's bridge implementing app-layer access control that gates on com.apple.macl (or correlates with it via some equivalent provenance check) rather than relying on a kernel sandbox.

Co-occurring symptom

mcp__workspace__bash was stuck at Workspace still starting for the entire affected session and never became usable. If workspace startup depends on enumerating or reading files in the project tree, a single unreadable path could plausibly wedge it. Worth checking; split into a separate issue if triage determines they're unrelated.

Suggested fixes (priority order)

1. Fix the error code. Surfacing a deterministic permission denial as EINTR is the highest-leverage fix — EACCES/EPERM or, better, a Cowork-specific message like Cowork can only read files it has provenance for; this file was created outside the Cowork session and lacks the required grant would let users self-diagnose in minutes instead of hours. Two debugging dead ends in the affected session came directly from EINTR implying "retry-safe transient failure."
2. Document the constraint. A short doc note explaining that Cowork's file bridge gates reads on files-it-wrote (or on macl provenance) would prevent the dead-end debugging path entirely.
3. Offer a workaround or grant flow. Either (a) a user-prompted "grant Cowork read access to this file" action, (b) a one-time cp through Cowork's own bridge to attach macl, or (c) a --grant flag at session start for the working directory. Today the only escape hatch is dropping to vanilla Claude Code.
4. Make Glob fail loudly on filtered-out files instead of silently dropping them, so users see the same root error and don't think the file is missing.

Environment

• Claude desktop 1.6608.2 (com.anthropic.claudefordesktop), team ID Q6L2SF6YDW
• macOS 26.4.1 (build 25E253), arm64
• Cowork mode in the research preview
• Reproduced 2026-05-11 against a normal user-owned git repo under ~/Documents/GitHub/

Filed from vanilla Claude Code (CLI), which can read all the affected files without issue.