The edit was three lines. The diff was fifty-seven. There was no error message. No test failure. The only signal was that the numbers did not match.
i.What happened
A small wording fix to a UTF-8 file ran through a PowerShell 5.1 script. The script read the file, made the three-line change, and wrote it back. Standard operation.
PowerShell 5.1, by default, reads text files as ANSI when no byte-order mark is present. The file had no BOM. So PowerShell read 57 lines containing non-ASCII characters, interpreted them through the ANSI codepage, mangled any character outside plain ASCII range, and wrote the mangled text back.
The script did not raise an error. The characters it wrote were valid strings in its own encoding model. The file it produced was readable. The corruption was silent.
The catch came from a simple check before committing: the diff against the parent commit showed 57 changed lines for a 3-line edit. That mismatch was the only evidence anything had gone wrong.
A byte-comparison against the pre-edit state confirmed the corruption. The mangled file was discarded. The fix applied through a tool that handled encoding correctly.
ii.Why this is a Windows-specific hazard
On Linux and macOS, the default file encoding assumption is UTF-8. A BOM-less UTF-8 file reads and writes correctly without any configuration. The hazard does not exist in the same form.
On Windows, PowerShell 5.1 (the version shipped with all Windows installations and the version that runs by default in many scripting contexts) defaults to the system ANSI codepage for file operations when no BOM is present. This is a legacy decision from the 1990s that has never been corrected at the platform default level.
The practical consequence: any script that reads and writes text files on Windows without explicitly specifying UTF-8 encoding is a latent corruption risk on any file that contains non-ASCII characters. The risk is proportional to the number of such characters and the frequency of the operation. The failure is silent every time.
On Windows encoding discipline On Windows, the platform's defaults will corrupt your data politely. The discipline that saves you is distrusting a diff whose size does not match the edit you made.
iii.The discipline that caught it
The practice of checking diff size against expected edit size is not formal protocol. It is a reflex: before committing, look at the diff. Not to read every line. To notice whether the scale of the change matches the scale of the intended edit.
A 3-line reword should produce a diff in the range of 3 to 6 lines, accounting for minor whitespace or context changes. A 57-line diff is outside that range by an order of magnitude. That mismatch is an immediate stop signal.
The check requires no tooling. It requires only the habit of reading the diff size as a first-pass sanity signal before reading the diff content.
This failure class is distinct from the encoding errors that produce visible garbage characters on screen. Silent mojibake, where the corruption is invisible to a casual reader because the corrupted characters are encoded into something that still displays, is detectable only at the byte level. The diff-size check is a byte-level proxy that costs nothing.
iv.The portable rule
Two rules travel from this incident for anyone running agentic or scripted workflows on Windows.
The first is encoding hygiene. Any script that reads and writes text files must specify UTF-8 explicitly. In PowerShell 5.1, this means passing -Encoding UTF8 on both the read and write operations. In any other language or tool, verify the encoding default before assuming it is correct for the file type.
The second is diff-size skepticism. Before any commit, the expected scope of a change and the actual scope of the diff should match. When they do not match, stop and investigate before pushing. The mismatch is not always corruption. It is always a question worth answering.
For agentic systems running file edits without a human in the loop, the diff-size check belongs at the output gate. A gate that verifies the number of changed lines falls within an expected range for the edit operation is cheap to implement and catches a class of silent failure that no downstream test will surface, because the tests read the file through the same encoding layer that produced the corruption.
Drafted with Bishop, my AI partner.
Words picked, edited, and approved by me.
Model provenance: Claude Code (Claude Opus and Sonnet)