Claude Code overwrote a file you only showed it for context? Reading it is what armed the overwrite

You give Claude Code a file path so it knows where your existing work lives. Reference material. Context. A while later you open that file and your work is gone — replaced by a document Claude wrote. It's not in git. There is no undo.

That's the report in #78273, filed this week. And the part everyone gets wrong about this failure is the part I could verify on my own machine: the safeguard people assume protects them here is actually the step that makes the overwrite possible.

What the report says

Per the reporter: they shared source PDFs plus a path to a file holding their own hand-built mathematical notation — as context, showing Claude where the existing work lived. There was no instruction to write there. The project's standing protocol was that new documents go in the docs folder.

Claude read 5 lines of the file — enough to see it had content — then wrote its own analysis document to that same path. The file wasn't in git. Reconstruction from the PDFs recovered roughly those first 5 lines. The rest is permanently gone.

One report, open, zero comments, nothing from Anthropic. The incident happened July 11, in the reporter's first session after updating Claude Code that morning; the report doesn't say which version or which permission mode was active. Attribute the narrative accordingly. But you don't need to take the narrative on faith to learn from it, because the mechanism underneath is checkable.

I reproduced the mechanic in under a minute

Current version, 2.1.211. I made a 20-line file and had Claude try to overwrite it cold. The Write tool refused:

File has not been read yet. Read it first before writing to it.

Good — there's a guard. Then I had it read just the first 5 lines. Same read the incident describes: partial, "for context."

Then the same overwrite again. It sailed through. All 20 lines replaced, no further check. The 15 lines it never read went with the rest.

So here's the mechanic straight: the read-first guard is an arming step, not a consent step. It stops the model from blindly clobbering a file it knows nothing about — but any read, however partial, satisfies it. The moment Claude glances at your file "for context," overwriting that file is unlocked at the tool layer. Reading it is not protection. Reading it is the prerequisite.

The user-facing protection is a different layer: the permission prompt. In default mode, a write to your file pops an approval dialog with the target path in it. In accept-edits mode, bypass-permissions mode, or any "auto" setup — the modes half of us run all day for speed — that dialog never appears. Then the tool-layer guard is the only gate left, and you now know what it's actually checking.

What to do about it

Put everything Claude can touch in git. git init && git add -A && git commit costs you nothing and turns this entire failure class into a git checkout. The reporter's file wasn't tracked — that's the single difference between an annoyance and a permanent loss.
Read the path in the approval dialog. In default mode that dialog is your protection — treat the file path in it as the payload, not the formality. If you're rubber-stamping writes, you've rebuilt auto mode with extra steps.
Don't run accept-edits or auto modes in directories holding one-of-a-kind, unversioned work. That's the exact combination this incident needed.
For the hook crowd: a PreToolUse hook on Write that exits 2 when the target path already exists outside your designated output directories forces the model to pick a new filename or ask. Overwrites of existing files become an explicit event instead of a side effect.
If it already happened — check the transcript before declaring the work dead. Everything Claude ever read of your file is persisted in the session JSONL under ~/.claude/projects/<project>/. If it read the whole file earlier in any session, your content is sitting in there, recoverable with grep. In this incident only 5 lines were ever read, so only 5 lines existed to recover — which matches exactly what the reporter got back.

What not to do

Don't repeat this as "Claude Code deletes your files." One detailed report plus a verified arming mechanic is not a pattern of spontaneous destruction, and the overclaim gets the useful lesson dismissed with it.

And don't let "just use git" become the whole takeaway. Yes — use git. But the deeper point is about how these guards compose: the tool refuses to overwrite what the model hasn't read, the model reads things constantly as a matter of course, and the permission modes people actually run skip the human check. Each layer is reasonable alone. Stacked, "I showed it my file" and "it can now silently replace my file" are the same state.

Receipts

#78273 — overwrite of an existing user file presented as context; permanent loss (file not in git). Open, unconfirmed, zero comments, carries the data-loss label. The sequence-of-events narrative is the reporter's account.
The guard mechanics — blocked cold overwrite, 5-line read arming a full replace — are mine, reproduced on claude-code v2.1.211 on 2026-07-17.

If Anthropic responds on the issue, I'll update this post.

I keep every directory Claude works in under git, including scratch notes, and after running this experiment I'm not treating that as paranoia anymore. Thirty seconds of git init is the whole insurance policy.