New files created with CRLF on Windows, ignoring all settings (LF)

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor agent on Windows creates new files with CRLF line endings no matter what, even though LF line ending was specified in all settings (i.e., files.eol, .editorconfig, and .gitattributes), git config --global core.autocrlf is not set, and the whole project uses LF (not CRLF).

Steps to Reproduce

Set files.eol (editor setting) to \n (LF).
Create an .editorconfig in the project root with end_of_line = lf.
Create .gitattributes with * text=auto eol=lf (and no mention of crlf).

Open new chat with any model (tested with Composer 2 and Opus 4.6) and execute this prompt:

❝Create a new test file called hello_world.js that prints “Hello World” to the console when run with Node.❞

cursor_hello_world_test_file.txt (944 Bytes)

Expected Behavior

The new file should have LF line endings.

Operating System

Windows 10/11

Version Information

Version: 2.6.22 (user setup)
VSCode Version: 1.105.1
Commit: c6285feaba0ad62603f7c22e72f0a170dc8415a0
Date: 2026-03-27T15:59:31.561Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19045

For AI issues: which model did you use?

Composer 2
Opus 4.6

Additional Information

This is causing headaches for our team. I’m guessing developers at Cursor are Mac-centric, but we would really appreciate if you could give this some attention. Fancy new features are not valuable if editor basics are broken.

This bug report is a DUPLICATE of the first one below (151096). I am re-reporting because that one no longer allows comments, and Cursor’s bug reporting guidelines say that bugs affecting more users will get more attention. I see no other way to let the Cursor team know that this is still an issue affecting Windows users.

Issues with Cursor converting LF to CRLF or creating files with CRLF despite LF settings have been reported repeatedly for the past 2 months.


New files (DUPLICATE of this bug report)

2/6/2026


Changing files

1/30/2026

2/1/2026

2/4/2026

2/12/2026

2/9/2026

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey, thanks for the detailed report and for gathering all the duplicates in one place.

This is a known bug. When creating new files on Windows, Cursor doesn’t respect files.eol, .editorconfig, or .gitattributes. Instead, it uses a heuristic based on existing files in the workspace or the OS default, which is CRLF on Windows. The team is aware, but there isn’t a specific ETA for a fix yet. Your report helps with prioritization since a lot of users have hit the same thing.

Unfortunately, there isn’t a good workaround specifically for creating new files. The only option is to manually change the line endings after the agent creates the file using the status bar in the bottom right. Click CRLF and switch it to LF.

Main thread to track: Cursor update changed line endings in entire codebase without consent

We’ll post an update there when there’s progress.

A post was merged into an existing topic: Cursor update changed line endings in entire codebase without consent