Cowork filesystem-type block ignores ST_RDONLY and host-side ACLs, breaking read-only cloud storage mounts

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?

Cowork's request_cowork_directory rejects all virtual/cloud-based filesystems based on f_type detection via statfs(), regardless of whether the mount is read-only or the host-side ACLs prevent write operations. This is an over-broad restriction that breaks legitimate, security-hardened workflows.\n\n## Background\n\nWe understand the safety motivation — the iCloud data destruction incident (#32637) where Cowork's Linux VM saw 0-byte dehydrated stubs and rm -rf propagated deletions through cloud sync is a serious concern. That was a write/delete problem. The current fix blocks all virtual filesystem types indiscriminately, including configurations where write operations are impossible.\n\n## Our Configuration\n\nWe use Google Drive for Desktop in streaming mode, which mounts shared drives locally via Apple's File Provider framework (macOS) and a virtual filesystem driver (Windows). We engineered a layered access control model using a dedicated Non-Person Entity (NPE) service account with Google Workspace ACLs:\n\n- Four shared business drives: NPE has Viewer access only. Google Drive's Viewer role prohibits all file creation, modification, and deletion at the API level. This is enforced by Google's infrastructure — the destructive scenario from #32637 is impossible at the permission layer.\n- One dedicated AI operations drive: NPE has Content Manager access. This drive exists solely for AI-generated work product (indexes, session artifacts). It contains no user data. Write access here is intentional and controlled.\n\nThis configuration was working as recently as April 1. On April 2, all five drives were rejected by request_cowork_directory without notice.\n\n## Confirmed on Both Platforms\n\n- macOS: Direct mount via folder picker — rejected. Symlinks from a standard local directory to the Google Drive path — also rejected (fs.realpath() resolves to the virtual filesystem target before validation).\n- Windows: Same rejection. This confirms the block is filesystem-type detection, not a path-string filter.\n\n## The Technical Issue\n\nThe statfs() check evaluates f_type (filesystem magic number) and rejects anything that isn't a recognized local filesystem. It does not check ST_RDONLY mount flags. This means:\n\n- A read-only virtual filesystem mount (where write/delete is physically impossible) is treated the same as a writable one\n- Host-side ACLs (Google Drive Viewer permissions, macOS ACLs) are invisible to the check\n- The restriction also presumably blocks NFS, SMB, FUSE volumes (sshfs, encrypted volume managers), and external drives with non-standard filesystems\n\n## Google Drive MCP Is Not a Workaround\n\nThe Google Drive MCP connector does not address this gap:\n\n1. Read limitations: google_drive_search and google_drive_fetch can only access native Google Docs. Shared drives commonly contain .md, .pdf, .xlsx, .vtt, and other non-native file types that the MCP cannot read.\n2. No write capability: The MCP provides no ability to create or update documents. Workflows that require writing back to a controlled location have no MCP equivalent.\n\n## Anthropic's Own Documentation Supports This Pattern\n\nThe Securely Deploying AI Agents documentation explicitly recommends read-only filesystem mounts as a security best practice (e.g., docker run -v /path:/workspace:ro). The current f_type block in Cowork prevents users from following this recommended pattern with cloud-synced storage.">

What Should Happen?

Cowork should allow mounting virtual/cloud-based filesystems when they are safe. Proposed solutions:\n\n1. Check ST_RDONLY mount flags — if a virtual filesystem is mounted read-only, allow it. The data destruction risk is a write problem, not a read problem.\n2. Explicit opt-in for writable virtual mounts — present a risk acknowledgment dialog rather than a silent block.\n3. Admin trust configuration for Team/Enterprise plans — allow account administrators to declare trusted mount paths, shifting liability to the account owner. This is a standard enterprise pattern that preserves Anthropic's default safety for all other users.\n\nThis would restore access for users who have already mitigated the data destruction risk through host-side permission controls, while maintaining the default safety behavior for everyone else.">

Error Messages/Logs

Error from request_cowork_directory: "Cannot mount a Library directory"\n\nThis error appears on macOS when attempting to mount any path under ~/Library/CloudStorage/ (where Apple's File Provider framework requires all cloud storage providers to mount).\n\nOn Windows, a similar rejection occurs with Google Drive virtual filesystem paths.

Steps to Reproduce

1. Install Google Drive for Desktop (streaming mode) on macOS or Windows\n2. Ensure shared drives are accessible locally (macOS: ~/Library/CloudStorage/GoogleDrive-user@domain/; Windows: virtual drive letter or similar)\n3. Open Cowork and use request_cowork_directory (folder picker) to select any Google Drive folder\n4. Observe rejection — macOS shows "Cannot mount a Library directory"\n5. Create a symlink from a standard local directory (e.g., ~/Documents/test-link) pointing to the Google Drive path\n6. Attempt to mount the symlink path — also rejected, as fs.realpath() resolves to the virtual filesystem target before validation\n7. Repeat steps 3-4 on Windows — same rejection confirms filesystem-type detection, not path-string filtering\n\nNote: These same paths mounted successfully via request_cowork_directory as recently as April 1, 2026. Nothing changed on the client side.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Version working as of April 1, 2026 — exact version number unknown

Claude Code Version

Cowork (Claude Desktop) — latest version as of April 3, 2026

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Cross-Platform\n\nThis issue is confirmed on both macOS and Windows. macOS selected above as primary test platform, but the identical rejection occurs on Windows with Google Drive's virtual filesystem driver.\n\n## Related Issues\n\n- #32637 — iCloud data destruction incident (likely the motivation for this restriction)\n- #25293\n- #29914\n\n## Impact\n\nThis affects any Cowork user on any platform who relies on cloud-synced storage (Google Drive, Dropbox, OneDrive, iCloud) or network-attached storage (NFS, SMB). The same f_type check presumably blocks all FUSE-mounted volumes including sshfs and encrypted volume managers.\n\nWe are a paying Team plan customer (5 seats, Advanced tier) who built, tested, and then upgraded our subscription specifically based on this capability working. This broke a core daily business workflow without notice, without a migration path, and without an alternative.">