[BUG] Cowork: Stale rclone FUSE cache (cache_duration_s=3600) causes silent file corruption when Edit/Write tools and bash interact

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 bash sandbox serves stale file content for up to 1 hour after the Edit/Write file tools modify a file. This causes silent file corruption, truncation, and massive productivity loss.

The root cause is the rclone FUSE mount configuration. I had Claude inspect the sandbox architecture from within a session, and it found the mount config at /tmp/rclone-mount-config.json:

/mnt/user-data/outputs:      cache_duration_s = 3600  ← 1 HOUR cache!
/mnt/user-data/uploads:      cache_duration_s = 1     ← works fine
/mnt/transcripts:            cache_duration_s = 10    ← works fine  
/mnt/user-data/tool_results: cache_duration_s = 3     ← works fine

All mounts use vfs_cache_mode: full with vfs_cache_max_size: 1G.

The process is /opt/rclone/rclone-filestore multimount --config /tmp/rclone-mount-config.json (a custom Anthropic build of rclone using go-fuse/v2 DirectMount). No RC API is exposed (localhost:5572 is not listening), so there is no way to programmatically invalidate the cache.

What happens:

1. User (or Claude) edits a file using Edit/Write tool → writes to host filesystem
2. User (or Claude) runs cat file.js or node -c file.js in bash → reads from rclone FUSE mount
3. FUSE mount serves the cached (old) version for up to 3600 seconds
4. Claude doesn't know the file is stale — no error, no warning
5. Any bash write based on the stale read corrupts or truncates the file

Impact Evidence (Single Project)

In one Cowork project (building a sales hub app), this caused:

| File | Times Hit | What Happened |
|------|-----------|---------------|
| portal/index.html | 2× | Truncated at 648 lines (should be 791), lost entire functions + closing tags |
| App.js | 1× | Showed 6 lines instead of 59 |
| package.json | 3×+ | Missing new scripts repeatedly |
| rfqController.js | 2× | Duplicate functions from append-to-truncated-file |
| server.js | 2× | Missing routes, required full rewrite |
| 3 other files | 1× each | Various truncation/missing content |

Estimated time wasted in one session: 3-4 hours of debugging and rebuilding.

Proposed Fix

Simplest fix: Change cache_duration_s from 3600 to 1 for the outputs/session writable mount — matching what the uploads mount already uses successfully.

Better fix: Enable the rclone RC API and call vfs/forget after every Edit/Write tool operation to surgically invalidate affected cache entries.

Best fix: Route Edit/Write tool writes through the same FUSE mount path that bash uses, so the VFS cache is updated on write.

Reproduction Steps

1. Open any Cowork project with bash access
2. Create a file with some content using the Write tool
3. In bash, run cat <filepath> — content appears correctly (cache is now warm)
4. Edit the file using the Edit tool (add a new line, change content)
5. In bash, run cat <filepath> again — shows the OLD content
6. Run wc -l <filepath> — shows the OLD line count
7. Wait up to 60 minutes for cache to expire, then bash shows the new content

Environment

• Platform: Windows 11 (but affects all platforms — the rclone config is server-side)
• Product: Claude Desktop — Cowork mode
• Process: /opt/rclone/rclone-filestore multimount (custom Anthropic build)
• Mount type: fuse.rclone (go-fuse/v2 DirectMount)
• Cache config: vfs_cache_mode=full, cache_duration_s=3600, vfs_cache_max_size=1G
• No RC API available (localhost:5572 not listening)

What Should Happen?

What happens:

1. User (or Claude) edits a file using Edit/Write tool → writes to host filesystem
2. User (or Claude) runs cat file.js or node -c file.js in bash → reads from rclone FUSE mount
3. FUSE mount serves the cached (old) version for up to 3600 seconds
4. Claude doesn't know the file is stale — no error, no warning
5. Any bash write based on the stale read corrupts or truncates the file

Error Messages/Logs

Steps to Reproduce

1. Open any Cowork project with bash access
2. Create a file with some content using the Write tool
3. In bash, run cat <filepath> — content appears correctly (cache is now warm)
4. Edit the file using the Edit tool (add a new line, change content)
5. In bash, run cat <filepath> again — shows the OLD content
6. Run wc -l <filepath> — shows the OLD line count
7. Wait up to 60 minutes for cache to expire, then bash shows the new content

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This bug is silent — there are no error messages or warnings. Claude (the AI) has no way to detect that the file it's reading in bash is stale. This makes it particularly dangerous because:

• Syntax checks (node -c) validate old code and pass when they shouldn't
• Appending to a stale file creates files with missing middle sections
• Claude confidently proceeds based on stale data, wasting entire conversation turns

The uploads mount proves that cache_duration_s=1 works fine for the same rclone setup. The 3600-second cache on writable mounts appears to be a configuration oversight rather than a performance necessity.

I've built a workaround skill (cowork-file-sync) that teaches Claude to force-sync files via Python rewrites in bash after every Edit/Write operation, but this is a band-aid — the fix needs to happen at the infrastructure level.