[BUG] Cowork (macOS): connected folder still mounted read-only in sandbox despite #76344 being closed as completed

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?

What's Wrong?

The issue described in #76344 (connected folders no longer writable-mounted into the workspace sandbox) persists as of September 9, 2026. That issue was closed as completed on July 17, but the behavior is unchanged on my machine.

Key observations from my session:

1. The FUSE mount reports rw (read-write), but the filesystem owner is user_id=0 (root) while the sandbox process runs as uid=1017. The folder permissions are drwx------ (owner-only), so the sandbox user cannot write despite the mount allowing it.

1. Both Write (file tool) and bash (shell) fail with Permission denied when targeting the connected folder.

1. The outputs directory is writable — the permission issue is specific to connected folders.

1. Root-level folders like Desktop and Downloads work fine as connected folders (writing succeeds). The problem appears when connecting subfolders (e.g., ~/Desktop/Claude Masterclass Materials/).

1. The behavior is intermittent — the same folder was writable earlier today in a different session, without any app version change.

Mount output confirming the issue:

/proc/self/fd/3 on /sessions/.../mnt/Claude Masterclass Materials type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

The mount says rw but user_id=0 + default_permissions + drwx------ on the directory means only root can write. The sandbox user (uid=1017) is denied.

Environment

• Product: Claude Cowork (Desktop app, macOS)
• OS: macOS Darwin 25.3.0, Apple Silicon
• Date: September 9, 2026
• Related issue: #76344 (closed as completed Jul 17, but behavior persists)

Is this a regression?

Yes — this is the same regression described in #76344, which was closed but not fully resolved.

What Should Happen?

Connected folders should be writable in the sandbox, as they were before the July 8 regression and as root-level folders (Desktop, Downloads) still are. The FUSE mount permissions should match the sandbox user's uid, or the directory permissions should allow the sandbox user to write.

Error Messages/Logs

Steps to Reproduce

1. Open Cowork on macOS
2. Connect a subfolder (not Desktop/Downloads directly, but a folder inside them — e.g., ~/Desktop/My Project/)
3. Start a new session
4. Attempt to create a file in the connected folder via Write tool or bash
5. Observe Permission denied
6. Verify with mount — the mount says rw but user_id=0 with default_permissions blocks the sandbox user

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.260.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_