补丁会保留原来的 CRLF
Codex 0.162.0 起，apply_patch 更新文件时保留文件里已有的 CRLF 换行，不再需要单独打开选项。说明没有写会把 LF 文件改成 CRLF，也没有写保存时的编码。Windows 上检出的仓库因此少一次被改成 LF 的风险。
Windows 上的仓库若本来是 CRLF，补丁不该把换行悄悄换成 LF。Codex 0.162.0 写明：apply_patch 在更新时保留已有的 CRLF，而且不需要再打开某个选项。codex apply_patch 保留 crlf 只针对文件里已经是 CRLF 的情况。
不会把 LF 文件改成 CRLF
句子是 preserve existing。原来是 LF 的文件，说明没有写会被改成 CRLF。原来混用两种换行时，也没有写每一行会怎样。只承诺已有的 CRLF 在这次补丁更新里留下来。
「不需要 opt-in」意味着以前可能要打开一个开关，现在默认就保留。说明没有写出旧开关的名字，也没有写旧开关还在不在。低于 0.162.0 时，不要假设已经默认保留。
编码不在这句里。GBK 还是 UTF-8，补丁工具会不会改字节，0.162.0 的这条没有说。换行和编码是两件事。Claude Code 2.1.296 对非法 UTF-8 的编辑改为拒绝，那是另一个产品，见 GBK 编辑被拒。不要用 Codex 的换行修复去解释 Claude Code 的拒绝。
差异里仍可能看见换行变化
保留的是补丁应用之后的文件内容。若模型生成的补丁块本身把换行写成了 LF，说明没有承诺会忽略补丁块里的换行、只改代码。existing 指的是更新前文件已经使用的 CRLF。写作日没有拿一份 CRLF 文件跑 apply_patch。
提交记录里若整文件换行都变了，对一下 Codex 是不是低于 0.162.0。已经是这一版仍全文件变 LF，就不是这句所写的默认行为，要看补丁内容本身。
Git 自己的 core.autocrlf 仍会在检出和提交时转换换行。Codex 保留的是它写回工作区的那一次。若 Git 随后把工作区规范成 LF，差异看起来仍像换行被改了，原因在 Git 配置，不在 apply_patch 这句。两边都要看，才能判断是补丁工具还是仓库设置。说明没有写 Codex 会读取或修改 core.autocrlf。编辑器再次保存时若统一成 LF，同样会盖过这次保留。升级到 0.162.0 只去掉「必须先打开选项才保留 CRLF」这一步。