[BUG] Edit raises "File has been unexpectedly modified" on CRLF files, Write silently converts CRLF on Windows

[BUG] Edit raises "File has been unexpectedly modified" on CRLF files, Write silently converts CRLF → LF on Windows

Background

Split-out from master ticket (54891). This issue isolates two related line-ending bugs on Windows that share the same root cause (the write pipeline normalizes CRLF in a way that doesn't round-trip):

• Mode A: Edit on a CRLF-saved file reports "File has been unexpectedly modified" even when no external process has touched the file. The tool's internal canonical form (LF) disagrees with the on-disk form (CRLF), so the pre-edit hash check fails.
• Mode B: Write over a CRLF-saved file silently rewrites the file with LF endings. Downstream Windows tools (PowerShell, Git for Windows with core.autocrlf=true, Notepad) see content drift.

Both modes are distinct from sibling splits 01 / 02 / 03 / 05 — the corruption surface is line endings, not size / encoding / cache / concurrency.

Note: there are existing tickets in this neighborhood (e.g. claude-code CRLF preferences not applied on Windows) but they primarily cover the LF-conversion side; the unexpectedly modified false-positive on Mode A is reported here specifically because it blocks Edit workflows on any Windows-saved file without warning.

Reproducer

Environment: Windows 11 + Cowork + vault on NTFS.

Mode A — Edit false-positive on CRLF files

1. From PowerShell on host, create a CRLF file:

``powershell
"line1rnline2rnline3rn" | Set-Content -Path C:\vault\sample.md -Encoding utf8 -NoNewline
``

1. From Claude Code, call Edit on sample.md (any edit).
2. Observed: Edit returns "File has been unexpectedly modified since the last Read" even though no other process touched the file between Read and Edit.

Mode B — Write silently converts CRLF → LF

1. Same CRLF source file.
2. From Claude Code, call Write with payload that contains \r\n line endings.
3. Verify on host:

``powershell
Format-Hex C:\vault\sample.md | Select-Object -First 3
# Expected: 0d 0a sequences at line ends.
# Actual: 0a only — CRLF stripped.
``

1. Git diff reports every line changed on the next commit (whole-file line-ending churn).

Expected behavior

Mode A

1. Edit's pre-write hash check must normalize line endings on both sides (or store the raw on-disk hash including CRLF). False-positive unexpectedly modified on otherwise-untouched CRLF files breaks Windows workflows.
2. Alternatively: an explicit line_ending parameter on Edit to declare the file's native form.

Mode B

1. Write must preserve the line-ending convention of the file it overwrites (or honor core.autocrlf / a user setting).
2. If converting CRLF → LF is intentional, it must be opt-in and visible in tool output.

Actual behavior

Mode A blocks Edit on any Windows-saved file (e.g. files touched by Notepad, by Aiken's PowerShell scripts, by Obsidian on Windows with certain plugin settings) with a misleading error that suggests external interference. Workaround is to manually re-Read then re-attempt, often multiple times, with no underlying state change.

Mode B silently churns line endings across Aiken's vault, breaking Git diff signal-to-noise ratio and confusing downstream Windows tools that key on CRLF.

Environment

• OS: Windows 11 (build 26100.x), NTFS host
• Claude Code: 2.1.123
• Cowork desktop app
• Affected files: any .md / .ps1 / .txt previously saved with CRLF (Notepad, PowerShell Set-Content, Obsidian on Windows with line-ending plugins)

Related

• Parent master ticket: (54891)
• Sibling splits: #54891-split-01, -02, -03, -05
• Adjacent: existing issues on "claude-code on Windows does not apply CRLF preferences" / "Edit/Write convert CRLF to LF on Windows"

Workaround (current)

For Mode A: detect the false-positive by checking byte-equality of pre-Edit and post-unexpectedly modified reads; if equal, retry up to 3× before bailing.

For Mode B: pre-normalize the vault to LF + add * text=auto eol=lf to .gitattributes. Acceptable for vault, not acceptable for .ps1 scripts that Windows tools expect in CRLF.

---

Cross-reference: split from closed master ticket #54891 (auto-closed as not_planned 2026-06-01 by github-actions[bot]; reproducible bugs persist). Also related to #64592 (Cowork VM service cluster). Submitted by dispatcher via REST API on behalf of the issue author (Claude Team subscription holder, IT MSP production use).