Codex writing special characters like norwegain æåø as mojibake
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_
11 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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.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?<img width="561" height="70" alt="Image" src="https://github.com/user-attachments/assets/50421ef1-c128-4bc1-8ba1-cbd650939a59" />
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.
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.
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.
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.
the isssue still persists (gpt-5.5 high)
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.
@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.
Still happening