Edit fuzzy match misses lines with differences in whitespace length

[robjgray]

What happened?

normalizeForFuzzyMatch doesn't collapse runs of whitespace or strip leading whitespace. Edit's oldText fails the fuzzy match when the whitespace isn't exact, even though the content is identical. I found his while looking into some problems small models were having with the edit tool. The same problem can occur with pi -ne and no extensions loaded.

Steps to reproduce

Edit a line where the only difference from oldText is the length of a whitespace section.

• a b vs a b

Expected behavior

I expected the fuzzy match to catch it and treat whitespace sections as equivalent. So whitespace-only differences would still lead to a match.

Version

0.80.5

NOTE: I investigated this with GLM-5.2 in Pi. Originally it eagerly raised the issue with a freeform issue body and verbose title before I fully reviewed the problem - truly sorry about that!

[github-actions]

This issue was auto-closed. All issues from new contributors are auto-closed by default.

Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md will not be reopened or receive a reply.

If a maintainer replies lgtmi on one of your issues, your future issues will stay open. If a maintainer replies lgtm, your future issues and PRs will stay open. The command must be at the start of the reply (optionally after one or more @username mentions) or at the end.

See CONTRIBUTING.md.

[barbatdev]

Asking to reopen this. The symptom is widespread and concretely degrades agent behavior: when oldText differs only in whitespace run (tabs vs spaces, or indentation depth), the fuzzy match fails and the model falls back to rewriting the whole file via a Python/shell script instead of using edit.

That workaround is not a niche observation. It comes up regularly in the Gentleman Programming community as "why does the agent stop using edit and start writing Python scripts to modify files?" The root cause traces back here: normalizeForFuzzyMatch has no whitespace-run collapse and no leading-indent tolerance, so semantically identical lines with different whitespace fail to match.

Two prior PRs targeted this area and both were auto-closed by the new-contributor policy before any maintainer review (not rejected on merits):

• fix: normalize tabs to spaces in edit tool fuzzy matching #6144 (cunzai97) — narrow fix, normalizes tabs to 4 spaces in normalizeForFuzzyMatch. Addresses the tab-vs-space case directly.
• fix(coding-agent): preserve untouched content in fuzzy edit matches #5898 (hobostay) — broader fix, builds a grapheme-cluster offset map so a successful fuzzy match translates back to original offsets, preventing the separate data-loss bug where untouched lines get rewritten (edit tool fuzzy match silently rewrites the whole file (data loss on untouched lines) #5899, Edit tool fuzzy matching normalizes entire file content, corrupting characters outside edited region #3554).

The suggested fix in the original report still stands and #6144 is a reasonable minimal first step. Happy to help validate either approach if there's interest in reopening.

[kushalBanda]

Root Cause

normalizeForFuzzyMatch doesn't collapse interior whitespace runs, so "a b" and "a b" produce different normalized strings and fuzzy match fails even though they're semantically identical.

packages/tools/src/lib/edit-diff.ts:19-29:

export function normalizeForFuzzyMatch(text: string): string {
  return text
    .normalize("NFKC")
    .split("\n")
    .map((line) => line.trimEnd())
    .join("\n")
    .replace(/[‘’‚‛]/g, "'")
    .replace(/[“”„‟]/g, '"')
    .replace(/[‐‑‒–—―−]/g, "-")
    .replace(/[  -   　]/g, " ");
}

Only trimEnd() runs per line interior runs of 2+ spaces are left untouched, so whitespace-length differences defeat the match.

Fix

In packages/tools/src/lib/edit-diff.ts:23, replace the .map call to also collapse interior whitespace runs (preserving leading indentation):

.map((line) => {
  const leading = line.match(/^\s*/)?.[0] ?? "";
  const rest = line.slice(leading.length).trimEnd().replace(/ {2,}/g, " ");
  return leading + rest;
})

Safety note

applyEditsToNormalizedContent (packages/tools/src/lib/edit-diff.ts:245) slices replacement text from originalContent, never from the normalized string so no content is corrupted by this change; normalization is only used for matching, not for the actual write.

[weiconghe]

Confirmed on current main (cd6852a). normalizeForFuzzyMatch covers Unicode spaces (NBSP, ideographic space, etc.) but never collapses runs of plain ASCII whitespace — so "a b" and "a b" stay distinct after normalization and fuzzyFindText misses.

Beyond the whitespace-length case in the original report, tab/space mixing also fails: "hello \t world" doesn't match "hello world". I tested both directions (extra spaces in content vs. in oldText) plus multi-line and function-call-argument scenarios — all miss.

The fix is one line after the existing Unicode-space replacement:

.replace(/[^\S\n]+/g, " ")

[^\S\n] matches any whitespace except \n, so it collapses spaces, tabs, and any residual special characters into a single space without touching line structure. I verified that it doesn't break the uniqueness guard — two lines like "x = 1" and "x = 1" both normalize to "x = 1" and correctly trigger the duplicate-occurrence error.

Worth noting: the same function is duplicated in packages/agent/src/harness/tools/edit-diff.ts and packages/coding-agent/src/core/tools/edit-diff.ts — both need the change.