Edit tool corrupts non-ASCII Unicode characters (typographic quotes) in string literals

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?

When Claude Code agents use the Edit tool to modify lines containing non-ASCII Unicode characters — specifically typographic (curly) double quotes „ (U+201E), “ (U+201C), and ” (U+201D) — the characters are silently corrupted during the replacement. This results in syntactically invalid source code (e.g., C# string delimiters replaced with typographic quotes, or typographic quotes inside strings replaced with ASCII quotes).

The corruption happens inside the agent's generated old_string/new_string values, not due to user error. Even when the agent is explicitly and repeatedly instructed to avoid touching lines with these characters, the Edit tool's string matching or the model's token representation appears to mangle them during round-tripping.

This is not a one-off: it has occurred across multiple independent agents in the same session, and was also observed in a prior session (documented in project notes as a known issue that forced a full revert of an earlier attempt).

<img width="3257" height="238" alt="Image" src="https://github.com/user-attachments/assets/21451fe5-46fe-4fd8-be01-f7a8fad38932" />

What Should Happen?

The Edit tool should preserve all Unicode characters byte-for-byte. If the old_string contains „ (U+201E), the matched region in the file should contain that exact codepoint, and the new_string should emit it unchanged. No codepoint substitution, normalization, or encoding conversion should occur.

Error Messages/Logs

Steps to Reproduce

1. Create a C# file Test.cs with UTF-8 encoding containing typographic quotes inside string literals:

using System;

class Test
{
    void Foo()
    {
        Console.WriteLine("Execution path „{0}” completed with status „{1}”", "path1", "ok");
    }
}

Note: The outer " are ASCII double quotes (U+0022, C# string delimiters). The inner „ is U+201E (DOUBLE LOW-9 QUOTATION MARK) and ” is U+201C (LEFT DOUBLE QUOTATION MARK) — these are literal characters inside the string content.

1. Ask Claude Code to make a small edit to the same line — for example, appending ! to "ok":

Change "ok" to "ok"! on the Console.WriteLine line in Test.cs

1. Observe the resulting file. The typographic quotes „ and ” inside the string will be corrupted — typically replaced with ASCII " (U+0022), which breaks the C# string literal parsing because the compiler now sees unbalanced string delimiters.

1. Attempting to compile produces errors like:

error CS1056: Unexpected character '"'
error CS1003: Syntax error, ',' expected

Why it happens even with explicit instructions: In my session, I gave agents detailed instructions including:

CRITICAL: This file contains typographic/Unicode quotes (U+201E „, U+201C “, U+201D ”). You MUST preserve these exactly. When using the Edit tool, avoid including these characters in old_string — instead use unique surrounding code that doesn't include the special quotes.

Despite this, agents that needed to edit on or near a line containing these quotes still produced corrupted output. The instruction to "use surrounding code that doesn't include the special quotes" helps only when the edit target is on a different line — if the fix must touch the same line (e.g., adding ! after .FullName on a line that also contains „{0}“), the agent must include the line content in old_string/new_string, and corruption occurs during that round-trip.

Real-world files affected in this session:

• WorkflowExecutionPathStepJob.cs line 52 — „{0}“ corrupted
• WorkflowConditionResolver.cs line 61 — „{0}“ corrupted
• (Likely more across ~20 files edited by parallel agents)

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.83 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

• Platform: Windows Server 2025, bash shell
• File encoding: UTF-8 (no BOM)
• The corruption pattern is consistent: typographic quotes in C# string literals get replaced with ASCII quotes or with the wrong Unicode codepoint, breaking string delimiter parsing
• Workaround attempted: Instructing agents to use unique substrings that avoid the special characters in old_string. This works only when the edit is on a different line. It fails when the edit must modify the same line that contains typographic quotes.
• Impact: In a previous session, this exact bug forced a full revert of all Workflow project changes. In this session, it caused 489 compilation errors from what should have been safe, targeted edits.
• Possible root cause candidates:

1. The model's tokenizer may normalize or substitute visually-similar Unicode characters during generation
2. The Edit tool's string matching may use a normalization form that conflates U+201E/U+201C/U+201D with U+0022
3. The transport layer between model output and tool execution may re-encode strings in a way that loses the distinction