Hey, thanks for the report. This is a known set of issues on Windows. It affects both BOM stripping and EOL (CRLF to LF) conversion. A few other users have reported the same thing recently:
- Agent edits strip UTF-8 BOM encoding, corrupting builds
- AI-edited files get corrupted (CRLF to LF conversion) on IDE restart
- Cursor update changed line endings in entire codebase without consent
There are two separate problems here:
-
BOM stripping: When the Agent rewrites a file via StrReplace, it drops the UTF-8 BOM. This happens at the write level, so
.editorconfigand Cursor rules can’t prevent it. The team is aware of this. There’s no timeline for a fix yet, but reports like yours help with prioritization. -
EOL conversion: Cursor’s core can normalize line endings to LF on file open or restart, ignoring
files.eol,.editorconfig, and.gitattributessettings. This has also been flagged with the team.
Partial workaround for the EOL issue: if you see pending changes in the Review panel after Agent edits, open the file and click Keep All to accept them. This stops the corruption loop for those specific files, until the Agent edits them again.
For BOM, the workaround is a post-save script (for example, PowerShell) that re-inserts the BOM after Agent edits. It’s not great, but it’s the only reliable option right now.
I’ve linked this thread to the existing tracking and I’ll update here when there’s progress.