edit: oldString with leading indentation fails to match ("Could not find oldString") #53036

Description

The edit tool reports Could not find oldString ... It must match exactly, including whitespace and indentation for oldString values that match the file exactly, whenever they contain leading indentation (multi-space runs) or backslash sequences. Only single-line oldString values with zero or one leading space match. This blocked all real edits to one working file.

Environment

• opencode version: v2.0.22
• OS: Linux Sicily 7.2.8-2-cachyos x86_64 GNU/Linux
• Terminal: TERM=xterm-256color, TERM_PROGRAM unset, COLORTERM unset
• Shell: /bin/fish
• Install/channel: latest
• Active plugins: no plugin entries in ~/.config/opencode/opencode.json; MCP server photon (local) configured; runtime snapshot also listed opencode.browser, openchamber-agent-tool

Reproduction

1. Create a JSON file with 4-space indented lines, e.g. a line "cmd": 847,.
2. Call edit with oldString = "cmd": 847, (exact, 4-space indent) and a differing newString (e.g. trailing space).
3. Observe the error Could not find oldString in <file>. It must match exactly, including whitespace and indentation.
4. Retry with oldString = "cmd": 847, (no indent) and the same change → the edit succeeds (Edited <file> (1 replacement)).
5. Retry with oldString = "cmd": 847, (one leading space) → also succeeds.

Expected Behavior

An oldString that byte-matches the file content, including its exact leading whitespace, should match regardless of indentation width.

Actual Behavior

• Any oldString containing a multi-space leading run (tested: 2, 3, 4 spaces; tab) is reported as not found, while 0/1-space variants of the same content match as substrings.
• Multiline oldString values spanning indented lines fail the same way, making it impossible to target JSON values (e.g. "es": "") that need surrounding lines for uniqueness.
• oldString values containing backslash sequences (e.g. "en": "\\E\\f[27]Misa Kaji",) also fail; backslash-free fragments of the same lines succeed, so this may share the root cause.
• Sanity check: identical oldString/newString returns No changes to apply: oldString and newString are identical, which suggests the mismatch happens in the real search path, not in parameter transport of the content itself.

Additional Context

• Frequency: consistent throughout the session for one ~90 KB JSON batch file (ESP/work/common/evt_466.json, 2190 lines, LF endings, space indentation confirmed via grep ^[ ] matching level-1 keys).
• Edits to another file (ESP/glossary.md, lines containing only single spaces) worked fine in the same session, pointing at whitespace-run handling rather than a general tool outage.
• Possibly related: grep patterns with {n} quantifiers (e.g. ^[ ]{4}"cmd") returned no matches while equivalent single-character patterns (^[ ]) matched; tab pattern ^\t also matched nothing.
• Workaround used: single-line, unindented substring edits only. No workaround exists for edits that require indented multiline context.
• Impact: blocked a 312-item file batch (logged as blocked in project notes); no data was corrupted (all probe edits reverted and verified).