Claude · whole-file rewrites
Claude rewrote my whole file. Was the request bad?
Determine whether Claude was invited to refactor, lost necessary context, or violated an explicit one-function edit boundary.
Short answer
What is probably happening
A whole-file rewrite is not automatically wrong. It is wrong when the task was local and the request clearly protected the rest of the file. If you asked Claude to “clean up,” “rewrite,” or “improve” the file, broad changes may follow from the instruction. If you named one function, prohibited refactoring, and required all other content to remain, the rewrite is on the model.
Possible causes
The same symptom can have different verdicts
The correct unit of analysis is the diff. A polished replacement can still be a failed edit if it silently removes exports, comments, tests, or edge-case behavior outside the requested scope.
The task sounded like a refactor
Broad verbs and a full-file output request may communicate that global cleanup is welcome.
The source was too large or incomplete
If Claude received only part of the file, it could not preserve code it never saw; if the relevant dependencies were absent, it may have simplified incorrectly.
A preservation condition was ignored
The request explicitly kept exports, comments, and unrelated functions, yet the response removed them.
The editing workflow favored replacement
A chat response that outputs one large code block makes accidental omission harder to detect than a patch-based repository edit.
How to distinguish them
Check the evidence in this order
- 01
Compare the old and new files with a real diff, not visual scanning.
- 02
Inventory lost exports, comments, types, tests, and behavior separately from intended edits.
- 03
Check whether the final instruction explicitly prohibited refactoring and deletion.
- 04
Confirm that Claude had the complete file and any dependencies required to preserve behavior.
WWW-style diagnosis
Example caseoops, that’s on us.
- Wanted
- Add retry handling to one function.
- Asked
- Modify only requestWithRetry(); keep every other export and comment; do not refactor.
- Result
- Correct retry logic inside a shorter replacement file with exports omitted.
- Why
- The feature implementation succeeded, but the edit failed as a whole because it broke explicit preservation constraints.
What to do next
Fix the diagnosed cause
Ask for a unified diff
Patch output makes the edit boundary visible and prevents a plausible-looking file from hiding omissions.
Freeze public behavior
State the APIs, exports, tests, and edge cases that must continue to work after the change.
Escalate only after a clean retry
Retry once with the explicit patch boundary. If Claude repeats the violation, switch to a repository-aware workflow rather than endlessly expanding the instruction.
When the instruction needs repair
A boundary-first template
Edit only [function/block] in [file]. Implement [behavior]. Preserve every other line, import, export, comment, type, test, and public behavior. Do not refactor, rename, reorder, or remove unrelated code. Return a unified diff. If the requested change cannot be isolated, stop and explain the required additional scope first.
This template is relevant only when the evidence points to missing or conflicting boundaries. It cannot excuse a model that violated a clear instruction.
Questions
What people usually ask next
Why does Claude sometimes return a shorter file?+
Chat interfaces often optimize for a concise, coherent answer. Without a patch boundary, that can look like permission to omit unchanged or seemingly redundant content.
Should I paste the whole file again?+
Only after restoring the original. Then ask for a scoped diff and provide the complete context needed for the target function.
Can a correct new function still count as a failed result?+
Yes. If unrelated protected behavior was lost, the artifact failed even though the requested feature appears to work.