[Bug] Edit tool fails on mixed literal/escape Unicode in multi-line old_string

I just ran into this again:

● Now add the test block at the end of the file:

● Update(~/worktrees/proj/tests/utils.test.ts)
  ⎿  Error editing file

  Read 1 file (ctrl+o to expand)

● Update(~/worktrees/proj/tests/utils.test.ts)
  ⎿  Error editing file

  Read 1 file (ctrl+o to expand)

● There's a non-breaking space character in that line. Let me use a different approach — append to the file:

  Regarding those Claude Code issues you linked — sorry about the Edit failures with the non-breaking space. The \u00a0
  character in the test file (expect(plain).not.toContain('\u00a0')) caused the string match to fail because the Read tool
  displays it as a regular space but Edit requires an exact byte match. I worked around it by using cat >> to append instead.
  Known issue, unfortunately.

● You're absolutely right. The JSON encoding does have the ability to distinguish these:

  - \u2014 in JSON → literal em-dash codepoint —
  - \\u2014 in JSON → the 6 ASCII characters \u2014

  So the tool parameter old_string could carry "$2 \u2014 $5",\n  "Cake price: $20 \\u2014 $40" and the Edit tool would receive the correct mixed representation —
  literal em-dash on line 3, backslash-u-2-0-1-4 on line 4.

  The bug isn't a fundamental JSON limitation at all. Something in the pipeline is either:

  1. Double-unescaping — treating the already-decoded \u2014 text as a JSON escape again
  2. The model (me) not emitting the right escaping — I'm generating \u2014 when I should be generating \\u2014 for the literal-backslash case, and the tool-calling
  layer doesn't give me fine-grained control over the JSON encoding
  3. The Edit tool normalizing on its own before matching, collapsing the distinction that JSON preserved

  It's likely a combination of 2 and 3 — I don't have direct control over the JSON serialization of my tool parameters, so even if I "intend" \\u2014, the
  tool-calling layer may emit \u2014. And then the Edit tool's fallback tries all-escaped or all-literal but not mixed.

  Either way, you're right that it's solvable within JSON. The fix would need to happen in the Claude Code tool-calling layer or the Edit tool's matching logic — not
  in the JSON spec.

@claude

Root cause: the Read → model → Edit round-trip is lossy

The Edit tool's string matching has a cascade of fallbacks (smart quotes, \uXXXX ↔ codepoint swapping, etc.) that try to compensate when old_string doesn't exactly match the file. This bug adds yet another case the fallbacks don't cover. But the deeper question is: why are fallbacks needed at all?

The answer is that Read's output is ambiguous. When a file contains the 6 ASCII characters \u00a0, Read displays them identically to a literal non-breaking space. The model can't tell which one the file has, so it guesses when composing old_string. Then the Edit tool has to guess back.

Every fallback in the matching logic — smart quote normalization, all-escaped regex, all-literal regex, and now the mixed-mode regex this bug needs — exists to compensate for that one upstream ambiguity. If the Read → model → Edit round-trip preserved the file's exact bytes, old_string matching would just be ===.

This specific bug

The existing fallbacks handle two cases:

• All-escaped: every high-Unicode char in the region is \uXXXX in the file
• All-literal: every high-Unicode char is a literal codepoint

They don't handle the mixed case: the same character as a literal codepoint on one line and \uXXXX on another. The all-escaped regex demands every position be escaped; the direct includes() demands every position be literal. Neither matches.

Pragmatic short-term fix

The minimal fix is a buildMixedRegex function — a sibling of the existing buildAllEscapedRegex — that matches either form at each high-Unicode position:

// Existing: buildAllEscapedRegex("x — y") → regex matching "x — y"
//     Every high-Unicode position must be \uXXXX.

// New: buildMixedRegex("x — y") → regex matching "x (?:—|—) y"
//     Each high-Unicode position can be either form.

function buildMixedRegex(str) {
  let result = "";
  for (const ch of str) {
    const code = ch.charCodeAt(0);
    if (code >= 0x80) {
      const hex = toInsensitiveHex(code);
      result += `(?:${escapeRegex(ch)}|\\\\u${hex})`;
    } else {
      result += escapeRegex(ch);
    }
  }
  return result;
}

Used as a fallback after the all-escaped regex fails. This fixes the match, but the replacement normalizes \uXXXX escapes to literal codepoints — because the model never knew which positions were escaped, that information was lost at Read time.

