Write tool overwriting a file in a Dropbox-synced directory prepends stale (first-version) content instead of replacing it

What's Wrong?

Overwriting an existing file with the Write tool inside a Dropbox-synced directory (Dropbox\MyNotes\... on Windows) intermittently prepends the file's first-known version of a leading block (in my case, a YAML frontmatter header) ahead of the newly written content, instead of fully replacing the file. The stale block is from the original version, not the immediately-prior write — consistent with Dropbox re-syncing a cached copy into the write path rather than a Write-tool bug per se.

Sequence that triggers it:

1. Write(path, contentA) — file created, contentA has frontmatter A.
2. Read(path) — confirms contentA on disk, correct.
3. Write(path, contentB) — contentB has a different, unrelated frontmatter B.
4. Reading the raw file on disk now shows: frontmatter A, immediately followed by frontmatter B and contentB's body — i.e. contentA's header was prepended, not replaced.

Repeating step 3 with a contentC reproduces the same duplication (still prepending the original frontmatter A, not B), so this isn't a one-off race — it reproduces on every subsequent overwrite of the same file within a session.

Isolation

Ran the identical Write→Read→Write sequence against two control locations that are not Dropbox-synced but are otherwise handled the same way by the CLI (both are additionalDirectories entries / scratch paths):

• A local folder under ~/.claude/plans/ — clean overwrite, no duplication.
• The session scratchpad temp directory — clean overwrite, no duplication.

Only the Dropbox-synced path reproduces the bug. This points at an interaction between Dropbox's sync/locking behavior and however the Write tool performs the on-disk replace (e.g. write-to-temp-then-rename, or an open-handle write) rather than a bug in the Write tool in isolation.

A related, not-separately-reproduced symptom from an earlier occurrence of this same bug (on a different Dropbox-vault file, different session): the corrupted result also showed cp1252-vs-UTF-8 mojibake (accented Latin characters written as multi-byte replacement sequences), which may be a second side effect of the same underlying race rather than a distinct bug.

Environment

• OS: Windows 11
• Sync client: Dropbox (desktop, standard sync — not tested with "online-only"/Smart Sync files)
• The affected path was configured as an additionalDirectories entry in settings.json, not the primary working directory

Workaround

Avoid the Write tool for files inside Dropbox-synced paths; write via a script (e.g. Python pathlib.write_bytes) instead, which does not reproduce the issue.

Steps to Reproduce

1. Ensure a target directory lives inside an actively-syncing Dropbox folder, and is reachable via additionalDirectories in settings.json.
2. Write a new file there with distinct frontmatter/content ("v1").
3. Read the file back (confirms clean v1 on disk).
4. Write the same path again with different frontmatter/content ("v2").
5. Read the raw bytes on disk (not via the Read tool, which may normalize) — the v1 frontmatter block appears prepended ahead of the v2 content, rather than the file containing only v2.
6. Repeat step 4 with a "v3" payload — v1's frontmatter still appears prepended (not v2's), confirming it isn't simply reading back the immediately-prior write.