Repository navigation
Codex writing special characters like norwegain æåø as mojibake #13743
Description
What version of Codex CLI is running?
codex-cli 0.110.0
What subscription do you have?
Plus
Which model were you using?
gpt-5.4. Also occured with gpt-5.3-codex
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What terminal emulator and version are you using (if applicable)?
No response
What issue are you seeing?
Often when Codex is writing special charactes like norwegain æ, ø and å, they turn to mojibake, like "å" turning into "Ã¥". This has been a recurring issue for me ever since I started using Codex a couple weeks ago. This doesn't always happen, if I tell it to fix the mojibake it manages to fix it, so I am not sure how it arises in the first place.
Sometimes Codex realizes its mistake and starts writing unicode escape sequences directly into strings, instead, but that just makes the strings hard for a human to read.
This doesn't happen with just æøå. I have also noticed the same issue with other special characters like U+200B.
What steps can reproduce the bug?
Uploaded thread: 019cc35c-e806-7ff1-888a-63d3c2618735
What is the expected behavior?
The expected behaviour is that Codex is consistently capable of writing characters like æøå when editing files.
Additional information
No response
Activity
github-actions commentedon Mar 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon Mar 6, 2026
If you're able to repro this, please use
/feedbackto upload your session details and post the thread ID here. We need to determine whether this is model behavior (i.e. behavior that's intrinsic to the model) or a bug in the Codex harness, perhaps related to character encoding. Session details will help us determine which it is.AdrianNO1 commentedon Mar 6, 2026
The Thread ID is the same as above,
019cc35c-e806-7ff1-888a-63d3c2618735. I dug this screenshot up from earlier today, it says the feedback was uploaded so ya'll have the details right?cybervand commentedon Mar 10, 2026
i can confirm that codex has done this for me as well. I think the replication process is to use claude to make a document, it uses alot of characters in the utf8 and ascii. but when codex edits these files it corrupts the documents turning the characters into mojibake.
COPK commentedon Apr 3, 2026
Using Codex, I am constantly encountering this problem regardless of the language I am working in. The latest ChatGPT LLMs generate authentic mojibake, and this is the reason why I stopped using them. The amount of tokens consumed in continuous corrections, which in many cases do not end up solving the errors, makes the use of ChatGPT unacceptable.
myvirtualclone commentedon Apr 5, 2026
I second this! Have the same problem ALL the time. Likely need to stop using Codex as a result. That said, I am no experimenting with adding this instruction which could be Windows-specific: Use PowerShell’s safer line-level encoding to avoid mojibake rewrite problems.
MNeMoNiCuZ commentedon Apr 12, 2026
This started happening recently, some time in March for me as well. For any project, not only for language/country specific character, but any special character it's using, like a checkmark, or a filled line, tree-list symbols or whatever. Things that just used to work is now always getting broken when it's coding.
shiraz-123 commentedon Jun 5, 2026
the isssue still persists (gpt-5.5 high)
AdrianNO1 commentedon Jun 5, 2026
I added to my system instructions to always read/write files using UTF-8 (no BOM). This has worked for many months but yesterday it had the issue again and converted all non-ASCII characters into mojibake in a file it edited.
It hasn't happened again since but it's quite the coincidence that shiraz-123 responds here at the same time.
MNeMoNiCuZ commentedon Jun 5, 2026
@etraut-openai
Any concern about this behavior? I don't see how it can be on the user-side as it keeps happening. We need to instruct our agents to not behave in the default way they are behaving. It seems wrong.
icaroperetti commentedon Jul 13, 2026
Still happening
dimitar-grigorov commentedon Jul 26, 2026
Might help narrow this down. Check the bytes on disk after a bad edit:
c3 a5is correct UTF-8 for å, whilec3 83 c2 a5means it got double-encoded on the way out. If the file is correct on disk but the agent still showsÃ¥in context, the corruption is on the read side rather than the write side, which matches #15422.Routing file reads and writes through an MCP server with its own file I/O avoids the console-codepage path entirely. I maintain one, so treat this as a biased suggestion rather than a fix: https://github.com/dimitar-grigorov/mcp-file-tools