Claude Code was replacing every non-ASCII character in non-UTF-8 files. Now it refuses.

Claude Code was replacing every non-ASCII character in a file it could not read as UTF-8, and the repair Anthropic shipped is not a better conversion. It is a refusal. The changelog entry for version 2.1.296 reads: "Fixed Edit and NotebookEdit replacing every non-ASCII character in files that are not valid UTF-8 (Windows-1252, Shift-JIS, GBK); such edits are now refused."

A Claude Code session reading a file and writing a test. Image: Anthropic

That is a data-integrity bug rather than a crash. A tool that fails loudly wastes your afternoon. A tool that writes a file back with every accented letter, every umlaut and every Japanese or Chinese character swapped out leaves you with a file that opens, compiles perhaps, and is wrong in ways a diff shows only if you look at it.

Three encodings, and all of them are still in use

The three Anthropic names are the ones a developer meets in old code rather than in new. Windows-1252 is the single-byte encoding Windows used for western European text for years, and it is what a CSV exported from an older Windows tool still tends to be. Shift-JIS is the Japanese encoding that predates Unicode's adoption there, and GBK covers simplified Chinese. None of them is valid UTF-8, so a reader that assumes UTF-8 sees invalid bytes and has to decide what to do with them. Claude Code's old answer was to substitute, which is the standard behaviour of a lenient decoder and the wrong one for a file you are about to write back to disk.

Anthropic publishes no CVE, no severity rating and no range of affected versions, and it does not say when the behaviour started. What is dated is the fix. Version 2.1.296 went to the npm registry at 16:58:10 UTC on October 9, and the registry still lists it as both latest and next, with the separate stable channel on 2.1.287 from October 1. Those figures were read at 21:52 UTC on October 10, and the changelog at 21:35 UTC the same day.

Two more fixes in the same release lost text as well

2.1.296 is a large release, grouped by Anthropic into additions, changes, nine improvements and 56 bug fixes, and two of those fixes have the same flavour. One reads: "Fixed CLAUDE_CODE_TRANSCRIPT_LOCAL_GC dropping a message from the saved transcript when its text held a Unicode line or paragraph separator (U+2028, U+2029)." The other: "Fixed claude purge leaving a prompt in the history file when its text held a Unicode line or paragraph separator (U+2028, U+2029)."

U+2028 and U+2029 are invisible characters that mean line break and paragraph break, and they arrive in a prompt through a paste from a word processor or a web page rather than by anyone typing them. One fault dropped a message that should have been kept, the other kept a prompt that should have been purged, and both turn on a character nobody can see. The changelog records a similar fault earlier in the month, when version 2.1.286 closed four secret-redaction gaps, one of them opened by an invisible character.

Reading large files and Windows line endings also changed

Two other entries in the release touch what the tool will and will not open. Anthropic "Added an allow_large option to the Read tool so Claude can read a text file past the usual size limits in one call when it needs the whole file and the context has room", and it "Fixed the Workflow tool refusing script files with CRLF line endings, such as files checked out on Windows". Both point the same way as the encoding fix: at the gap between what a file actually contains and what a tool assumes it contains.

There is no action to take beyond updating, and no statement from Anthropic about files that were edited before the fix landed. Three numbered releases went out in the two days before it, and the one that opened that run was 2.1.293, which withdrew a cloud-session fix two days after shipping it.