[BUG] Cowork (macOS): connected folders are no longer writable-mounted into the workspace sandbox since the new mandatory write-consent (~Jul 8, 2026) — device bridge works, but in-place editing is gone
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?
Summary
Since ~2 days ago (around July 8, 2026, concurrent with the Chat + Cowork "Home" merge), connecting a folder in Cowork shows a new, mandatory prompt asking whether Claude may write to that folder (declining means the folder is not connected at all). Write consent was granted, and writing does work via device_commit_files. However, the folder is no longer mounted writable into the workspace sandbox.
In earlier Cowork sessions the same folder was mounted writable into the workspace, so the ordinary sandbox shell (workspace bash) could edit files in place with sed/direct writes, and the Cowork review UI (view file content + inline comments) was available at the same time. Now new sessions provide only the read-only bridge (device_stage_files) plus the device_commit_files round-trip. In-place editing is gone, and each edit forces a SendUserFile → commit round-trip that flips the right-hand preview from the local file to a remote copy.
The write-consent prompt appears to enable only the bridge commit path, not the previous writable mount.
Environment
- Product: Claude Cowork (Desktop app, macOS) — same product surface as the previously working session
appVersion: 1.20186.0 (Electron 42.5.1, Node 24.17.0) — fromget_device_info- OS: macOS, Apple Silicon (darwin, arm64)
- Device:
macbook-air-local - Connected folders:
/Users/mseemann/claude/bugs,/Users/mseemann/claude/bugs2,/Users/mseemann/claude/bugs3
What works (verified this session)
get_device_info✅ — reports the connected folder(s)device_list_dir✅ — reads the connected foldersdevice_stage_files✅ — stages a read-only copy under/mnt/user-data/uploads/<folder>/device_commit_files✅ — writes back to real disk (verified: the committed file actually appears in Finder)
What is broken / missing
- No writable workspace mount. Under
/mnt/onlyuser-dataexists (the staged copies)./Users/mseemann/claude/bugs*do not exist as paths inside the sandbox;mount/findmntshow no entry for these folders. - A write into the staged copy (
/mnt/user-data/uploads/bugs/_writetest.txt) reported "OK" sandbox-side but did not appear on the device (device_list_diron/Users/mseemann/claude/bugsdid not show it). The staged copy is decoupled from the real disk, soworkspace bash/sedonly mutates a dead copy. - The only real write path to disk is
device_commit_files, which requires aSendUserFile-producedfileUuid. BecauseSendUserFiledelivers a fresh remote copy, the right-hand preview switches from the local file (button "Reveal in Finder") to the remote copy (button "Download and open"), and scroll position is lost.
Likely trigger
The new mandatory write-consent prompt introduced ~Jul 8, 2026. Consent is required to connect the folder at all; granting it enables device_commit_files (writes reach disk) but does not result in a writable in-sandbox mount. This strongly suggests the consent/permission rework switched folder writes from a writable mount to the bridge commit model.
Reproduction
- In the Cowork desktop app, add a local folder → the new mandatory "allow Claude to write to this folder?" prompt appears; confirm "allow" (declining means the folder is not connected).
- Open a new Cowork session.
- Check whether the folder is writable-mounted in the sandbox (
mount/findmnt, or a write test cross-checked on the device viadevice_list_dir) → no mount; a write into the staged copy never reaches the device; the only real write path isdevice_commit_filesvia aSendUserFilefileUuid. - Edit a file and commit it back → the right-hand preview immediately switches from the local file to the remote copy ("Reveal in Finder" → "Download and open"), scroll position lost.
- Identical on multiple folders, including one added mid-session (
bugs,bugs2,bugs3) → session-wide and folder-independent; reconnecting does not fix it.
Impact
The Cowork review UX (view content + inline comment) and in-place editing of connected local files can no longer coexist. Reading/commenting works; the moment a file is edited, the preview flips to the remote copy. Reconnecting or adding a fresh folder does not restore the writable mount.
Secondary note (not the cause)
device_bash is absent in this session (No such tool available: mcp__remote-devices__device_bash; also No matching deferred tools found via ToolSearch select), as are project_memory_read/project_memory_write. These are not the cause of the broken workflow — the previous working session did not use device_bash either; it relied on the writable workspace mount. Listed only because it shows the same "worked before, gone after the ~Jul 8 change" signature.
Distinction from existing issues (same July regression wave, different failure mode)
- Not #76095 / #76054 / #76259 / #75625: there the device bridge tools themselves are never provisioned (
device_list_dir/stage/commitall fail). Here those tools work fine; what's missing is the writable workspace mount. - Not #76187: there
connectedFoldersis empty and the folder is fully non-functional. Hereget_device_inforeports the folders and the bridge works. - Not #45433 / #69866 / #40264: there the mount exists but serves stale/truncated content. Here the mount is entirely absent — the session fell back to the pure stage/commit bridge.
Related issues
#76187, #76183, #75603, #76095, #76054, #76259, #75625, #45433, #75814 (feature: one synced session with local execution at desktop)
What Should Happen?
After granting the mandatory write consent, a Cowork session should mount the connected folder writable into the workspace sandbox (as it did before the ~Jul 8, 2026 change), so that:
- The sandbox shell (
workspace bash) can edit files in place (sed/direct writes) and those changes land on the real disk directly — without aSendUserFile→device_commit_filesround-trip. - The Cowork review UI (view file content + inline comments) stays available at the same time, and editing a file updates the existing local-file view in place instead of switching the preview to a remote copy and losing scroll position.
In short: granting write access should restore the writable workspace mount, not merely enable the read-only stage + commit bridge. Read/comment and in-place editing of connected local files should coexist, as they did in earlier Cowork sessions.
Error Messages/Logs
Steps to Reproduce
Reproduction
- In the Cowork desktop app, add a local folder → the new mandatory "allow Claude to write to this folder?" prompt appears; confirm "allow" (declining means the folder is not connected).
- Open a new Cowork session.
- Check whether the folder is writable-mounted in the sandbox (
mount/findmnt, or a write test cross-checked on the device viadevice_list_dir) → no mount; a write into the staged copy never reaches the device; the only real write path isdevice_commit_filesvia aSendUserFilefileUuid. - Edit a file and commit it back → the right-hand preview immediately switches from the local file to the remote copy ("Reveal in Finder" → "Download and open"), scroll position lost.
- Identical on multiple folders, including one added mid-session (
bugs,bugs2,bugs3) → session-wide and folder-independent; reconnecting does not fix it.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
1.20186.0*
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_