[BUG] Cowork: Sandbox silently reads truncated/stale file content from mounted folder — no error raised

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?

Environment: Windows, Cowork mode, mounted local project folder (~50 files, largest ~2000 lines Python)

When Cowork's sandbox reads files from a mounted Windows folder, it can return silently truncated or stale content — no I/O error, no warning. Both the Read tool and wc -l via Bash report the truncated version as if it were the complete file.

This is distinct from existing mount issues (#30364, #29587, #27594) because there is no error signal at all. The sandbox believes it has the full file.

Reproduction:

1. Mount a folder containing a ~1963-line Python file (ib_position_engine.py)
2. Use the Read tool or wc -l to check the file — returns 1818 lines, cleanly cut off mid-docstring
3. md5sum confirms the working copy differs from git show HEAD:<file> (which correctly returns all 1963 lines via the git object store)
4. The file is fully intact on the host (verified in VS Code at 1963 lines, matching HEAD)
5. No error is raised at any point — the sandbox treats the partial content as the complete file

Why this is dangerous:

Silent truncation (file ends mid-block) is the lucky case — Claude can potentially notice something looks wrong.

Silent staleness (file ends at a clean boundary but is missing recent changes, or has outdated function bodies) is the dangerous case — there is no visual clue. Claude assesses, plans, and recommends changes based on code that doesn't match what's actually on disk. In our case, this led to incorrect analysis of safety-critical trading engine code.

Workaround: git show HEAD:<file> reads from the git object store inside the sandbox and returns correct content. Only works when working copy matches HEAD — no workaround for uncommitted changes.

What Should Happen?

1. File reads from the mount should return the complete, current content of the host file
2. If the mount cannot guarantee freshness, the sandbox should have a mechanism to detect or force a re-sync (e.g., a checksum/length validation against the host)
3. At minimum, Claude's Read tool should be able to detect when its copy may be stale and warn the user rather than silently returning partial content

Error Messages/Logs

# Sandbox shows 1818 lines
$ wc -l ib_position_engine.py
1818 ib_position_engine.py

# Git HEAD shows 1963 lines (correct)
$ git show HEAD:ib_position_engine.py | wc -l
1963

# Checksums don't match
$ md5sum ib_position_engine.py
5d73bc94c7668c05d63573dafe51e0e0  ib_position_engine.py
$ git show HEAD:ib_position_engine.py | md5sum
668443808664135ccffbaaba1e1c1e1a  -

# File ends mid-docstring — no error raised
$ tail -5 ib_position_engine.py
        from_monitor=True (async 5s polling): requires 2 consecutive oversized
        reads before tripping ...
        from_monitor=False (active decision paths: f

Steps to Reproduce

1. Open Cowork on Windows, mount a project folder containing a Python file over ~1800 lines
2. Ask Claude to assess or review the file
3. Claude reads the file via the Read tool — receives silently truncated content (1818 of 1963 lines in our case)
4. wc -l via Bash confirms the truncated count — no error
5. git show HEAD:<file> | wc -l returns the correct 1963 lines, proving the git object store is intact but the mount is stale
6. md5sum of the mounted file differs from git show HEAD:<file> | md5sum
7. VS Code on the host shows the complete 1963-line file

Note: This is intermittent — the mount appears to sometimes lag behind the host filesystem. The truncation point varies. There is no error or warning at any stage.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Cowork (Claude Desktop, Opus 4.6)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

This bug applies to Cowork mode (Claude Desktop), not the CLI. Filing here because related mount issues (#30364, #29587, #27594) are tracked in this repo.

The core issue is that the file bridge between the host Windows filesystem and the Cowork sandbox can serve incomplete file content with zero error signal. This makes it impossible for Claude to detect when it's working with stale data unless it cross-references git — which only works for committed files.

Suggested fix: Add a checksum or file-length validation at the mount/bridge layer so the sandbox can detect sync mismatches, or expose a "re-sync" mechanism that Claude's Read tool can invoke before critical file reads.