Edit tool replaces Turkish UTF-8 characters with ASCII equivalents

[morphaven]

Preflight Checklist

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

What's Wrong?

When using the Edit tool to modify files containing Turkish UTF-8 characters, Claude Code systematically replaces Turkish special characters with their ASCII equivalents:

• ş → s
• ı → i
• ğ → g
• ü → u
• ö → o
• ç → c
• Ş → S
• İ → I
• Ğ → G
• Ü → U
• Ö → O
• Ç → C

This happens both when:

1. Adding new content that contains Turkish characters
2. When the edit touches existing Turkish text in the file

The corruption occurs silently without any warning, causing data loss and requiring manual fixes.

What Should Happen?

Claude Code should preserve all UTF-8 characters exactly as they appear in the source content. Turkish characters (and other non-ASCII Unicode characters) should remain unchanged when:

1. Reading files with Turkish content
2. Editing files that contain Turkish characters
3. Writing new content that includes Turkish characters

The Edit tool should be encoding-aware and maintain byte-for-byte accuracy for all UTF-8 content.

Error Messages/Logs

Steps to Reproduce

1. Create a file with Turkish content:

   // test.ts
   const message = 'Merhaba dünya! Türkçe karakterler: şğüöçı'

2. Ask Claude to edit the file (e.g., "add a console.log statement"):

   claude "Add a console.log to print the message in test.ts"
   

3. After the edit, check the file content:

   // Result - Turkish characters are corrupted:
   const message = 'Merhaba dunya! Turkce karakterler: sguoci'

Real-world example from my session:

• Original file had: 'PWA (Progressive Web App) özellikleri kapsamlı şekilde geliştirildi'
• After Claude's edit: 'PWA (Progressive Web App) ozellikleri kapsamli sekilde gelistirildi'

The issue is 100% reproducible with any file containing Turkish characters.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.0.69 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Impact

This bug affects all non-English languages that use special UTF-8 characters, including but not limited to:

• Turkish (ş, ğ, ı, ü, ö, ç)
• German (ä, ö, ü, ß)
• French (é, è, ê, ë, à, ç)
• Spanish (ñ, á, é, í, ó, ú)
• Portuguese, Polish, Czech, and many others

Workaround

Currently, users must manually review and fix all edited files after each Claude Code operation, which is time-consuming and error-prone.

Hypothesis

The issue may be related to:

1. Character encoding during file read/write operations
2. Internal string normalization that converts to ASCII
3. A tokenization or processing step that strips non-ASCII characters

Notes

• The bug is 100% reproducible
• Affects both the Edit and Write tools
• Happens regardless of file type (.ts, .tsx, .js, .json, .md, etc.)
• File encoding is UTF-8 with proper BOM

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Characters å,ä and ö are replaced with � when Claude Code edit files #7335
2. Write tool corrupts UTF-8 multi-byte characters (box-drawing chars become NULL bytes) #13080
3. [BUG] Claude Code does not respect file encoding, corrupts Windows-1252 files #7134

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[xrchz]

This is also broken for Unicode quotes (‘, ’, “, ”) being replaced by ASCII quotes (', ").

[xrchz]

● Yes, I understand:

  - For term quotations: U+2018 (LEFT SINGLE QUOTATION MARK) and U+2019 (RIGHT SINGLE QUOTATION MARK)
  - For parsed terms: U+201C (LEFT DOUBLE QUOTATION MARK) and U+201D (RIGHT DOUBLE QUOTATION MARK)

  The issue is that when I write edits, they may be getting converted to ASCII quotes (U+0027 or U+0022). Let me try writing with explicit Unicode escapes or see if I can preserve them.

Such a capable model held back by such garbage software.

[xrchz]

I should note I am using GNU/Linux - this is not just a Windows issue.

[xrchz]

Consolidated Impact Analysis - This Needs Priority Attention

I've analyzed this issue along with at least 6 related open issues that all stem from the same root cause: Claude Code's Edit/Write tools have fundamental UTF-8 encoding bugs.

Related Issues (All Still Open/Affecting Users)

Issue	Description	Status
#13939	Turkish UTF-8 characters → ASCII	Open
#13080	UTF-8 multi-byte chars → NULL bytes	Open
#7134	Windows-1252 encoding corruption	Open
#7332	Chinese characters garbled	Open
#7335	Swedish å,ä,ö → replacement char	Recently closed (inactivity, not fixed)
#6246, #5518, #3416	Earlier duplicates	Various

Why This Is High Priority

1. Affects ALL non-English users - Turkish, German, French, Spanish, Portuguese, Chinese, Japanese, Nordic languages, and anyone using Unicode symbols

2. Silent data corruption - No warning is given. Users discover corruption after the fact, often after committing to git

3. 100% reproducible - This isn't a flaky edge case. It happens every single time

4. Core functionality is broken - Edit and Write are fundamental tools. If they corrupt data, Claude Code cannot be trusted for international codebases

5. Token waste - Users spend tokens asking Claude to fix the corruption it caused (see comment in [BUG] Claude Code does not respect file encoding, corrupts Windows-1252 files #7134: "fixing the errors generated by this issue consumes a lot of tokens")

6. Competitive disadvantage - Users in [BUG] Claude code bash command execution, output Chinese characters appear as garbled text #7332 note "Gemini CLI seems to be free of this problem"

Technical Pattern Identified

From #13080's excellent analysis, the bug appears to be truncating UTF-8 multi-byte sequences to single bytes:

• Character ─ (U+2500) should be e2 94 80 (3 bytes)
• Actually written as 00 (just codepoint & 0xFF)

This suggests the encoding pipeline is treating Unicode codepoints as single bytes somewhere in the Write/Edit implementation.

Request

Could this be escalated internally? The volume of duplicate issues (spanning 6+ months) and the fundamental nature of the bug suggest this deserves engineering attention before more features are added.

cc @dicksontsai (who acknowledged this pattern in #7335)

---

🤖 Generated with Claude Code