Problem

tools.edit frequently fails with messages like:

edit failed: Could not find the exact text in . The old text must match exactly including all whitespace and newlines.

This happens across many repos/files (JS/CSS/MD), especially when:

• The target file is large and changes frequently.
• The replacement involves template strings/backticks (JS) or compact CSS formatting.
• Another agent/process has already made small formatting changes (whitespace/newlines), making the "oldText" no longer an exact match.

In practice this makes edit unreliable for real-world iterative work, even when the intended change is correct.

Steps to Reproduce

1. Use tools.edit to replace a multi-line snippet in a JS or CSS file.
2. Make any small formatting change to the file (indentation, whitespace, line wrapping, quotes), or have another agent update the file.
3. Retry the same tools.edit with the previous oldText.
4. Observe that edit fails because exact text is not found.

Expected

tools.edit should support safer, more robust editing modes beyond exact-match replacement, e.g.:

• Regex / pattern-based replacement
• Anchor-based replacement (match around a stable marker, then replace a range)
• Fuzzy matching with a similarity threshold (diff-match-patch style)
• A tools.patch capability that applies unified diffs (git-apply like), with clear conflict reporting

Actual

Only exact-match replacement is supported. Minor formatting changes cause hard failure.

Why this matters

This is a systemic reliability issue: agents often work on the same files iteratively, and exact-match text replacement is brittle. It leads to repeated failures and forces manual workarounds.

Suggested approach

• Keep current exact-match behavior as default (safe), but add explicit opt-in modes:
  • mode: "regex" | "anchor" | "fuzzy" | "patch"
• For patch mode, allow passing a unified diff and return a structured result:
  • applied hunks / rejected hunks / context mismatch details
• For fuzzy mode, require an explicit threshold and a max replacement span to reduce risk.

Environment

• OpenClaw: 2026.3.8
• macOS: 26.4 (arm64)
• Repro seen with JS/CSS in active projects (e.g., dispatch-board.js, base.css), but occurs broadly.