GBK 等非 UTF-8 编辑改为拒绝
Claude Code 2.1.296 起，Edit 和 NotebookEdit 不再改写非法 UTF-8 的文件。修复前，Windows-1252、Shift-JIS、GBK 里的每个非 ASCII 字符都可能被换掉。现在改为拒绝。说明没写 Read 或 Bash 会拒绝，也没写会自动转成 UTF-8。
用 GBK 存的源文件，以前可能在一次编辑里把中文全部换坏。claude code gbk 文件编辑 在 2.1.296 的结果是：Edit 和 NotebookEdit 遇到不是合法 UTF-8 的文件时，拒绝这次编辑。发行说明点名的编码有 Windows-1252、Shift-JIS 和 GBK。修复前的行为是把文件里每一个非 ASCII 字符都替换掉。
合法 UTF-8 的中文不在这句里
判断标准是文件字节是否为合法 UTF-8，不是「里面有没有汉字」。用 UTF-8 保存的中文源文件，本来就能通过这道检查。编辑被拒绝时，先看文件是不是仍以 GBK 或其他旧编码保存。说明没有写拒绝时的原文，也没有写会弹出哪一种编码的名字。
NotebookEdit 和 Edit 一起被点名。笔记本里的单元如果整文件不是合法 UTF-8，同样改为拒绝。只改一个代码单元、文件其余部分仍是 GBK 时，说明没有承诺会只改那一格。
Read 没有出现在这句。低于或高于 2.1.296，读一份 GBK 文件会显示成什么，这句都不负责。Bash 去改字节，也不在这句的修复范围内。
已经换坏的字符不会跟着升级复原
升级只是让下一次编辑被拒绝，不把已经写坏的文件改回去。若仓库里出现成片替换过的非 ASCII，那是修复前某次编辑留下的。用版本管理里的上一份完整文件恢复，比在坏文件上再编辑一次更稳。2.1.296 没有提供还原命令。
另存为 UTF-8 是编辑器里的普通操作，发行说明没有把它写成 Claude Code 的步骤。转完之后再让 Edit 改，文件已经是合法 UTF-8，就不再走「拒绝非 UTF-8」这条。转换若把换行从 CRLF 改掉，那是编辑器的选项，和这句编码修复无关。工作流脚本因 CRLF 被拒，是同一版里另一条，不要合成一个开关。