# Agent Write tool inserts blank line between every line in file contents **URL:** \ **Category:** Bug Reports\ **Tags:** composer\ **Created:** [May 27, 2026, 2:01pm UTC](https://forum.cursor.com/t/agent-write-tool-inserts-blank-line-between-every-line-in-file-contents/161703 "2026-05-27T14:01:45Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![tommynanny](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/tommynanny/32/109857_2.png) [@tommynanny](https://forum.cursor.com/u/tommynanny)\ **Post date:** [May 27, 2026, 2:01pm UTC](https://forum.cursor.com/t/agent-write-tool-inserts-blank-line-between-every-line-in-file-contents/161703/1 "2026-05-27T14:01:45Z")
### Where does the bug appear (feature/product)? Cursor IDE ### Describe the Bug 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.: ```go package simulation import ( "bitbucket.org/..." ) ``` **Environment:** - OS: Windows 10.0.26200 - Tool: Agent `Write` (full file write) - Observed in: `app/sim/simulation/meta.go`, `app/internal/use_case/nasa_takeoff.go` **Impact:** Large diffs, broken readability, may fail linters/formatters until manually fixed. **Workaround:** Manually reformat the file, or ask the agent to fix spacing afterward. ### Steps to Reproduce - Ask the agent to rewrite a Go file using the Write tool (full file replace, not search/replace). - Open the written file. ### Expected Behavior Normal Go formatting — single newlines between lines, standard import grouping. ### Operating System Windows 10/11 ### Version Information Version: 3.5.33 (system setup) VSCode Version: 1.105.1 Commit: aac81804b986d739acab348ed96b8bea6e83cc50 Date: 2026-05-22T06:47:48.039Z Layout: editor 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.26200 ### For AI issues: which model did you use? Composer 2.5 ### For AI issues: add Request ID with privacy disabled 7b610645-d529-4b08-9675-b6ae6c54fb3b ### Does this stop you from using Cursor No - Cursor works, but with this issue ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [May 27, 2026, 2:36pm UTC](https://forum.cursor.com/t/agent-write-tool-inserts-blank-line-between-every-line-in-file-contents/161703/5 "2026-05-27T14:36:33Z")
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. ---
**Author:** ![tommynanny](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/tommynanny/32/109857_2.png) [@tommynanny](https://forum.cursor.com/u/tommynanny)\ **Post date:** [May 27, 2026, 4:13pm UTC](https://forum.cursor.com/t/agent-write-tool-inserts-blank-line-between-every-line-in-file-contents/161703/6 "2026-05-27T16:13:00Z")
Hey Dean, 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! 🙇‍♂️ ---
**Author:** ![tommynanny](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/tommynanny/32/109857_2.png) [@tommynanny](https://forum.cursor.com/u/tommynanny)\ **Post date:** [May 31, 2026, 3:56pm UTC](https://forum.cursor.com/t/agent-write-tool-inserts-blank-line-between-every-line-in-file-contents/161703/7 "2026-05-31T15:56:17Z")
@deanrie follow-up on this bug — happened again today. **Environment** - OS: Windows 10.0.26200 - Cursor: Composer 2.5, Agent **Write** tool (full file overwrite) - File: `app/core/engine/lifecycle.go` - Editor EOL: LF - Git `core.autocrlf`: true **What happened** 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`: ```bash 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. [lifecycle-bug-report.txt](https://forum.cursor.com/uploads/short-url/gliuABw2zn5lSaRTqWjjGzJ7L0q.txt) (6.4 KB) ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [May 31, 2026, 4:44pm UTC](https://forum.cursor.com/t/agent-write-tool-inserts-blank-line-between-every-line-in-file-contents/161703/8 "2026-05-31T16:44:58Z")
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. ---
**Author:** ![eluvatar](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/eluvatar/32/111668_2.png) [@eluvatar](https://forum.cursor.com/u/eluvatar)\ **Post date:** [June 17, 2026, 2:32am UTC](https://forum.cursor.com/t/agent-write-tool-inserts-blank-line-between-every-line-in-file-contents/161703/10 "2026-06-17T02:32:09Z")
I’m also seeing this issue. Windows 11, auto. Checked a hex dump to confirm the same `\r\r\n` line ending issue. Request ID 8717085e-86ec-45f5-9a10-53239e5ec680 ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [June 28, 2026, 6:35pm UTC](https://forum.cursor.com/t/agent-write-tool-inserts-blank-line-between-every-line-in-file-contents/161703/11 "2026-06-28T18:35:29Z")
Hey, thanks for confirming and for sharing the Request ID. That matches the pattern we’re already seeing in this thread (`0D 0D 0A` / `\r\r\n` on every line ending, Windows + `autocrlf`). To confirm it’s exactly the same case for you, check the hex. It should be `0D 0D 0A`, not `0D 0A 0D 0A`. Based on what you described, it sounds like the same issue. As a stopgap while we work on a fix: - After this happens, switch the EOL back to LF (status bar bottom right → pick LF → save), or run `dos2unix` or `gofmt -w` on the file. - If you hit another incident, just send the Request ID. No need to collect the hex every time. This is a known bug and we’ve logged it. I can’t share an exact ETA for the fix yet. I’ll post an update in the thread as soon as I have one. ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [October 13, 2026, 8:00am UTC](https://forum.cursor.com/t/agent-write-tool-inserts-blank-line-between-every-line-in-file-contents/161703/15 "2026-10-13T08:00:53Z")
Hey @tommynanny, The issue where the agent’s Write tool saved files with an extra carriage return at the end of every line (the `0D 0D 0A` from your hex dump) has been fixed in a recent Cursor update. Updating to the latest version should resolve this. Files that were already affected before you update won’t be changed by the update, so they still need a one-time cleanup. For Go files, running `gofmt -w` on them takes care of it. Let me know if you still see blank lines showing up after a Write on the latest version (3.24+) cc @eluvatar