Repository navigation
Edit/Write corrupt Windows-1252 (cp1252) files by rewriting them as UTF-8 #57308
Description
Description
Summary
edit/write corrupt Windows-1252 (cp1252) files by rewriting their contents as UTF-8.
Reproduced with OpenCode 2.0.32 on Windows 11 using a legacy IBM Informix 4GL source file encoded as Windows-1252 with CRLF line endings.
The important part: a one-character edit changes hundreds of characters elsewhere in the file.
Evidence
Original file:
Encoding: Windows-1252 (cp1252)
Line ends: CRLF
Size: 421899 bytes
SHA1: 2e2b28aecd80
U+FFFD: 0
bytes>127: 745
CRLF: 8541
The file contains 745 non-ASCII characters, including common Spanish characters such as á, é, í, ó, ú, ñ and ª.
I asked OpenCode to make a trivial change: append a single space to an existing comment line. OpenCode performed the change using its built-in edit tool.
After the edit:
Size: 423390 bytes
SHA1: 981e864147c9
U+FFFD: 745
bytes>127: 2235
CRLF: 8541
The requested change was only one ASCII space, but all 745 existing non-ASCII characters elsewhere in the file were corrupted and replaced with U+FFFD.
The CRLF count remained unchanged, so the corruption is specifically related to character encoding, not line-ending conversion.
Expected behavior
The tool should preserve the original Windows-1252 encoding.
If preserving the encoding is not supported, edit/write should refuse to modify the file and return an explicit warning instead of silently corrupting it.
Related issues
Same underlying problem as #28521, which was closed due to inactivity rather than fixed.
Also related: #27832 (support for multiple file encodings in built-in tools).
Still reproducible in OpenCode 2.0.32.
Plugins
No response
OpenCode version
2.0.32
Steps to reproduce
-
Create or use a Windows-1252 (cp1252) file with CRLF line endings containing non-ASCII characters, for example Spanish text: "Número de prestación - revisión año 2026"
-
Verify that the file is actually encoded as cp1252 and contains no U+FFFD replacement characters.
-
Ask OpenCode to make a trivial ASCII-only change to the file, for example adding a single space to an existing comment. Let OpenCode perform the change using its built-in edit tool.
-
Compare the file before and after the edit.
-
Verify that non-ASCII characters have been replaced with U+FFFD, even though the requested change only affected ASCII content.
Screenshot
No response
Operating System
Windows 11
Terminal
Windows Terminal / PowerShell 7
Activity
opencode-agent commentedon Oct 20, 2026
Thanks for the detailed report and the byte counts. I think this is a duplicate of #45924, which is still open. The v2
edittool reads the file with a lenient UTF-8 decoder, so every byte that isn't valid UTF-8 (your cp1252á,ñ,ª, …) becomes U+FFFD, and the whole file is written back that way while the tool reports success. That fits your numbers: 745 replacement characters, and 745 × 2 = 1,491 extra bytes.Possible duplicates and related issues, ordered from most to least likely:
edit/apply_patchsilently replace non-UTF-8 bytes with U+FFFD, and one comment there describes a Spanish ISO-8859-1 project like yoursThe bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different. Adding your cp1252/CRLF case to #45924 would also help.
opencode-agent commentedon Oct 21, 2026
Closing this as a duplicate of #45924, as mentioned yesterday, since there's been no reply saying how it differs. The cp1252 bytes being replaced with U+FFFD after an ASCII-only
editis the same bug tracked there: the v2edit/apply_patchtools decode the file as lenient UTF-8 and write it back that way.Please follow #45924 for updates. Adding your cp1252/CRLF case and the byte counts there would help. If this turns out to be a different problem, reply here and it can be reopened.