Windows: editing non-UTF-8 Unity C# files can corrupt Korean text after invalid UTF-8 detection

### What version of Codex is running?

Codex Desktop on Windows.

Which model were you using?

GPT-5 Codex in the desktop app.

What platform is your computer?

Windows (PowerShell environment)

What steps can reproduce the bug?

1. Have a Unity .cs file that contains Korean text and is not UTF-8 encoded (for example CP949 / ANSI style encoding).
2. Try to modify it through a UTF-8-only patch/edit path.
3. In my case, an initial patch attempt failed with an error equivalent to:

stream did not contain valid UTF-8

1. After that, a structured edit path rewrote the file as UTF-8.
2. Some original Korean comments/strings from the non-UTF-8 file were not preserved correctly and became replacement characters / corrupted text.

What is the expected behavior?

If a file is not valid UTF-8, Codex should avoid unsafe text rewriting that can silently destroy non-ASCII characters.

Ideally one of these should happen:

• refuse the edit clearly and stop before rewriting
• preserve the original encoding
• or require an explicit encoding conversion step before editing

What do you see instead?

A non-UTF-8 Unity C# file can enter a mixed workflow where:

• one edit path correctly detects invalid UTF-8 and fails
• but another edit path still rewrites the file as UTF-8
• and Korean text is partially corrupted during the process

This is not only terminal display mojibake. In the bad step, the file contents themselves were actually damaged.

Important clarification

There were two separate issues during debugging:

1. Real file corruption

• original file was non-UTF-8
• UTF-8-based edit path touched it
• Korean text was actually damaged in file contents

1. Later display-only confusion

• after recovery, the file was saved as UTF-8 without BOM
• Windows PowerShell sometimes displayed it incorrectly depending on how it was read
• that second phase was output/terminal interpretation only, not file corruption

The bug report here is about the first issue: unsafe editing of non-UTF-8 source files.

Additional information

This happened with a Unity C# source file containing Korean comments. Other modified files in the same workspace were already valid UTF-8 and did not have the same problem.

So this seems to be a file-encoding edge case rather than a general Korean-text failure on every file.