When the Agent uses StrReplace / Apply / Write on a file larger than 8 MiB, Cursor rewrites the entire file instead of applying a surgical patch, then silently truncates the write at exactly 8 MiB (8,388,608 bytes). The tool still reports success.
Evidence from a Unity .unity scene (~12.0 MB / 452,917 lines):
Intended change: rename one line (Main Camera → Main Camera_CURSOR_TEST, +12 bytes)
Hey, thanks for the detailed report. The byte-level evidence and the sed check helped a lot, it only took me a few minutes to confirm.
Your analysis is correct. The Agent reads the whole file but caps it at exactly 8 MiB 8,388,608 bytes, and the edit tools StrReplace Apply MultiStrReplace write the full buffer back without checking if the read was truncated. That’s why it writes only the first 8 MiB plus your edit delta, while still reporting success. This is a bug on our side, I’ve filed it internally with the team.
Interim workaround until it’s fixed: for files larger than 8 MiB like Unity .unity scenes, prefabs, etc, avoid the built-in edit tools and edit via shell instead. sed or perl will produce a surgical diff and won’t touch the rest of the file, like you showed in your check.
I can’t share an ETA for the fix yet. Once I have an update, I’ll reply in the thread.
I promised an update, so here it is. I re-tested this today on the current stable version 3.23.13, and nothing has changed. A single StrReplace on a 14 MiB, 400k-line file wrote back exactly 8,388,607 bytes. That means 173k lines were lost, a line was cut in the middle, and the tool still reported updated with no warning. Your byte-level analysis is still correct.
Nothing has shipped to fix this yet, and I don’t have an ETA. The workaround still applies. For anything over 8 MiB, keep the agent away from the built-in edit tools and use sed or perl in the shell, or add those paths to .cursorignore so it can’t touch them at all.
If you’ve run into this again since July, or if it hit another user reading this, a short reply here with the version number helps us show how many users it affects.
Following up as promised: the large file truncation issue you reported is fixed, and the fix is in the current Cursor release 3.24.
When the Agent’s built in edit tools StrReplace, MultiStrReplace, and ApplyPatch hit a file larger than 8 MiB, they now refuse the edit with a clear error and leave the file unchanged. Before this, they could cut the file off at 8 MiB while still reporting success. For files that large, the Agent now switches to a shell edit instead, using the same sed or perl approach you used in your control test, so large Unity scenes and prefabs should no longer get corrupted.
Thanks again for the detailed report and the byte level evidence. It made this quick to confirm. If you’re on the latest version and still see a large file get truncated, let me know here.