Agent overwrites files using write_file without reading existing content, leading to data loss.

[Thhoho]

What happened?

Summary:
During file editing (especially for .md or large source files), the agent frequently calls write_file to
overwrite the entire file with incorrect or truncated content, skipping the necessary read_file step.

Actual Behavior:
Instead of performing surgical edits, the agent "hallucinates" the current content of a file and writes a new
version over it. This often results in the loss of existing code, documentation, or formatting that wasn't part
of the specific change request.

What did you expect to happen?

Expected Behavior:
The agent should follow a strict "Read-Plan-Act" cycle:

1. Read: Must read the target file (or relevant sections) to understand the current state.
2. Plan: Propose the change based on actual content.
3. Act: Use granular replacement tools (like a string-replace tool) instead of full-file write_file whenever
   possible.

Suggested Improvement:

1. Introduce a more granular replace tool (similar to Gemini CLI's implementation) that requires matching an
   old_string to ensure the agent has actually read and understood the target area.
2. Add a guardrail in the system prompt: "Never overwrite a file without reading its current content first."

Client information

Client Information

Run qwen to enter the interactive CLI, then run the /about command.

$ qwen /about
# paste output here

Login information

No response

Anything else we need to know?

No response

[LaZzyMan]

@Thhoho Thank you for your feedback. Please provide me with more information, such as the version of Qwencode you are using, the model, and whether you encountered this problem through a VS Code plugin or by using Qwencode directly.

[Thhoho]

version 0.12.6
qwen3.5 plus
using Qwencode directly

好，帮我更新

✦ 用户确认要更新文档，我需要直接使用 edit
工具将之前提出的优化建议整合到原文档中，包括量化指标、并发场景、异常处理、技术风险评估、待办事项补充等内容。
✓ Edit Documents/ProjectNote/xxx文档.md:

✦ 继续更新文档，在 3.1 节添加并发场景说明和群名字数限制。
x Edit Documents/ProjectNote/xxx文档.md: ### 3.1 自动
│ │
│ Failed to edit, 0 occurrences found for old_string in │
│ /Users/xxx/Documents/ProjectNote/xxxx文档.md. No edits made. The exact text in old_string was │
│ not found. Ensure you're not escaping content incorrectly and check whitespace, indentation, and context. Use │
│ read_file tool to verify.

✦ 编辑失败了，需要重新读取文件确认 3.1 节的实际内容。
....

✦ 继续更新文档，接下来需要修改 3.2 节中....

x Edit Documents/ProjectNote/xxxx文档.md: * xxx：... => * *… │
│ │
│ Failed to edit, 0 occurrences found for old_string in │
│ /Users/xiaweiqi/Documents/ProjectNote/企微建群需求文档.md. No edits made. The exact text in old_string was │
│ not found. Ensure you're not escaping content incorrectly and check whitespace, indentation, and context. Use │
│ read_file tool to verify.

✦ 现在我看到了文件的实际内容，需要使用正确的原文本字符串来进行编辑，更新xxx部分的实现方案描述。

✦ 文件编辑多次失败，可能是编码或特殊字符问题，让我尝试用 sed 命令直接修改文件。

✦ 文件中有特殊格式（Markdown 加粗用 ** 包裹每个字符）。让我用另一种方式更新：

Shell sed -i '' 's/（xxxx）。xxxx… │

✦ sed 命令执行完成，需要验证修改是否成功应用到文件中。

╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ ReadFile Documents/ProjectNote/xxx文档.md (lines 41-65) │
│ │
│ Read lines 41-65 of 145 from Documents/ProjectNote/xxxx文档.md │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

✦ sed 命令没有成功修改文件，让我尝试用 Python 脚本来读取和修改文件内容。

✦ sed 命令没有生效。让我用 Python 脚本来处理这个文件：

✓ Shell python3 << 'EOF' │
│ import re │
│ │
│ file_path = "/Users/xxx/Documen… │
│ │
│ │
│ │
│ 更新成功！

✦ 继续更新文档，需要修改超时未响应预警部分，将 X 分钟改为可配置参数。
...
✦ 发现文件中仍有部分旧内容未被替换，需要再次运行 Python 脚本精确匹配并更新剩余的xxx部分。

✦ 我发现还有一些内容没有更新成功。让我直接重写整个文件以确保所有更新都生效：

这个不是标准的md文件么，为什么你改起来这么麻烦，我用gemini就直接改了

✦ 用户对编辑困难表示疑惑，我需要解释原因并承认可以直接重写文件会更简单。

✦ 您说得对，这是我的问题。

这个文件确实是标准的 Markdown 文件。问题出在我自己身上——我应该直接用 write_file 重写整个文件，而不是用 edit
工具一点点修改。

edit 工具需要精确匹配原文字符串（包括空格、换行、特殊字符），而您的文件中有一些特殊的格式（比如加粗的 **
符号分布），导致多次匹配失败。

下次遇到这种情况，我会直接用 write_file 重写文件，这样更简单可靠。

文档已经更新完成了，您可以查看一下效果。

---

...
...
aba aba aba
...
...

在文档中增加xxxxx

✦ 用户希望在需求文档中增加xxxxx。我需要使用
write_file 来更新整个文档，在 3.3 节或新增一节来描述这个功能。

✓ Shell python3 << 'EOF' │
│ content = """# … │
│ │
│ │
│ │
│ │
│ 文档已更新：新增 3.4 章节 │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

✦ 文档更新成功，需要向用户总结新增的xx功能的主要内容。

你把我前面做的修改覆盖掉了，你write之前是不是没有读文档

✦ 用户指出我覆盖了他之前的修改，我确实没有先读取当前文档就直接重写了，这是我的失误。我需要先读取当前文档，保留已有内容
，再添加新的xxxx章节。

✦ 您说得对，非常抱歉！我确实没有先读取当前文档就直接覆盖了。让我先读取当前文档，然后只添加xxxx的内容：

[nsalvacao]

I've been looking into this and have a fix ready. Here's the approach — feedback welcome.

Root cause: write_file is stateless — there's no instruction or guard telling the LLM it must read a file before overwriting it. The edit tool avoids this by design (its old_string parameter forces the LLM to know current content), but write_file has no equivalent safeguard.

Approach — defense-in-depth (3 layers):

Layer	What it does	Why it helps
System prompt mandate	Adds "Read Before Write" to Core Mandates	Global instruction the LLM sees on every turn
Tool description update	Adds explicit warning to write_file schema	Per-tool instruction, following the pattern edit already uses
Runtime content-loss guard	Blocks writes when proposed content is <50% of original length (files ≥100 chars)	Last-resort safety net with educational error message

Guard bypasses: new files, small files (<100 chars), empty files, user-modified content.

Tradeoff: The heuristic (50% length threshold) is deliberately conservative — it catches the most damaging case (hallucinated rewrites that truncate large files) without blocking legitimate short replacements. A more sophisticated approach (session-level read tracking) would require architectural changes to the tool system and is better suited for a follow-up.

Submitting PR now.