On Windows systems, non-Latin characters can still become garbled even when everything is configured to UTF-8

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #6998
• #6178

Powered by Codex Action

Same issue experienced, and replicable in the latest GPT-5.2 model as well.

I can confirm this behavior on Windows 11 with PowerShell 7.5.
In my case, the CLI output (which is GBK/CP936 by default) was incorrectly detected/decoded as EUC-JP by the internal node logic, resulting in Japanese-like garbled text (e.g., 数据结构 becoming 方象潤更).
Manually forcing $OutputEncoding = [System.Text.UTF8Encoding]::new($false) in my $PROFILE fixes the interactive CLI session, but as the OP mentioned, if the extension spawns shells with -NoProfile, my fix will be bypassed.

---

System-level Workaround

Since the extension likely uses -NoProfile, the $PROFILE fix is bypassed during agent execution. The only way to enforce UTF-8 for these spawned processes is to change the Windows system locale.

Steps:

1. Press Win + R, type intl.cpl, and hit Enter.
2. Go to the Administrative tab -> Change system locale....
3. Check "Beta: Use Unicode (UTF-8) for worldwide language support".
4. Restart Windows.

Note: This changes the system code page to 65001 globally. While this resolves the encoding issue for Codex, it may cause display issues in older, non-Unicode legacy applications.

We merged an experimental fix for this in #7902, which you can test out by running codex --enable powershell_utf8 or adding features.powershell_utf8 = true to your config.toml.

@jingkarqi @sd1114820 @aosumi-rena can you try this feature out and let us know if it works for you?

We merged an experimental fix for this in #7902, which you can test out by running codex --enable powershell_utf8 or adding features.powershell_utf8 = true to your config.toml. @jingkarqi @sd1114820 @aosumi-rena can you try this feature out and let us know if it works for you?

@dylan-hurd-oai
Thanks for the reply.
I performed very thorough testing, checking not only the latest build but also specifically rolling back to the problematic v0.73.0, as well as several versions before and after it.

Test results:
What is very strange is that I am currently unable to reproduce the garbled text behavior on all versions.
Even though I strictly restored the environment to how it was, Codex can now handle Chinese correctly.

Suspected reason:
I suspect that the previously enabled "Windows System-wide UTF-8 (Beta)" option caused some irreversible or hidden configuration residue at the system level (even after "disabling" it), causing the current environment behavior to no longer be consistent with when the issue was first reported.

Conclusion:
Since I have completely lost the control group, I cannot perform valid comparative experiments to test the effectiveness of the --enable powershell_utf8 flag. I apologize for this and for not being able to provide exact verification data.
But the good news is that currently, whether adding this flag or not, it runs normally on my machine.

Thanks for the feedback!

thread ID 019bbc5f-ba20-7692-bb0b-b2dd9df03298
I encountered a similar issue. On Windows, Codex attempts to use PowerShell to replace file content and keeps failing

codex --enable powershell_utf8features.powershell_utf8 = true

I didn't encounter any issues after adding features.powershell_utf8 = true. However, I switched from using the extension in VS Code to using it in Cursor, in case that matters.

Also, I'm still using PowerShell 7 with UTF-8 set as the default encoding. I'm not sure if the issue would occur on PowerShell 5, but for now, I haven't noticed any problems.

@sd1114820, thanks for the confirmation. It sounds like powershell_utf8 is working well, so we're planning to enable that by default for everyone.

seems when windows native sandbox enabled, this powershell_utf8 setting to true will result in this error
InvalidOperation: Cannot set property. Property setting is supported only on core types in this language mode..
I want to know if this is expected?

Wasn't this made the default in the latest release? "Windows builds enable the PowerShell UTF-8 feature by default. (#9195)"?
https://github.com/openai/codex/releases/tag/rust-v0.87.0

Yes, the feature flag powershell_utf8 is now enabled by default as of 0.87.0.

I'm going to close this issue. If you're still seeing problems with garbled characters or with the new powershell_utf8 feature, please open a new bug report with details.

@TTTPOB, the error you're seeing isn't expected. If you're able to repro it with the latest version of the CLI, please open a new bug report using the /feedback slash command.

Feedback on the recent patch:

I am still encountering the encoding issue with the latest update. I dug into the execution logs and found the specific cause that might have been overlooked.

The tool is explicitly executing: powershell -Command "(Get-Content ...)"

The problem: Even on a modern Windows setup (PowerShell 7 + UTF-8), invoking powershell spawns a legacy PowerShell 5.1 subprocess. This subprocess defaults Get-Content to ANSI encoding, ignoring the parent environment's UTF-8 setting.

Fix: The patch needs to ensure that when powershell (legacy) is called, the argument -Encoding UTF8 is explicitly included in the Get-Content command string. Alternatively, calling pwsh would also resolve this. @etraut-openai @dylan-hurd-oai