[BUG] Cowork: Edit silently clamps file size to pre-edit size — data loss, reproduces #52581

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (most-relevant prior, #52581, was auto-closed as duplicate of #42520; see "Why not a duplicate" below)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

In Claude Desktop Cowork mode on Windows, the Edit tool silently clamps the on-disk file size to the pre-edit size, dropping the tail of the new content. The tool reports "The file has been updated successfully", and a subsequent Read returns the intended post-edit content (from an in-memory cache), so the agent has no in-band signal that the write failed. The actual on-disk file is corrupted: the original bytes are preserved up to the splice point, the first few bytes of the new content are written, and everything beyond the original file length is dropped.

This is the same failure described in #52581 ("Cowork Edit/Write tools silently clamp final file size to pre-edit size on FUSE-mounted workspace"), which was auto-closed as a duplicate of #42520. #42520 is a different mechanism (host-side MCP writes invalidate sandbox cache) and was itself closed by the reporter as a duplicate of #38993. The sandbox-write-side clamp bug described in #52581 has no open canonical, so it isn't getting tracked. Filing this with fresh evidence from 2026-05-14.

Severity: data-destroying. Real long-running project (financial planning model, 1700-line markdown brief) lost ~7,500 bytes of intended content on a single Edit call; the only reason the work was recoverable is that an audit script downstream of the Edit happened to grep for a closing marker and noticed it was missing.

Environment

• Client: Claude Desktop, Cowork mode, version 1.6259.1
• Claude Code CLI version (from claude --version inside sandbox): 2.1.90
• Host OS: Windows 11 Pro, 10.0.26200.8457
• Sandbox OS: Linux microVM (MINGW reports Msys 3.6.5, x86_64)
• Mount stack: NTFS (host) → virtiofs (host↔VM) → FUSE (bindfs) (sandbox-side)
• Workspace path: C:\Users\<user>\Desktop\<folder>\Financial\Claude (mounted under /sessions/<id>/mnt/Claude/)
• Folder type: plain Windows local folder, not OneDrive-synced, no cloud sync active
• Model: Opus

Concrete reproduction (deterministic, real-session evidence)

A single Edit call on a 1,608-line markdown file. The Edit's intent: append a new ~7,600-byte Session log entry by replacing the closing marker *End of brief.*\n (the last 16 bytes of the file) with ### Session 13 - May 14, 2026 ...(7,600 bytes of new content)... *End of brief.*\n.

| Metric | Pre-edit | Expected post-edit | Actual post-edit |
|---|---|---|---|
| File size | 127,488 bytes | ~135,072 bytes | 127,488 bytes (clamped) |
| Line count | 1,608 | ~1,715 | 1,608 |
| Trailing bytes | *End of brief.*\n | *End of brief.*\n | ### Session 13 - (no trailing newline) |
| Edit tool return | n/a | success | success |
| Read immediately after | n/a | shows new content | shows new 1,715-line content (in-memory cache) |
| Host-side Get-Content | n/a | full content | truncated as above |
| Python open() from sandbox bypassing FUSE cache | n/a | full content | truncated as above |

Critical signature: the new file is exactly the pre-edit size. The first 16 bytes of the 7,600-byte new_string ("### Session 13 -") landed on disk at the splice point because that's exactly how many bytes fit before hitting the pre-edit-size cap. The rest was silently dropped. This matches #52581's "the first original_size bytes of the intended result match exactly. The last N bytes are dropped with no error."

This is not the first time. Same workspace, same project, 9 days earlier on 2026-05-10, an Edit on the same PROJECT_BRIEF.md also silently truncated mid-line. That incident was caught by the same downstream audit. Two for two on Edits to this file with substantial appends.

Why this isn't a duplicate of #42520 / #38993

#42520 and #38993 describe a read-side cache-coherency problem: a process on the host writes a file, the sandbox reads the stale cached view. The data on the host disk is correct; the sandbox's view is wrong.

This bug is the opposite direction: the sandbox issues an Edit (a sandbox-side write), and the host disk ends up truncated. The host's on-disk content is permanently wrong after the call. No MCP-on-host process is involved — only Cowork's own Edit tool, writing to the mounted workspace.

The two bugs probably share a root cause inside virtiofs/bindfs cache handling, but the symptoms, the recovery, and the user-facing failure modes are different. Closing #52581 as a duplicate of #42520 buried the sandbox-write-side bug, which is the one that actively destroys user data.

What Should Happen?

1. After any Edit or Write call, the on-disk file size should match the intended content length. If the post-write stat'd size doesn't equal len(intended_content), the tool should return an explicit error to the agent instead of "updated successfully."
2. Read after a successful Edit should reflect the on-disk state, not an in-memory projection of "what the Edit was supposed to produce." The in-memory cache is currently masking the corruption.
3. The Edit tool should write atomically (write-to-tempfile → fsync → rename) so that a partial write can never leave a corrupted file on disk. NTFS same-volume rename is atomic; this would close the bug at the source even if the underlying cache layer remains buggy.

Error Messages/Logs

No error. That is the bug.

=== Edit tool said ===
The file ...PROJECT_BRIEF.md has been updated successfully.

=== Read tool said (cached intended view) ===
1,715 lines, ending in "*End of brief.*"

=== bash inside sandbox ===
$ wc -lc PROJECT_BRIEF.md
1608 127488 PROJECT_BRIEF.md
$ tail -c 20 PROJECT_BRIEF.md | od -An -c
   #   #   #       S   e   s   s   i   o   n       1   3       -

=== Windows PowerShell on host ===
PS> (Get-Item PROJECT_BRIEF.md).Length
127488
PS> Get-Content PROJECT_BRIEF.md -Tail 1
### Session 13 -
# (no trailing newline; file ends mid-sentence)

Steps to Reproduce

1. Start a fresh Cowork session on Windows. Select a plain local folder (non-OneDrive) as the workspace.
2. Place an existing text/markdown file of any non-trivial size (~100 KB works) in the workspace. Record wc -c <file> (call it N).
3. From the agent, call the Edit tool with:

• old_string = the last ~16 bytes of the file (e.g. its closing marker)
• new_string = something ~7,000 bytes longer than old_string (e.g. a closing marker preceded by a long appended block)

1. After the Edit:

• The tool returns The file has been updated successfully.
• Read returns the expected post-edit content (1,700+ lines in our case).
• wc -c <file> from bash still returns N (the pre-edit byte count).
• tail -c 20 <file> shows the file ends at the first ~16 bytes of new_string, with no trailing newline.
• PowerShell on the host confirms the host-side file has the same truncation.

We have not deliberately attempted a controlled minimal-repro on a scratch file yet (the working assumption was that the workspace is now poisoned, so we've prioritized recovery and locked away from Edit). What we have is two real incidents on the same large markdown file in 4 days: 2026-05-10 and 2026-05-14, same signature, both caught only because a downstream audit script greps for a closing marker. Plus a third symptomatically-adjacent incident from 2026-05-08 logged in the workspace's own session record: "Edit/Write tools reported success on model/engine.py but bash saw the old file" — initially attributed to Python bytecode cache, but with hindsight is more likely the same FUSE-cache-vs-host bug.

Claude Model

Opus

Is this a regression?

I don't know.

Last Working Version

Unknown. The same Cowork workspace exhibits the bug across multiple Claude Code CLI versions (2.1.x) and the current desktop app 1.6259.1. We have no version on which the Edit tool was demonstrably reliable for this workspace.

Claude Code Version

2.1.90 (inside sandbox); desktop app 1.6259.1.

Platform

Other (Claude Desktop, Cowork mode)

Operating System

Windows

Terminal/Shell

PowerShell on host; bash (Msys) inside sandbox.

Additional Information

Workaround in use today. We can no longer use Edit or Write on any project file in this workspace. Every project-file write must be: (a) bash heredoc cat > <target>.tmp << 'EOF' ... EOF, (b) mv <target>.tmp <target> (atomic same-filesystem rename), (c) verify via wc -lc + tail -c 1 | od + Python open() byte check. The protocol is documented in our project's SAFE_WRITES.md. This is not a satisfying long-term answer for users — the bash heredoc pattern is itself easy to misuse (see #38993, our own prior incidents) — but it is reliable for now.

Related issues (verified by author of this report):

• #52581 (closed as dup): same exact symptom, deterministic repro on sandbox-side Edit/Write. The closure-as-duplicate is the proximate reason this bug isn't being tracked.
• #42520 (closed as dup): host-side MCP-write cache coherency. Different mechanism.
• #38993 (open): host-side write → sandbox read staleness. Different mechanism, same FUSE-cache family.
• #50873 (open, stale): virtiofs split-brain at git-object level. Different surface, same family.
• #42913 (closed): Windows non-OneDrive truncation when reading from sandbox — read-side variant.
• #40231 (open), #51435 (open): skill/upload-side truncation. Same write-side family.

The cluster of FUSE/virtiofs cache bugs in Cowork on Windows is significant and is causing real data loss in long-running projects. A single fix at the substrate (cache invalidation on sandbox writes, or atomic-write through bindfs) likely closes most of them; but at minimum, post-write size verification in the Edit/Write tools would convert silent corruption into visible errors, which is the single most valuable change for users in the meantime.