A further fix to the representation mapper can reconstruct per-position literal vs escaped by walking the matched string and old_string with dual cursors, then applying the same mapping to new_string. This preserves the file's original representation. But it's reconstructing information that was thrown away upstream — the complexity exists only because Read doesn't preserve it.

The clean fix

Make the Read → model → Edit round-trip lossless. If Read's output unambiguously represents the file's bytes — so that \u00a0 (6 ASCII chars) is visually distinct from   (1 char) — the model can reproduce the exact bytes in old_string, and matching is just ===. No fallback cascade, no mixed-mode regex, no dual-cursor reconstruction.

Tests

I've attached a vitest file covering the cases. It uses readable aliases (findActualMatch, mapNewString) — just wire up the real imports at the top. Covers:

• findActualMatch: direct match, mismatch, all-literal, all-escaped, mixed (both directions), mixed NBSP, mixed different codepoints, double-escaped \\u, full #64479 repro
• mapNewString: identity, all-escaped, all-decoded, mixed per-position preservation, different codepoints, extra chars default to literal, full #64479 repro
• End-to-end: both functions composed, including the #52813 NBSP case

Still reproduces on Claude Code v2.1.209 (model: Opus 4.8), macOS (darwin 24.1.0).

Repro — recipes.ts where the same char (em-dash —) appears both ways in adjacent lines:

• line 3: literal codepoint (UTF-8 bytes 342 200 224)
• line 4: the 6 ASCII chars \ u 2 0 1 4 (—)

Results:

• Edit spanning both lines in one old_string → ❌ fails.
• Edit of either line alone → ✅ succeeds (all-literal / all-escaped paths each work).

So the failure is still specific to a single old_string spanning both forms, exactly as described — the whole-string swap fallback is all-or-nothing and matches neither variant.

One thing has changed since the v2.1.159 report: the error is now more informative instead of a bare Error editing file:

String to replace not found in file.
String:   "Cookie price: $2 — $5",
  "Cake price:   $20 — $40",
(note: Edit also tried swapping \uXXXX escapes and their characters; neither
form matched, so the mismatch is likely elsewhere in old_string. Re-read the
file and copy the exact surrounding text.)

The tool now tells you it attempted the swap and gives up cleanly — but the underlying mixed-form gap (and the per-position (?:—|\\u2014) fix proposed above) is unchanged.

Workaround unchanged: byte-exact sed/node/bun via Bash, or one Edit per line.

Still reproduces on Claude Code v2.1.220 (model: Opus 5), macOS (darwin 24.1.0). Previously confirmed on v2.1.209.

Repro — same as before, a file where the em-dash appears both ways on adjacent lines:

printf '  "a: $2 \xe2\x80\x94 $5",\n  "b: $20 \\u2014 $40",\n' > f.ts

• line 1: literal codepoint (bytes e2 80 94)
• line 2: the 6 ASCII chars \u2014 (bytes 5c 75 32 30 31 34)

Results:

| Case | Result |
|---|---|
| old_string spanning both lines | ❌ String to replace not found in file |
| line 1 alone (literal —) | ✅ |
| line 2 alone (ASCII \u2014) | ✅ |

After the two single-line edits, xxd confirms both representations survived intact and were each individually matchable:

00000000: 2020 2261 3a20 2432 20e2 8094 2024 3520    "a: $2 ... $5
00000010: 4f4b 3122 2c0a 2020 2262 3a20 2432 3020  OK1",.  "b: $20
00000020: 5c75 3230 3134 2024 3430 204f 4b32 222c  \u2014 $40 OK2",

So neither line is unmatchable on its own — only the span fails.

---

One new observation that supports the lossy-round-trip diagnosis above:

When I attempted the spanning edit with the mixed form (literal — on line 1, ASCII \u2014 on line 2), the error echoed my old_string back with a literal em-dash on both lines:

String:   "a: $2 — $5",
  "b: $20 — $40",

The escape was decoded somewhere before Edit saw it. So the all-literal attempt and the mixed attempt arrive byte-identical — as far as I can tell there is currently no way to express the mixed form in old_string at all, which means the model cannot work around this even in principle. The whole-string swap fallback then has only two candidates, and the file matches neither.

Workaround remains: one Edit per line, or a byte-exact sed/node call via Bash.

Bug #64479 still reproduces on Claude Code 2.1.220

One notable difference: the error message is now more specific — it explicitly says it tried swapping \uXXXX escapes for literal chars and neither matched, instead of the old generic "Error editing file." Root cause is unchanged.

Still reproduces in Cowork sandbox