fix(core): preserve CRLF line endings when editing files

[howardpen9]

Summary

The edit tool normalizes file content from CRLF to LF for consistent matching, but did not restore CRLF line endings when writing back. This silently converts Windows-style (\r\n) line endings to Unix-style (\n), causing:

• Massive git diffs (every line appears changed)
• .editorconfig enforcement breakage
• Team collaboration issues on mixed OS teams

Root Cause

In edit.ts, calculateEdit() normalizes content for matching:

currentContent = fileInfo.content.replace(/\r\n/g, '\n');

But the write path passes editData.newContent (LF-only) directly to writeTextFile() without restoring the original line endings.

Changes

packages/core/src/tools/edit.ts:

• Detect CRLF before normalization: usesCRLF = fileInfo.content.includes('\r\n')
• Use existing normalizeContent() utility (handles CRLF, standalone CR, and BOM) instead of inline replace
• Restore CRLF on write-back when the original file used CRLF
• Add usesCRLF flag to CalculatedEdit interface

packages/core/src/tools/edit.test.ts:

• should preserve CRLF line endings when editing a CRLF file
• should not inject CRLF when editing a LF file
• should preserve UTF-8 BOM when editing a BOM file

Reproduction

1. Create a file with CRLF line endings on Windows
2. Use the edit tool to modify a line
3. Run git diff — every line shows as changed (line ending conversion)

Related

• Fixes Vscode中的QwenCode编辑代码时报错：Edit 工具用 LF 匹配，文件是 CRLF，多行匹配失败 #2257
• Builds on normalizeContent() from fix(cli): parse markdown command frontmatter on Windows CRLF/BOM #2078

[howardpen9]

123

[timxx]

When will this PR be merged? It is too noisy, as it rewrites CRLF to LF on every edit.

[tanzhenxin]

Addressed in #2707 , closing this one.