[BUG] Silent data loss: Cowork file writes truncated after successful md5 verification on Windows OneDrive folders

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?

Files written or edited by Cowork to OneDrive-synced and Obsidian Vault folders on Windows are silently truncated — typically losing the last 50–200 bytes of content, often mid-word or mid-line. The write itself succeeds (md5 matches at the moment of write), but the file appears truncated when re-read in a later operation.
Steps to Reproduce

Open a Cowork session with a connected folder under C:\Users\<user>\OneDrive\ or a OneDrive-synced Obsidian Vault
Use any of the following to write or edit a markdown/text/python file in that folder:

The Write tool
The Edit tool
Bash atomic-mv from the Cowork sandbox (cp /tmp/file dest)
A scheduled task writing to the folder

Read the file back later (same session or new session)
Observe the file is truncated at the tail

Reproducibility: 5+ times in 2 days on the same canonical file (1,739-line markdown that twice ended mid-word at ### P.3 — Cross-source signal stacking — trip).
Expected Behavior
Files written via Cowork tools should retain the complete content that was written.
Actual Behavior
Last 50–200 bytes of file are silently lost. Examples observed:

1,739-line markdown → 1,625 lines (lost 114 lines + cut mid-word at line 1,625)
CHANGELOG markdown → tail cut at "will be created whe" (mid-sentence)
Multiple .py and .md files affected across two folders

Environment

Windows 11
Claude desktop with Cowork mode
Affected folders:

C:\Users\<user>\OneDrive\Documents\Claude\Projects\<project>\
C:\Users\<user>\Documents\Vaults\<vault>\ (also OneDrive-synced)

Cowork sandbox bash mount visible at /sessions/<id>/mnt/

Workarounds Attempted (none resolve)

Paused OneDrive sync for 24+ hours → truncation continued
Added Windows Defender exclusions for both root directories → truncation continued
Atomic-write discipline (write to /tmp first, md5 verify, cp to destination, md5 verify destination, read-back + tail-inspect) → md5 matches immediately after write, but file later appears truncated

What I Ruled Out

Not OneDrive sync — sync was paused during multiple incidents
Not Defender real-time scan — exclusions in place during multiple incidents
Not write-tool-specific — reproduced across Write, Edit, and bash atomic-mv

Suspected Cause
Something is modifying or truncating the file after the write completes. Candidates I have not ruled out:

Windows Search indexing service touching the file
Obsidian's git auto-commit plugin scanning the vault
OneDrive's "Files On-Demand" tier-down despite sync being paused
Interaction between Cowork sandbox's 9P-style mount layer and Windows file handles (e.g., truncation on close-without-flush)

Impact
This is a silent data-loss bug. The affected file is a canonical multi-session TODO list driving operational work. Each incident requires manual restoration from prior session context, and there is no warning the truncation occurred until something tries to read past the cut point. For users storing code or notes in OneDrive folders, this is a serious issue.
What Would Help Diagnose

Verbose Cowork file-write logging (size + md5 before write, immediately after, and 60 seconds after)
Documentation of whether Cowork's mount layer flushes Windows file handles synchronously vs lazily on close
Whether bash sandbox's 9P file metadata can mismatch Windows-side metadata in a way that causes truncation on next Windows-side access

What Should Happen?

Files written via Cowork's Write, Edit, or bash tools should retain the complete content that was written. Specifically:

1. The file size, md5 hash, and last bytes of content on disk should match what was written.
2. The match should persist — reading the file 1 second, 1 minute, or 1 hour after the write should return the same content.
3. If any background process (sync, indexer, security scan) cannot complete safely, the write should fail loudly rather than silently truncate.

Error Messages/Logs

SILENT FAILURE — NO ERROR MESSAGES SURFACE TO THE USER.

Evidence of truncation, with md5/line-count audit:

Incident 1 (todo-v1.1-v1.2-and-cleanup.md):
- Pre-write line count: 1,739
- Pre-write md5: 399fdbfaaf4172278159637a1cff94f7
- Post-write md5 verify (immediately after cp + read-back): MATCH
- Discovery, ~hours later:
  - Line count: 1,625 (lost 114 lines / ~5KB at tail)
  - File ends mid-word at line 1,625: "### P.3 — Cross-source signal stacking — trip"
  - Expected last line: "  ALWAYS edit via /tmp + atomic mv + md5 verify; integrity_check.py watches..."

Incident 2 (CHANGELOG.md, pre-existing truncation):
- File tail ends mid-sentence at: "- executions/ folder: still doesn't exist; will be created whe"
- Expected: complete sentence with closing punctuation and additional content

Incident 3 (investos_sync.py):
- Python script truncated mid-function definition
- ast.parse() failed with SyntaxError on a previously-valid file

Reproduction frequency: 5+ incidents in 2 days (2026-06-06 and 2026-06-07).

Defensive audit pattern used (still misses truncation since it happens AFTER verification):
  1. Write file to /tmp via Python
  2. md5sum /tmp/file
  3. cp /tmp/file <dest>
  4. md5sum <dest>     ← matches
  5. tail -3 <dest>    ← intact
  6. (some time passes)
  7. wc -l <dest>      ← truncated
  8. md5sum <dest>     ← now mismatched

Steps to Reproduce

1. Open a Cowork session in a project with a connected folder under either:

• C:\Users\<user>\OneDrive\Documents\Claude\Projects\<project>\
• A OneDrive-synced Obsidian vault (e.g., C:\Users\<user>\Documents\Vaults\<vault>\)

1. Create or edit a multi-hundred-line markdown or Python file in that folder using ANY of:

• The Write tool
• The Edit tool
• Bash atomic-write pattern from the Cowork sandbox (write to /tmp, cp to destination, verify md5)
• A scheduled task agent writing to the folder

1. Immediately after the write, md5sum and tail-inspect the file — it matches what was written.
2. Wait some unspecified amount of time (could be seconds, could be hours) OR continue in the session and read the file later.
3. Re-read the file — last 50–200 bytes are gone, often mid-word.

Reproduced 5+ times in 2 days on the same canonical file across multiple write surfaces.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Version 1.11187.4 (584005)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

• Truncation happens AFTER the write completes successfully. md5sum verification immediately

post-write matches expected content; the truncation manifests later on subsequent reads.

• The atomic-write pattern (write to /tmp via Python, cp to destination, md5 verify destination,

tail-inspect destination) cannot prevent the bug — it only catches truncation that has already
happened at the moment of verification.

• A custom integrity_check.py was built to monitor file shrinkage by comparing against a manifest,

but it runs on schedule (post-close), not in real time, so it only catches truncation after the
fact.

• The Cowork sandbox bash mount (visible at /sessions/<session-id>/mnt/) is what suggested initially

that this might be a 9P-style mount metadata issue, but truncation reproduces even when only the
desktop-side Write/Edit tools are used — so it's not sandbox-specific.

• Defender exclusions and OneDrive sync pause did NOT resolve the issue, so the most obvious

suspects (real-time AV scan, sync race condition) are ruled out.

• Affected files include large markdown files (1,700+ lines), Python scripts (some now syntactically

broken from mid-function truncation), and JSON state files.

• Recovery requires manual restoration from in-context backup. There is no warning to the user that

the truncation happened until something reads past the cut point.

• Happy to provide a list of specific file paths + timestamps + md5 before/after if useful for

forensics.