[BUG] Built-in Edit tool corrupts SJIS-encoded files by inserting content in UTF-8

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: Built-in Edit tool corrupts SJIS-encoded files by inserting content in UTF-8

Summary:
When the built-in Edit tool modifies a SJIS-encoded file, it writes newly inserted content in UTF-8 while leaving the original bytes unchanged. This creates a file with mixed encodings that cannot be correctly read by any single encoding.

What happened:

1. A SJIS-encoded configuration file was used as a test target.
2. Claude Code used the built-in Edit tool to insert a line containing Japanese text into the file.
3. After the edit, reading the file as SJIS showed that the inserted Japanese text was garbled, while the original Japanese content remained intact.
4. Reading the file as UTF-8 showed the opposite: the inserted text was correct, but the original Japanese content was garbled.
5. This confirmed that the Edit tool left the original SJIS bytes untouched but wrote the inserted content in UTF-8, producing a mixed-encoding file.

Expected behavior:
The Edit tool should either detect the file's encoding and write new content in the same encoding, or refuse to insert non-ASCII content into a file it cannot correctly encode, and report an error.

Actual behavior:
The Edit tool wrote inserted Japanese text in UTF-8 regardless of the file's actual encoding (SJIS), resulting in a file that is broken for any application that reads it with a single consistent encoding.

Note:
If only ASCII characters are inserted, the file remains valid SJIS, since ASCII byte values are identical in both encodings. The corruption occurs specifically when non-ASCII characters (e.g., Japanese) are inserted into a non-UTF-8 file.

Impact:
Any SJIS-encoded file edited with the Edit tool that includes non-ASCII inserted content becomes silently and invisibly corrupted. The corruption is not apparent from Claude Code's output -- the tool reports success -- and may only be discovered later when the file is opened by an application that reads it as SJIS.

Distinction from related issues:
Unlike most existing reports where the entire file is rewritten in UTF-8, the behavior observed here is different: the original SJIS bytes are preserved intact, but the newly inserted content is written in UTF-8. The result is a single file containing two different encodings, which is arguably more dangerous because the corruption is harder to detect -- partial content still reads correctly depending on which encoding is used.

Related issues:

• #6485 -- File Encoding Limitation: Edit Tool Overwrites Non-UTF-8 Files
• #7134 -- [BUG] Claude Code does not respect file encoding, corrupts Windows-1252 files
• #5518 -- [BUG] Edit tool corrupts Windows-1252 encoding to UTF-8
• #34695 -- [BUG] The Edit tool changes file charset when editing .properties files

What Should Happen?

Expected behavior:
The Edit tool should either detect the file's encoding and write new content in the same encoding, or refuse to insert non-ASCII content into a file it cannot correctly encode, and report an error.

Error Messages/Logs

Steps to Reproduce

N/A

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.152

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_