[BUG] str_replace silently drops the adjacent line when inserting a record near a line boundary (confirmed twice, data-integrity risk)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Scope note: this occurs in claude.ai web chat using the file-editing tools (bash_tool/str_replace) — not specific to the Claude Code CLI, though the tool itself may be shared infrastructure. Filing here as the public Anthropic issue tracker; if there is a more appropriate queue, please route rather than close. Two prior related reports from the same account (tool manifest degradation, Claude in Chrome SPA/AJAX) are #77083 and #77085 in this repo.

Observed facts (13 July 2026, claude.ai web, bash_tool/str_replace file-editing tools in a long-running data-extraction thread):

1. The thread was maintaining an incrementally-built text file (a working dataset of extracted email headers, one record per line, each tagged with a numeric offset).
2. To insert a new record at a specific position (record [649] before existing record [650]), the thread used str_replace to insert new text immediately before the target line.
3. After the operation, record [649] — a line that existed BEFORE the insertion and was not the target of the edit — had disappeared from the file. This was caught only because the thread ran a grep -c verification against an expected count immediately after the write.
4. The thread corrected it by re-inserting [649].
5. The exact same pattern recurred shortly after: inserting record [674] before [675] caused [674] itself to vanish. Again caught only by grep -c verification, again corrected by re-insertion.
6. Both losses were silent: no error was raised by the tool, the operation was reported as successful, and the file's line count only revealed the problem because the thread happened to verify it against a known expected value.

This is not a prompt-engineering or methodology problem — it is the file-editing tool itself apparently consuming or overwriting content adjacent to the target of a targeted string replacement, under conditions not fully isolated (possibly related to how the "old_str" match boundary interacts with immediately-preceding content, or to how the replacement is written back). Without active verification discipline, this produces silently corrupted datasets.

We have two confirmed occurrences, both in the same thread, both involving insertion near a line the tool was not directly targeting. We have not attempted a minimal isolated reproduction outside our actual workflow, and don't know the precise mechanical trigger.

Update: Anthropic support (conversation 215475075078337) confirmed this specific failure mode is not documented as a known issue, recommended the "insert" command (positional insertion by line number) as the safer alternative to str_replace for this use case, and has escalated this report to a human engineering agent for review.

What Should Happen?

str_replace should never alter or remove content outside the exact span matched by old_str. Inserting text adjacent to a line (immediately before or after it) should never cause that neighboring, untouched line to disappear.

Requested: (1) confirm whether this is a known failure mode and under what conditions it occurs; (2) if not previously known, register as a data-integrity bug — we can provide the exact thread ID and before/after file states captured via grep; (3) any recommended safer pattern for inserting content at a specific position in a large incrementally-built text file, other than avoiding str_replace for insertions entirely (our current mitigation: append-only construction, str_replace reserved strictly for correcting an already-identified error, never for routine insertion).

Error Messages/Logs

Actual Behavior: No error, exception, or warning of any kind was surfaced by the tool in either occurrence. The str_replace call returned as a normal successful edit. The only way the loss was detected was an independent grep -c line-count check run immediately after, against a known expected total (50 expected, 49 found after the first occurrence; corrected, then a second, separate occurrence a few batches later with the same pattern).

Environment: claude.ai web (chat), paid plan, long-running data-extraction thread using bash_tool and str_replace to build an incremental working file. Date: 13 July 2026.

Steps to Reproduce

1. Create/maintain a large plain-text file with sequential numbered records, one per line.
2. Use str_replace to insert a new record immediately before an existing line (i.e., old_str = the existing line, new_str = new line + existing line).
3. Verify the file's line count / content immediately after with an independent method (e.g., grep -c) against the expected count.
4. Observe: the previously-existing line adjacent to the insertion point may be missing, with no error reported by the tool.

(We do not have a minimal standalone repro outside our actual multi-hundred-line dataset; happy to share the exact before/after file snippets from the two confirmed occurrences on request.)

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — this bug occurs in claude.ai web chat file-editing tools, not the Claude Code CLI; no CLI version is involved.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_