You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes because when an AI makes a modification to a script, this one, opencode modifies the encoding to UTF8, and I would like this to keep the encoding of the file which it was in UTF8 with Bom
This issue is actually bigger than it suggests: OpenCode corrupts PowerShell files
OpenCode strips UTF-8 BOM when editing files, which breaks PowerShell scripts with international characters (å, ä, ö, etc.). PowerShell requires UTF-8 BOM to correctly interpret non-ASCII characters.
Reproduction:
example.ps1 (UTF-8 with BOM) Write-Host "Börjar bearbetning..."
Before OpenCode edit: file example.ps1 → "UTF-8 (with BOM)" ✓ works
After OpenCode edit: file example.ps1 → "UTF-8" (no BOM) ✗ shows gibberish in PS 5.1
Any edit to a PowerShell file removes the BOM and corrupts the script, making OpenCode unusable for PowerShell development in non-English environments.
The issue is compounded by saving files with LF line endings and certain PowerShell syntax patterns in PowerShell 5.1.
While simple scripts with LF line endings may parse correctly, PowerShell 5.1 fails to parse files with LF line endings when they contain method calls with quoted string arguments, such as .Trim('"').
Minimal reproduction case:
test-complex.ps1 (saved with LF line endings, UTF-8 without BOM)
At test-complex.ps1:3 char:34
+ $triggerLevel = $parts[2].Trim('"')
+ ~~
The string is missing the terminator: '.
Solution: Converting the file to CRLF line endings (with or without UTF-8 BOM) resolves the parsing error completely. PowerShell 7+ does not exhibit this issue and handles LF line endings correctly.
Note on tooling: Standard Unix tools like sed, awk, and Git Bash (MINGW) typically convert files to LF line endings, making them incompatible with PowerShell 5.1 for scripts using this syntax pattern. When modifying PowerShell scripts in mixed Unix/Windows environments, the user must verify line ending format manually before deployment to Windows PowerShell 5.1 environments.
Root cause: PowerShell 5.1's parser incorrectly handles quoted strings as method arguments when preceded by LF-only line terminators, causing it to misinterpret the quote termination.
I am also experiencing this issue. More specifically I have Windows-1252 encoded files, that keep being changed to UTF-8, breaking international characters, thus introducing compilation erros
@rekram1-node Are you deliberately misinterpreting the issue and actively trying to kill the product and its community, because this is how you do it. Get your act together. Please do not interpret politeness or incompleteness as "a non issue" when there is clear evidence of such! The bug here is that Open code is changing the file format for edited files, destroying working code. since the write-file-format is UTF8 without BOM only.
Reacted by Adrien Peyre, Anton Egholm, a-n-r-o, Serhii K and Jean-François Pustay
Activity
rekram1-node commentedon Oct 21, 2025
u want opencode to create non utf8 files, is that correct (or the option to) via BOM
LexBoosT commentedon Oct 22, 2025
Yes because when an AI makes a modification to a script, this one, opencode modifies the encoding to UTF8, and I would like this to keep the encoding of the file which it was in UTF8 with Bom
rekram1-node commentedon Oct 22, 2025
gotcha
renanfranca commentedon Jan 22, 2026
I am interested in that feature too. In my case, I am working on a project encoded with
ISO-8859-1. Every time a file is edited, it transforms the file intoUTF-8. I tried to turn the formatter option tofalse(https://opencode.ai/docs/formatters/#disabling-formatters)13640535881 commentedon Feb 12, 2026
Any progress?
Mikael-Gustavsson commentedon Feb 16, 2026
This issue is actually bigger than it suggests: OpenCode corrupts PowerShell files
OpenCode strips UTF-8 BOM when editing files, which breaks PowerShell scripts with international characters (å, ä, ö, etc.). PowerShell requires UTF-8 BOM to correctly interpret non-ASCII characters.
Reproduction:
example.ps1(UTF-8 with BOM)Write-Host "Börjar bearbetning..."Any edit to a PowerShell file removes the BOM and corrupts the script, making OpenCode unusable for PowerShell development in non-English environments.
Expected:
Mikael-Gustavsson commentedon Feb 17, 2026
Further investigation shows:
While simple scripts with LF line endings may parse correctly, PowerShell 5.1 fails to parse files with LF line endings when they contain method calls with quoted string arguments, such as .Trim('"').
Minimal reproduction case:
test-complex.ps1 (saved with LF line endings, UTF-8 without BOM)
PowerShell 5.1 output:
Solution: Converting the file to CRLF line endings (with or without UTF-8 BOM) resolves the parsing error completely. PowerShell 7+ does not exhibit this issue and handles LF line endings correctly.
Note on tooling: Standard Unix tools like sed, awk, and Git Bash (MINGW) typically convert files to LF line endings, making them incompatible with PowerShell 5.1 for scripts using this syntax pattern. When modifying PowerShell scripts in mixed Unix/Windows environments, the user must verify line ending format manually before deployment to Windows PowerShell 5.1 environments.
Root cause: PowerShell 5.1's parser incorrectly handles quoted strings as method arguments when preceded by LF-only line terminators, causing it to misinterpret the quote termination.
13640535881 commentedon Mar 11, 2026
Why not pay attention to it? This is a big problem
Anantonon commentedon Mar 23, 2026
I am also experiencing this issue. More specifically I have Windows-1252 encoded files, that keep being changed to UTF-8, breaking international characters, thus introducing compilation erros
adpeyre commentedon May 5, 2026
Same issue with ISO encoding.
rekram1-node commentedon Jun 23, 2026
Automated: closing question issues.
GitHub Issues are for bug reports and feature requests only — questions / support are no longer tracked here.
If this is a bug or feature request, please open a new issue with the appropriate template.
Mikael-Gustavsson commentedon Jun 23, 2026
@rekram1-node Are you deliberately misinterpreting the issue and actively trying to kill the product and its community, because this is how you do it. Get your act together. Please do not interpret politeness or incompleteness as "a non issue" when there is clear evidence of such! The bug here is that Open code is changing the file format for edited files, destroying working code. since the write-file-format is UTF8 without BOM only.