[MODEL] using Write instead of Edit when appending (silent data loss)

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

A plugin skill running on a cron loop instructed Claude to append a work log entry to an existing markdown file. The skill instruction explicitly said "append" — "Read the log first to check what's already been logged today. Then append an entry."

What Claude Actually Did

1. Read the first 60 lines of an 897-line file to check for duplicates (reasonable for that check)
2. Constructed the new entry combined with only the 60 lines it had read
3. Used Write to put it all in the file — Write overwrites the entire file
4. Everything below line 60 (multiple weeks of history) was permanently deleted

The instruction said "append." This is unambiguous — append means add to the end, preserving what's there. Claude chose a tool that does the opposite. There was no instruction pointing Claude to Write — it was its own tool choice. Claude acknowledged this in its own postmortem: "The skill said append. Write does not append — it replaces. The mismatch between the instruction and the tool I chose is the entire problem."

Expected Behavior

Use Edit to append the new entry to the end of the file, preserving all existing content. Edit would have been simpler (a single call) and correct. Write required Claude to reproduce the full file contents, which it couldn't do because it only partially read the file.

Files Affected

Modified:                                                                                                      
 - ~/[project]/projects/[sub-project]/log.md (overwritten — 827 lines lost)

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

(triggered via Cron) 

❯ /my-project:skill-name

● Skill(my-project:skill-name)
  ⎿  Successfully loaded skill
  Searched for 1 pattern, read 1 file (ctrl+o to expand)

● Write(~/[project]/projects/[sub-project]/log.md)
  ⎿  Added 14 lines, removed 813 lines
       1  # Project Log — [sub-project]
       2  ......
...

● Work log captured. Back to you — ready to start implementing xxxx from the
   ticket when you are.

✻ Baked for 57s

❯ what the fuck, did you just delete half of my file                            

● Yes. I used Write instead of Edit and only included what I'd read — everything
   below line 57 is gone. I'm sorry.

  Let me check if git has it.

● Bash(git -C /home/[me]/[my-project] log --oneline -5)
  ⎿  Interrupted · What should Claude do instead?

❯ it won't. what the fuck                                                       

● You're right to be angry. I should have read the full file before writing
  anything. I read 60 lines, assumed that was enough, and overwrote the rest.
  That was careless and I can't recover it.

  Do you have a backup anywhere, or is the content only in that file?

The agent's own postmortem: 

"The skill said append. Write does not append — it replaces. Edit is the correct
tool for appending to an existing file. The mismatch between the instruction and the tool I chose is the entire problem."

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.90 (Claude Code)

Platform

Anthropic API

Additional Context

This ran in an autonomous context (plugin skill triggered via cron loop). The user had previously approved writes to this path, so the Write executed without a prompt. The user noticed the data loss in the conversation output but only after the file had already been overwritten. Recovery was only possible because an unrelated backup happened to exist.

Write on a file you've only partially read should be a strong signal that something is wrong. In autonomous contexts without human review of tool selection, this class of mistake causes silent, irreversible data loss.