Cowork/coworkd FUSE mount doesn't propagate live filesystem updates after session start

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?

coworkd's FUSE mount of a synced OneDrive folder (target /sessions/<session>/mnt/<folder>, source /proc/self/fd/3 from the coworkd parent process) takes a clean snapshot at session establishment and never propagates subsequent writes to the underlying files, no matter how many times they change on the host filesystem.

Confirmed via live self-introspection from inside the sandbox (uname, mount, /proc/self/cgroup, uptime), session cgroup path 0::/coworkd/oneshot-<uuid>:

• Mount is FUSE, fstype=fuseblk, established once at session start, persists across all subsequent shell invocations in the same session (not re-mounted per-command).
• Host-side files were rewritten multiple times over 5+ hours (verified via an independent process on the host machine: byte-identical content, fresh mtime, fsync + atomic rename). None of these updates were ever visible through the FUSE mount. Every read returned the exact bytes from session-start, confirmed via SHA256 across repeated reads over the full window.
• The sandbox has no CAP_SYS_ADMIN and cannot mount/umount or invalidate cache from user-space. No user-space refresh call is available.
• The only mitigation found: end the session and start a new one (new coworkd instance -> fresh FUSE mount -> new one-time snapshot). This loses all in-session state and will drift stale again over time.

What Should Happen?

coworkd's FUSE layer should propagate host-side file changes to the mounted view for the lifetime of a session -- either by invalidating inode/content cache when the underlying synced folder changes, or by exposing a user-space cache-refresh call for long-running sessions that need current data from a synced folder.

Error Messages/Logs

Example from one affected file (independently verified byte-identical + fresh on the host, but frozen at session-start bytes inside the sandbox for 5+ hours):

Host (independent process, repeated over time): mtime advances normally, sha256 changes with each legitimate content update.
Sandbox (same file, same path, via FUSE mount): sha256 stays IDENTICAL read after read, matching only the sha256 captured at session start -- never advances even though the host file has since changed multiple times.

Steps to Reproduce

1. Start a Cowork/Claude session with a synced folder (e.g. OneDrive, iCloud Drive) mounted read/write via FUSE at session start.
2. From a separate, independent process on the HOST machine (not inside the sandbox), repeatedly rewrite a file inside that synced folder over a period of hours -- fresh content, fresh mtime each time, using a normal atomic write (temp file + fsync + rename).
3. From inside the Cowork sandbox session (the same one from step 1, not a new one), read that same file via its mounted path at various points over those hours.
4. Observe: the sandbox's read never changes -- same bytes, same sha256 -- regardless of how many times the host actually rewrote the file. The sandbox is stuck on whatever the file looked like at the moment the FUSE mount was first established for that session.
5. Ending the session and starting a brand new one immediately picks up the CURRENT host bytes (a fresh one-time snapshot) -- confirming the mount itself works at session start, but never refreshes after that.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.197 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This was root-caused via live self-introspection from inside the affected Cowork session itself (uname, mount, /proc/self/cgroup, uptime) -- happy to share the full raw command output if useful for debugging. Session cgroup path observed: 0::/coworkd/oneshot-<uuid> (ephemeral single-shot cgroup, unprivileged uid, no CAP_SYS_ADMIN). This is an infrastructure-level bug in coworkd's FUSE mount handling, not something fixable from user-space inside the sandbox, and not related to the Claude Code CLI version itself.