A developer's agent is editing a configuration file that has multiple identical lines (e.g., three different sections each containing enabled: true). The agent calls Edit to change the second occurrence and gets an error: the anchor text isn't unique. The agent tries adding context to the anchor, fails again, then gives up and reports it can't edit the file.
What's the documented fallback?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
Read + Write is the documented fallback for non-unique anchor cases. Edit requires unique text to know which occurrence to modify; when uniqueness can't be established, load the whole file, modify the right occurrence in memory, and write it back. This is reliable, safe, and exactly what the tooling is designed to support.
There's no backup_first parameter that allows non-unique matches. Fabricating a plausible-sounding parameter is a common pattern when the agent (or developer) doesn't know about the documented fallback path.
sed has its own escaping and quoting issues that can corrupt files in surprising ways, especially with regex metacharacters in the content. Read + Write is structurally safer for arbitrary text.
This is the genuinely tempting answer because line-number indexing is how every text editor on earth works — but it's a trap in agentic editing. Line numbers shift the moment any earlier line is added, deleted, or moved. The agent's Read showed line 47 a few turns ago; by the time Edit runs, an upstream insertion has made line 47 something else. Text-anchored editing is robust to those shifts; line-anchored editing isn't. Read+Write fallback is the documented path because text anchors keep working when line numbers don't.