[BUG] Cowork: FUSE Mount Cache Coherency Failure on Host-Side File Writes

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

The Cowork sandbox's file mount layer (virtiofs + bindfs) does not invalidate cached file-size metadata when files are modified on the host side (e.g., by MCP servers). This causes the sandbox to see corrupted file content: null-byte padding when files shrink, hard truncation when files grow.

Affected Configuration

• Platform: Windows 11
• Client: Claude desktop app (Cowork mode)
• Mount stack: NTFS → virtiofs (host↔Linux VM) → bindfs (FUSE) → sandbox
• Trigger: Any MCP server that writes to files in the mounted workspace folder

Symptoms

When an MCP server (running on the Windows host) writes to a file in the workspace folder:

1. The write is correct on the host filesystem — verified by reading back through the MCP.
2. The sandbox sees stale file size — the FUSE cache retains the previous size known from the last sandbox-originated operation.
3. Content is corrupted in the sandbox view:

• File shrinks → new content + null bytes (\x00) padded to old size
• File grows → content hard-truncated at old size
• Equal size → no corruption (no size change = no cache mismatch)
• New file (no prior cache entry) → no corruption

1. Modify time is not updated in the sandbox stat output after host-side writes, confirming the FUSE cache is stale.

Cascade: How This Causes Real Data Loss

The stale cache alone would be annoying but survivable. The real damage occurs through read-modify-write:

1. MCP writes file (correct on host disk)
2. Claude reads file from sandbox (stale FUSE cache → null-padded or truncated)
3. Claude writes back the corrupted view (via sandbox filesystem tools)
4. Now the host disk is genuinely corrupted — the FUSE write propagates through virtiofs to NTFS

This is how vault files were permanently corrupted in production use before the root cause was identified.

Workaround

Avoid using MCP tools for file writes. Use only the sandbox filesystem tools (Read/Edit/Write) for all file I/O. Since these go through the FUSE mount, the cache stays consistent with its own writes. MCP read-only operations (e.g., search) remain safe.

Root Cause Analysis

Full test suite and analysis: available on request (13 tests, hex dumps, inode tracking, timing analysis). The definitive test (Test 13) proved the corruption is purely a cache view issue by showing correct content via MCP read and corrupted content via sandbox read on the same file, immediately after a host-side write.

Environment Details

bindfs on /sessions/.../mnt/Work type fuse.bindfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
IO Block: 262144, Blocks: 0 (characteristic of FUSE/virtiofs, not native filesystem)

What Should Happen?

The external write file event should invalidate the FUSE cache and force a new read from the filesystem

Error Messages/Logs

Steps to Reproduce

Reproduction Steps

Setup

Open a Cowork session with a workspace folder mounted.

Test (requires any MCP that can write files)

1. From sandbox, write a file with known content (~235 bytes). Verify with wc -c.
2. Via MCP (host-side write), overwrite the same file with shorter content (~17 bytes).
3. From sandbox, read the file:

• wc -c reports 235 bytes (stale cached size)
• xxd shows 17 bytes of correct new content + 218 null bytes
• stat shows unchanged mtime

1. Via MCP read, verify the file on host is correct (17 bytes, no null bytes).

Reverse test (expanding)

1. From sandbox, write the file with short content (17 bytes). Verify.
2. Via MCP, overwrite with longer content (~240 bytes).
3. From sandbox, wc -c reports 17 bytes. Content is truncated at byte 17.
4. Via MCP read, verify the file on host has the full ~240 bytes.

Key observation

The FUSE cache always reflects the last sandbox-originated file size, regardless of host-side changes.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.87

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_