edit_block silently truncates file to pre-edit byte length when replacement grows the file

[Haseeb-1698]

Version: 0.2.43 (DXT, Claude Desktop) · OS: Windows 10/11 x64 · Node: 24.17.0 (Electron 42.5.1) · Client: local-agent-mode "Desktop Commander"

Summary

On a large text file (~148 KB, ~1,070 lines, UTF-8/ASCII, .tex), every edit_block call whose
new_string is longer than old_string writes a file whose byte length is EXACTLY the pre-edit
length. The replacement itself is applied correctly, but the file's tail is cut by exactly the
number of net bytes added. No error is returned; the call reports success.

Reproduced twice (byte-exact)

1. File 147,308 bytes → 6 edit_block calls, net +4,684 bytes → file still 147,308 bytes,
   last 4,684 bytes gone (file ends mid-word, \end{document} lost).
2. Same file later at 151,992 bytes → 3 edit_block calls, net +1,391 bytes → still 151,992 bytes,
   last 1,391 bytes gone.

Losses accumulate across sequential edits; shrinking edits did not visibly corrupt anything,
suggesting the file length is being pinned to a stale pre-edit size on the write path
(e.g. a truncate/allocation based on old fs.stat size rather than the new content length).

Steps to reproduce

1. Create a text file of ~150 KB with > 1,000 lines (some lines ~2–3 K chars); note byte size and last line.
2. Call edit_block replacing a short unique string in the middle with a string ~2 KB longer.
3. Compare: file byte size is unchanged from step 1, and the last ~2 KB of the file are missing.

Expected

File length grows by the net replacement delta; tail preserved.

Impact

Silent data loss/corruption on any growing edit to a large file. Tool stats showed 77/77
edit_block calls "successful" while the file lost its tail twice.

Notes

• Replacement target being past line 1,000 still matched fine, so fileReadLineLimit (1000)
  does not gate matching; the bug appears to be write-side.
• config: fileReadLineLimit=1000, fileWriteLineLimit=50 (defaults).

[jryyangjy]

Tried to reproduce this against current main (build 0.2.45) and couldn't — noting what I tried in case it's useful for narrowing this down.

Attempt 1 — single growing edit on a large file, matching the repro steps: built a 1200-line / ~133KB file, called performSearchReplace directly (bypassing the MCP transport) with a search string replaced by one ~2KB longer. Result: file size increased by exactly the expected delta, replacement content present, original tail content intact.

Attempt 2 — sequential growing edits (5 in a row, each replacing a short marker with a ~1.5KB longer string), to check for the accumulated loss pattern described in the report. Each edit's size delta matched exactly; no accumulation, all markers and the original tail present after all 5.

I also traced the write path by hand: performSearchReplace's exact-match branch builds the full new content via substring/join (no line-count-based truncation — fileWriteLineLimit only produces a warning string there, doesn't slice anything), and TextFileHandler.write() calls a plain fs.writeFile(path, content) with the complete string — no partial/chunked write or stat-based truncation on that path. The fuzzy-match fallback (exact match not found) never calls writeFile at all in the current code, so it can't be the source either.

Given I can't reproduce it and the code I can see looks correct for both scenarios you described, this might already be fixed, or need a detail my repro is missing — happy to try again with more specifics if you have them (exact tool-call sequence via the actual MCP transport rather than a direct function call, config used, whether it's Windows/macOS/Linux-specific, or a version where it still reproduces).

[Haseeb-1698]

Thanks for the thorough trace you can close this. I ran a controlled repro on 0.2.43 with size checks on both sides of my setup, and Desktop Commander is not at fault.

A setup detail my report omitted: the file lives in a folder that is simultaneously mounted into a sandboxed Linux VM by another tool (Claude Desktop's Cowork mode). Every "truncated" read in my report went through that mount, never directly through Windows.

Controlled test (0.2.43 DXT, Windows, same folder):

1. Created a 144,009-byte / 1,100-line file.
2. One edit_block replacing a 25-character marker with a 1,196-character string (net +1,171 bytes).
3. PowerShell on Windows immediately after: 145,180 bytes, 1,100 lines, replacement present at line 550, original tail intact exactly correct.
4. The same moment through the Linux mount: still 144,009 bytes, 1,091 lines, replacement present but the file ends mid-line—the new content is clamped to the stale pre-edit size.

So edit_block writes correctly; the VM mount layer serves updated content with a stale cached file size after an external writer modifies a mounted file, which produces exactly the "pinned to pre-edit byte length" signature I reported. The "corruption" I then repaired was me reading the truncated mount view.

Sorry for the noise, and thanks for checking the write path so carefully that trace is what prompted me to test both sides.