[BUG] Windows: Edit on a Shift_JIS file replaces every Japanese character in the file with U+FFFD and saves it as UTF-8

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

A one-word Edit in a Shift_JIS (CP932) file destroys all the Japanese text in the file, including lines the edit did not touch. The file is written back as UTF-8, and each Japanese character that could not be decoded as UTF-8 is replaced with U+FFFD. The original bytes are gone.

Before (decoded as CP932):

# 設定ファイル：ここは日本語のコメントです
name = "テスト"
fruit = "APPLE"
note = "ソフト表示、能力、予定"

After Edit of APPLE → ORANGE (the file is now UTF-8):

# �ݒ�t�@�C���F�����͓��{��̃R�����g�ł�
name = "�e�X�g"
fruit = "ORANGE"
note = "�\�t�g�\���A�\�́A�\��"

38 U+FFFD characters, 107 → 182 bytes. Without version control there is no way back.

In one of the Sonnet runs the model then reported "The other lines are unchanged (still Shift-JIS encoded, same as before)", which is not true. In the Opus run the model noticed the damage and rewrote the file with PowerShell, but the Edit call itself had corrupted it in the same way.

#62723 reported a milder form in May (inserted text written as UTF-8, original bytes kept). It was closed as stale and marked duplicate, not fixed. #7134 (Windows-1252) is still open. On 2.1.280 the untouched text is now lost as well.

What Should Happen?

Edit keeps the file's encoding, or refuses to edit a file it cannot decode and says so. It should not write U+FFFD over bytes it could not read.

Steps to Reproduce

1. Create a CP932 file (Python):

``python
text = '# 設定ファイル：ここは日本語のコメントです\nname = "テスト"\nfruit = "APPLE"\nnote = "ソフト表示、能力、予定"\n'
open("sjis.py", "wb").write(text.encode("cp932"))
``

1. Run:

``
claude -p --permission-mode acceptEdits --disallowedTools Bash \
"Use the Edit tool on the file sjis.py to replace the word APPLE with ORANGE. Change nothing else in the file. Do not use Bash. Reply DONE."
``

1. python -c "print(open('sjis.py','rb').read().decode('utf-8'))" shows the U+FFFD text above.

Results

The same prompt on nine small files, each checked byte for byte (the only allowed difference is APPLE → ORANGE in the file's own encoding):

| File | Result |
|---|---|
| Shift_JIS, LF | rewritten as UTF-8, 38 × U+FFFD (4 of 4 runs: 3 Sonnet 5, 1 Opus 5.5) |
| Shift_JIS, CRLF | rewritten as UTF-8, U+FFFD (1 of 1) |
| UTF-8 | OK |
| UTF-8 with BOM | OK |
| UTF-8, CRLF | OK |
| UTF-16 LE with BOM, CRLF | OK |
| tabs, no final newline | OK |
| mixed CRLF/LF | all line endings changed to LF (separate issue, not reported here) |

So files with a BOM are detected; files in a legacy code page without a BOM are read as UTF-8 and written back as UTF-8.

Claude Model

Not model-specific: the corruption is done by the Edit tool (Sonnet 5 and Opus 5.5 both).

Is this a regression?

Possibly. #62723 (May 2026) describes inserted text being written as UTF-8 while the original bytes were kept; now the original bytes are replaced.

Claude Code Version

2.1.280 (latest on npm at the time of testing)

Platform

Anthropic API (Claude Max subscription)

Operating System

Windows 11 (Japanese locale, system code page 932)

Terminal/Shell

Git Bash

Additional Information

Shift_JIS is still common in Japan for Windows batch files, CSV exports, and older business systems, so on a Japanese Windows machine this is an easy way to lose data. Related: #62723, #7134, #92328.