[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

Open 💬 0 comments Opened Jul 10, 2026 by mseemann

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) — from get_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 folders
  • device_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/ only user-data exists (the staged copies). /Users/mseemann/claude/bugs* do not exist as paths inside the sandbox; mount/findmnt show 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_dir on /Users/mseemann/claude/bugs did not show it). The staged copy is decoupled from the real disk, so workspace bash/sed only mutates a dead copy.
  • The only real write path to disk is device_commit_files, which requires a SendUserFile-produced fileUuid. Because SendUserFile delivers 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

  1. 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).
  2. Open a new Cowork session.
  3. Check whether the folder is writable-mounted in the sandbox (mount/findmnt, or a write test cross-checked on the device via device_list_dir) → no mount; a write into the staged copy never reaches the device; the only real write path is device_commit_files via a SendUserFile fileUuid.
  4. 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.
  5. 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/commit all fail). Here those tools work fine; what's missing is the writable workspace mount.
  • Not #76187: there connectedFolders is empty and the folder is fully non-functional. Here get_device_info reports 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:

  1. The sandbox shell (workspace bash) can edit files in place (sed/direct writes) and those changes land on the real disk directly — without a SendUserFiledevice_commit_files round-trip.
  2. 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

  1. 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).
  2. Open a new Cowork session.
  3. Check whether the folder is writable-mounted in the sandbox (mount/findmnt, or a write test cross-checked on the device via device_list_dir) → no mount; a write into the staged copy never reaches the device; the only real write path is device_commit_files via a SendUserFile fileUuid.
  4. 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.
  5. 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_

View original on GitHub ↗