When the Cursor agent uses the Write tool to overwrite a Go source file, the written file ends up with an extra blank line between every line of code (double-spaced formatting).
Actual: Every line separated by an empty line, e.g.:
Hey, thanks for the detailed report and the Request ID.
To narrow down the cause, I need a couple quick details. The issue could be either the model output itself or how line endings are handled when writing on Windows, and from the outside it looks the same.
Can you check and share:
Line endings in the original file before it was overwritten. What were they CRLF, LF, or mixed? You can see it in the bottom right of Cursor in the status bar when the file is open.
What’s inside the new version of the file. Open the corrupted file and check the same EOL indicator in the status bar. If you can, share a hex dump of the first lines PowerShell: Format-Hex -Path .\meta.go | Select-Object -First 5. This will show right away if it’s 0D 0A 0D 0A or 0A 0A.
Repro details. Does this happen every time on any Write in a Go file, or was it a one off? Does it happen with other languages or with a different model like Claude 4.6 Sonnet on the same files?
With that info I can tell whether bytes are getting doubled during the write or the model is generating double newlines, and I can escalate to the right team.
I’ve noticed it happen a few times now. I exclusively use Go for these files and mainly use Composer (haven’t tried other models yet).
I am on Windows 11, but my Cursor editor is configured to work with LF line endings, and I have Git set up to commit as LF as well. Originally, I thought it might be a local Git lifecycle issue, but I caught it this time and realized the double-spaced whitespaces are actually present in the file before I run a git commit—right after the Cursor agent finishes running the task.
I don’t have the exact hex dump on hand for the previous instances right now, but I wanted to report this pattern. I’ll keep a close eye on it, and the next time it happens, I’ll grab the Format-Hex output to drop in here. Thanks for keeping track of this!
After the agent finished, the file was double-spaced on disk — a blank line between every line of code — before any commit or manual edit. HEAD had 103 lines; the corrupted file had 215.
Hex finding (not \n\n or \r\n\r\n)
The Write tool wrote 0D 0D 0A (\r\r\n) on line endings — 107 occurrences, zero normal CRLF. After package engine:
65 6E 67 69 6E 65 0D 0D 0A ("engine\r\r\n")
HEAD in git uses LF (0A) only. Hypothesis: Write on Windows with autocrlf=true may be converting \n → \r\r\n instead of \r\n.
Request IDs
This session: 3a8efae6-6e10-4f1f-8c2d-262f65dcc361
Attached:lifecycle-bug-report.txt — full diagnostic report (hex dump, line counts, git diff) generated by Cursor Agent from a different session.
Same pattern as my earlier reports on other .go files (meta.go, nasa_takeoff.go). Happy to re-test with another model if that helps narrow it down.
Thanks, the hex dump explains it. You can see that Write is writing 0D 0D 0A\r\r\n at every line ending, 107 times, and there isn’t a single normal CRLF or \n\n. That means the cause isn’t the model output it’s not generating double newlines, it’s the line ending handling on the write side where an extra 0x0D gets added to the end of each line. On Windows that shows up as a blank line between code lines.
I reported this internally with all the details (hex, Request ID, environment with autocrlf=true and EOL=LF).
A couple things that can help:
As a stopgap, after a Write like this you can fix the file by switching EOL back to LF (status bar bottom right → select LF → save) or by running dos2unix or gofmt -w.
If you can, try the same full-file Write with a different model (for example Claude 4.6 Sonnet) on the same file. If \r\r\n doesn’t show up there, it’ll narrow down which step is breaking. Not urgent, but it’d be a useful signal.
Let me know how it goes, and if you catch another incident you can just send the Request ID, no need to collect hex every time.
