Edits now preserve a file's encoding and Windows CRLF line endings instead of rewriting them.
What's wrong with this entry?
The sed-style edit path now reads the raw bytes of a file, detects its encoding and whether it uses Windows CRLF line endings from the first 4096 bytes, and writes back using both. Previously it assumed a single encoding lookup, which could rewrite line endings.
- The synchronous byte-read helper was removed from the filesystem layer; callers use the async read instead.
readFileBytes
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.248
Read-before-write guard relaxed for remotely served calls
Both mention file editing
-
v2.1.236
Edit tool now tells the model to read out-of-directory files first
Both mention editing
-
v2.1.239
File uploads report why they failed and stop retrying forever
Both mention file