What happens

When the LLM reads a file with read_file and later writes modified content back with write_file, the LINE_NUM|CONTENT format from read_file can end up persisted in the actual file. This silently corrupts configuration files, source code, and especially .env — embedding line-number prefixes like 1| into real file content.

Steps to reproduce

1. Have the agent read any text file: read_file("config.yaml")
2. The agent receives:

        1|setting: value
        2|other: thing

3. Agent modifies the content and calls: write_file("config.yaml", " 1|setting: new_value\n 2|other: thing")
4. File on disk now literally starts with 1|setting: new_value — the 1| prefix is permanent.

This is not hypothetical. It happens in practice when models echo read_file output into write_file content, especially with weaker models or complex multi-step transformations where the model loses track of the display format vs. actual content distinction.

Root cause

read_file always line-numbers its output (tools/file_operations.py:594-595):

return ReadResult(
    content=self._add_line_numbers(read_output, offset),  # ← always line-numbered
    ...
)

Where _add_line_numbers() (line 440-451) prepends {i:6d}| to every line.

write_file writes content as-is with zero sanitization (tools/file_operations.py:749):

write_cmd = f"cat > {self._escape_shell_arg(path)}"
write_result = self._exec(write_cmd, stdin_data=content)  # ← no stripping

The existing guard only catches one specific case (tools/file_tools.py:798-802):

if _is_internal_file_status_text(content):
    return tool_error(
        "Refusing to write internal read_file status text as file content. ..."
    )

_is_internal_file_status_text() (line 274-302) ONLY checks for _READ_DEDUP_STATUS_MESSAGE — it is completely unaware of line-number pollution. Content like " 1|REAL_CONFIG=value" passes through undetected.

read_file_raw exists but is NOT exposed to the LLM (tools/file_operations.py:654). It reads without line numbers using cat, but there is no read_file_raw_tool wrapper, no READ_FILE_RAW_SCHEMA, and no registration in the tool registry. It is only used internally by patch_parser.py.

Evidence — exact code locations (commit a11aed1ac)

Suggested fix

A non-aggressive approach (mirroring the existing _is_internal_file_status_text pattern): add a detection function that recognizes when content appears to be line-number-polluted, and reject the write with a clear error message telling the model to strip the prefixes.

def _is_line_number_polluted(content: str) -> bool:
    """Detect content that looks like it was copy-pasted from read_file output."""
    if not isinstance(content, str) or not content.strip():
        return False
    lines = content.split('\n')
    if len(lines) < 2:
        return False
    # Check if a significant portion of non-empty lines start with NUMBER|
    import re
    pattern = re.compile(r'^\s*\d+\|')
    non_empty = [l for l in lines if l.strip()]
    if len(non_empty) < 3:
        return False
    polluted = sum(1 for l in non_empty if pattern.match(l))
    return polluted / len(non_empty) > 0.8

Then call it alongside _is_internal_file_status_text in write_file_tool with a similar rejection message.

The alternative — unconditionally stripping ^\s*\d+\| prefixes in write_file — is too aggressive since legitimate files could start with that pattern.

Impact

• Data corruption: .env, config.yaml, and other config files get silently polluted
• Hard to notice: The pollution is prefix-only; the rest of the file looks normal at a glance
• Cascading: Once a file is polluted, subsequent read_file calls show double pollution ( 1| 1|real content)
• Security: If .env gets polluted, API keys may fail to parse, leading to confusing auth failures