Claude Code Edit Tools Now Refuse to Overwrite Non-UTF-8 Files
Claude CodeClaude Code 2.1.296 changes how the Edit and NotebookEdit tools treat files that are not valid UTF-8, such as Windows-1252, Shift-JIS and GBK files. Previously an edit could replace every non-ASCII character in such a file, silently damaging text far from the lines being changed. Edits to these files are now refused instead.
Key Takeaways
- Edit and NotebookEdit now refuse changes to files that are not valid UTF-8, instead of rewriting them.
- The old behavior could replace every non-ASCII character in the file, not just the text near the edit.
- Affected encodings named in the release include Windows-1252, Shift-JIS and GBK.
- The fix turns a silent corruption into a visible refusal, which makes the problem easy to notice and recover from.
- The release does not add native editing of legacy encodings, so affected files still need converting or a manual change.
- The issue had been reported many times in the Claude Code issue tracker, across accented European text, Japanese and Chinese files.
Sources & Mentions
4 external resources covering this update
[BUG] Claude Code does not respect file encoding, corrupts Windows-1252 files (anthropics/claude-code issue 7134)
GitHub
[BUG] Edit/Write tool corrupts accented characters in Windows-1252 (cp1252)
ClaudeIssues
[BUG] Built-in Edit tool corrupts SJIS-encoded files by inserting content in UTF-8
ClaudeIssues
[BUG] Edit tool corrupts GBK-encoded Chinese comments in source files
ClaudeIssues
The problem with legacy encodings
Many long-lived codebases still contain source files saved in older character encodings such as Windows-1252, Shift-JIS or GBK. Claude Code's file tools assume UTF-8, and when an edit touched one of these files, the tool could replace every non-ASCII character in it. Accented letters, Japanese text and Chinese comments could be damaged across the whole file, not only on the lines the edit targeted. Users reported this pattern repeatedly in the project's issue tracker, including cases where the tool reported success and the corruption was only discovered later when another program opened the file.
What changed in 2.1.296
Claude Code 2.1.296 fixes this for the Edit and NotebookEdit tools. When a file is not valid UTF-8, the edit is now refused rather than applied. The tool no longer rewrites the file and no longer corrupts characters that it cannot interpret.
What it means in practice
The change is protective. Instead of a silent loss of text, a developer working in a legacy-encoded repository now gets a refusal, and can convert the file to UTF-8 first or make that specific change another way. Teams that keep legacy-encoded files in version control gain a safeguard against an easily missed, hard-to-reverse kind of damage, though the release notes describe the fix as refusing such edits rather than adding native support for editing them in their original encoding.