Problem (one or two sentences)
Models that use read_file output as input to search_replace or edit_file fail with exact-match errors because the line-number prefixes (137 | content) produced by read_file are copied verbatim into old_string. The tool descriptions for these two tools have no warning about this, unlike the recently patched apply_diff (PR #641).
Context (who is affected and when)
Affects any model/provider that copies read_file output directly into search_replace or edit_file — observed with Gemini but likely reproducible with others. Occurs whenever a model reads a file and then attempts an edit using content from that output.
Reproduction steps
- Use Zoo Code with any model that references
read_file output when constructing edit calls.
- Model calls
read_file on a file — output is prefixed with 137 | someCode() etc.
- Model calls
search_replace or edit_file with old_string copied verbatim from that output (including the 137 | prefix).
- Tool fails with an exact-match /
Edit Unsuccessful error because the raw file contains no such prefixes.
- Repeated failures eventually hit
consecutiveMistakeLimit.
Expected result
Tool descriptions warn models that read_file line-number prefixes (e.g. 137 | ) are decorative and must not be included in old_string.
Actual result
search_replace.ts and edit_file.ts parameter descriptions say old_string must match file contents exactly, but give no guidance about stripping read_file prefixes. edit.ts (the native Edit tool) already has this warning at line 7 — making the omission inconsistent across sibling tools.
Variations tried
The root-cause fix would be a single upstream warning in the read_file description itself (read_file.ts:65), protecting all downstream tools without requiring each to repeat it. The actual format from addLineNumbers() in extract-text.ts:155 is ${lineNumber} | ${line} (space-padded integer + | + content).
Suggested per-tool additions:
read_file.ts: "NOTE: Line-number prefixes (e.g. 137 | ) are for reference only and do NOT exist in the raw file. Do NOT copy them into old_string, SEARCH blocks, or other edit inputs."
search_replace.ts old_string: "Do NOT include line-number prefixes (e.g. 137 | ) from read_file output — the file itself does not contain them."
edit_file.ts old_string: same note as above.
App Version
Observed against current main (post PR #641).
API Provider
Google Gemini (originally reported), but affects any model that copies read_file output verbatim.
Model Used
Gemini (and likely others).
Related
Problem (one or two sentences)
Models that use
read_fileoutput as input tosearch_replaceoredit_filefail with exact-match errors because the line-number prefixes (137 | content) produced byread_fileare copied verbatim intoold_string. The tool descriptions for these two tools have no warning about this, unlike the recently patchedapply_diff(PR #641).Context (who is affected and when)
Affects any model/provider that copies
read_fileoutput directly intosearch_replaceoredit_file— observed with Gemini but likely reproducible with others. Occurs whenever a model reads a file and then attempts an edit using content from that output.Reproduction steps
read_fileoutput when constructing edit calls.read_fileon a file — output is prefixed with137 | someCode()etc.search_replaceoredit_filewithold_stringcopied verbatim from that output (including the137 |prefix).Edit Unsuccessfulerror because the raw file contains no such prefixes.consecutiveMistakeLimit.Expected result
Tool descriptions warn models that
read_fileline-number prefixes (e.g.137 |) are decorative and must not be included inold_string.Actual result
search_replace.tsandedit_file.tsparameter descriptions sayold_stringmust match file contents exactly, but give no guidance about strippingread_fileprefixes.edit.ts(the native Edit tool) already has this warning at line 7 — making the omission inconsistent across sibling tools.Variations tried
The root-cause fix would be a single upstream warning in the
read_filedescription itself (read_file.ts:65), protecting all downstream tools without requiring each to repeat it. The actual format fromaddLineNumbers()inextract-text.ts:155is${lineNumber} | ${line}(space-padded integer +|+ content).Suggested per-tool additions:
read_file.ts: "NOTE: Line-number prefixes (e.g.137 |) are for reference only and do NOT exist in the raw file. Do NOT copy them intoold_string, SEARCH blocks, or other edit inputs."search_replace.tsold_string: "Do NOT include line-number prefixes (e.g.137 |) fromread_fileoutput — the file itself does not contain them."edit_file.tsold_string: same note as above.App Version
Observed against current
main(post PR #641).API Provider
Google Gemini (originally reported), but affects any model that copies
read_fileoutput verbatim.Model Used
Gemini (and likely others).
Related
apply_diffbut not the sibling tools; also contains a format inaccuracy in its examples ('137: 'instead of the correct'137 | ') — separate inline comment posted on that PR.