Agents trust the shell to read a file correctly
Windows PowerShell 5.1 still reads BOM-less UTF-8 as a 1990s code page, without a warning. Agents edit through the shell all day, so silent transcoding is now an AI-compatibility bug, and the SOS standard is adding text-encoding requirements to say so.
An AI agent that edits a file through a shell assumes the shell read the file correctly. On a default Windows machine that assumption is wrong for any UTF-8 file without a byte-order mark, and the shell will not tell anyone. We think that makes legacy encoding defaults an AI-compatibility bug in the shell, not a user error, and we are writing it into the SOS standard as one.
One em dash, three characters
The failure is easy to reproduce.
Windows PowerShell 5.1, still the program behind powershell.exe, reads a BOM-less file with Get-Content as the system ANSI code page.
An em dash is three bytes in UTF-8, so the shell hands the agent three characters instead of one.
The agent changes the line it cares about and writes the file back with Set-Content, and every dash in the file is now stored as —.
No exit code changes. No warning is printed. The pipeline reports success.
Dev-Centr hit exactly this in October 2026: an agent’s commit garbled a GitHub Actions workflow badly enough that GitHub refused to parse it, and older changelog prose had been carrying the same damage for a month without anyone noticing. Their write-up, The AI agent broke my em dashes and signed my name, covers the incident and the guard they now run.
PowerShell 7 fixed these defaults years ago. That is the point: the fix exists, and the default a machine ships with still does not use it. Agent harnesses take whatever shell is guaranteed to be there.
Why agents make an old bug new
Humans have run into code-page mojibake for decades and mostly survived it, because a human edits in an editor that sniffs encodings and looks at the result. An agent does neither. It edits through stdin, stdout and file redirection, it does so hundreds of times a session, and it treats "the command returned zero" as "the command did what I asked."
It also cannot see the problem afterwards.
To a language model, — is three plausible tokens.
Unless something in the toolchain flags the bytes, the corruption is indistinguishable from content.
That is the same pattern OpenShellOrg keeps returning to, from structured pipelines to tool-run diagnostics: a shell that only produces human-readable text, and only fails in ways a human would notice, is hostile to the programs now doing most of the typing.
What a shell should guarantee
Silent transcoding is a lie about what is in a file. The requirements we are adding to the SOS design considerations come down to refusing to lie:
-
UTF-8 is the default for reading files, writing files, pipes between commands, and the console. Not the system code page, not UTF-16, not "it depends on the cmdlet."
-
No silent code-page conversion. If bytes are not valid in the encoding being used, that is an error or a structured warning, never a quiet best-effort decode.
-
Legacy encodings are a loud, explicit opt-in, named per command, and reported in machine-readable output so the caller knows a conversion happened.
-
Byte-order marks are handled, not invented. Read and strip them; never add one unless asked.
-
Round trips are safe. Read a file and write it back with no changes, and you get the same bytes.
-
Encoding errors are machine-readable, with the path, byte offset and the encoding that was assumed, so an agent can stop instead of saving garbage.
None of this is exotic. Nushell already behaves this way, and PowerShell 7 mostly does. What is missing is a standard that says shells and SOS-compliant tools must, so agent authors can rely on it instead of rediscovering the bug repository by repository.
The normative text is in the standard’s Design Considerations, under AI compatibility concerns. Until shells meet it, put a byte-signature guard in front of your commits; Dev-Centr’s Prevent text encoding corruption guide shows one.