OpenClaw Fixes a Fuzzy Edit Bug That Could Rewrite Untouched Unicode

OpenClaw has merged a fix for an edit-tool data-integrity bug: when oldText required fuzzy matching, the write path could silently alter Unicode bytes outside the requested replacement span on the same line.

A harmless mismatch such as a normal space versus a non-breaking space could send matching through NFKC-normalized text. The old path then rebuilt the overlapping line from that normalized copy, potentially changing fullwidth punctuation, halfwidth katakana, smart punctuation, dashes or other untouched content.

The correction is on main. Operators should not claim remediation until they have matched their installation to a containing release or exact source revision.

The contract that failed

An edit operation has a narrower promise than “produce equivalent-looking text.” It should replace the selected span and preserve everything else byte for byte unless the caller explicitly asks for broader normalization.

Unicode normalization deliberately maps some distinct source sequences to equivalent forms. That is useful for locating text despite formatting variation. It is not safe as the source from which to reconstruct unrelated content.

In the affected path, fuzzy matching answered the right discovery question—“where is the intended text?”—but the write stage used the normalized representation as though it were the original file. The result could be a successful edit accompanied by collateral changes the model never requested and a reviewer might not notice visually.

Interpretation: tolerant matching and exact mutation need separate authorities. Normalized text may help identify a candidate span; only stable boundaries mapped back to the original source should control the write.

What the merged fix does

PR #116509 maps fuzzy matches back onto stable boundaries in the original source and applies the replacement there. Upstream reports grapheme verification, complete span mapping and rejection of ambiguous partial normalization expansions.

The associated test record covers preservation of Unicode outside the target, line-ending behaviour and host/sandbox write-readback paths. The important outcome is simple: the matcher may remain forgiving while the writer preserves original bytes outside the proven replacement span.

This is distinct from the earlier apply_patch collision bug reported by OpenClaw Academy. That defect allowed an “Add File” or move destination to overwrite an existing path. This one concerns an in-place edit that targets the right line but mutates more of that line than requested.

Exposure triage

Review is most valuable where agents edited files containing:

• mixed-width Japanese text;
• non-breaking spaces or compatibility characters;
• smart quotes, em dashes or fullwidth punctuation;
• generated identifiers where visually similar bytes are not interchangeable;
• localisation resources;
• signed, hashed or byte-sensitive text; or
• CRLF files passing through fuzzy rather than exact matching.

The upstream evidence establishes a mechanism, not a count of damaged files. Do not scan every repository and present every normalization difference as OpenClaw corruption. Look first for edits made by affected builds, then correlate unexpected same-line changes with the relevant tool call and diff.

Incident review without making damage worse

For a potentially affected worktree:

1. stop further autonomous edits;
2. preserve the repository, transcript and tool-call record before running formatters;
3. compare the edit request with the complete resulting diff, not only the requested token;
4. inspect same-line changes at a byte-aware or code-point-aware level;
5. recover from version control, snapshots or an authoritative upstream file;
6. review later commits that may have copied the altered text; and
7. label any manual reconstruction instead of presenting it as original evidence.

Do not run bulk Unicode normalization as a repair. That repeats the class of mistake: it may make text look consistent while destroying distinctions the file intentionally retained.

Safe acceptance test

Use a disposable fixture containing synthetic mixed Unicode around a harmless target.

• Make oldText differ only by a supported fuzzy variation such as plain space versus NBSP.
• Place unrelated compatibility-sensitive characters before and after the target on the same line.
• Record the fixture bytes before the edit.
• Run one edit on a build proven to contain PR #116509.
• Confirm the target changed and every byte outside the mapped span remained identical.
• Repeat through both host and sandbox edit paths you permit.
• Confirm an ambiguous partial normalization match is rejected rather than guessed.

A rendered editor view is not sufficient evidence. Visually similar characters can have different byte sequences and different operational meaning.

Evidence and limits

The merged PR, closing issue and merge commit consistently describe the normalized-line reconstruction fault and the original-source span correction. GitHub search also surfaced the stable-boundary mapper and tests for Unicode, CRLF and partial normalization expansions. Direct page extraction was unavailable in this run.

OpenClaw Academy did not reproduce the bug against a live agent and has not identified a packaged release containing the fix. We therefore attribute implementation and test claims to upstream and recommend revision-specific verification.

Bottom line

Fuzzy matching should make an edit easier to locate, not broaden what the agent is allowed to change. OpenClaw now maps the match back to the original source and preserves bytes outside the proven span.

Teams that allow autonomous edits should adopt a containing build through normal change control, inspect historical fuzzy edits in byte-sensitive files, and keep version control or snapshots as the recovery boundary. Prompt instructions are not a substitute for a writer that honours its mutation contract.