[BUG] Inconsistent UTF-8 / Unicode Character Handling in Code Outputs (Regression Compared to Sonnet 4.5 / Opus 4.1)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

I’ve recently noticed inconsistent handling of Unicode (UTF-8) characters in the latest Claude models when generating code or code-formatted text. This behavior was not present in earlier versions such as Sonnet 4.5 or Opus 4.1, so it may be related to recent updates.

Observed Behavior

In normal conversation mode, the model outputs Unicode characters correctly (including accented letters, non-ASCII symbols, Turkish characters, etc.).

However, when generating code, the model sometimes:

replaces non-ASCII characters with ASCII equivalents,

omits them entirely,

or avoids using them even in safe contexts such as comments or string literals.

This does not seem to be specific to Turkish; it appears to affect unicode characters in general depending on the context.

Possible Technical Factors

This behavior might be connected to:

recent tokenization adjustments,

stricter normalization rules applied during code generation,

or an unintended side effect of new safety/accuracy tuning.

The issue appears primarily in code mode, not in regular text conversations, suggesting that code-generation-specific output rules may be contributing.

What Should Happen?

Expected Behavior
The model should output Unicode / UTF-8 characters consistently in all contexts, including during code generation.
Non-ASCII characters (such as accented letters, Turkish characters, and other Unicode symbols) should be preserved correctly inside:

code comments

string literals

documentation blocks

filenames or paths

any other code-related text

The output should not replace or remove these characters unless explicitly instructed.

Error Messages/Logs

Steps to Reproduce

Reproduction Steps

Ask the model a normal question in Turkish, without providing any Unicode characters yourself.
Example prompt:

Basit bir örnek kod yazar mısın?


The model should naturally include Turkish words in comments or output (because the request is in Turkish).

Observe the result:

In most cases (about 90–95%), the model outputs the correct Unicode characters such as “ç, ğ, ş, ö, ü, İ”.

In a small number of attempts (5–10%), these characters may:

appear as ASCII versions (“c, g, s, o, u, I”), or

be dropped or altered.

Repeat the request multiple times to confirm the inconsistent behavior.

Minimal Example Prompt
Basit bir kod örneği verebilir misin?

Example Output Showing the Issue

Expected / Correct Output:

print("küçük bir gemi")


Incorrect Output Sometimes Produced:

print("kucuk bir gemi")


This demonstrates the inconsistent handling of Unicode characters.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

claude-opus-4-5-20251101

Claude Code Version

2.0.53 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

I experienced this first while developing a Google extension, and later noticed the same behavior in my main project. I realized that when Claude reads text from anywhere, it starts writing correctly in my language (Turkish characters like “ğ, i, ş, ç, ü”, etc.). Previously, this did not happen at all. Before, when I wrote sentences containing only English characters (i.e., without Turkish letters), it would not work correctly.

For example:
println("ösadö")
If Claude reads this, and the question contains only English characters (no Turkish characters), then even if the conversation is in Turkish, it might or might not use Turkish characters — it’s inconsistent.

Another example:
println("hello")
If Claude reads this and the question contains only English characters, the probability of it responding with English-only characters increases. For instance, it outputs println("nasilsin") instead of the correct println("nasılsın").

If the question contains Turkish characters, and the text it reads also includes Turkish, then it makes no mistakes and responds correctly.

I noticed an additional behavior: when I point out that Claude is forgetting to use Turkish characters, it corrects everything.
For example:
println("kayip ETTIK")
gets updated to
println("kayıp ETTİK").

Now, imagine a scenario where someone is leaning back, in bypass permission mode, developing something, and leaving the entire project to run autonomously. In that case, this behavior could make them feel like they are wasting tokens and time unnecessarily.

I had not seen this for a long time; I did not experience it at all prior to the language update you released. It’s not a huge problem, but I wanted to report it so you are aware. I believe it may have appeared due to precautions or changes introduced in later updates.