Agent StrReplace truncates files > 8 MiB (silent data loss)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

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)
  • Resulting file size: exactly 8,388,620 bytes = 8,388,608 + 12
  • File truncated mid-token (m_LocalPositio cut from m_LocalPosition)
  • Line count dropped ~452,917 → ~303,584
  • git diff: +2 / -149,334
  • UI review bar previously showed ~+303k / -452k and Cursor became unstable/crashed

Control: same one-line edit via sed → 1 insertion / 1 deletion, file remains intact at full size.

This is silent data corruption on large files (common with Unity scenes/prefabs).

Steps to Reproduce

  1. Open a project with a text file larger than 8 MiB (e.g. a Unity .unity scene ~12 MB).
  2. Ask the Agent to make a tiny one-line change using file edit tools (StrReplace), not an external MCP.
  3. Let the edit apply (or watch the review bar).
  4. Check file size / tail / git diff:
    • Final size ≈ 8,388,608 + net byte delta of the edit
    • File ends mid-line / truncated
    • Huge deletions despite a 1-line intent
  5. Compare with the same edit via sed/perl: surgical 1-line diff, file intact.

Operating System

MacOS

Version Information

Version: 3.12.30
VS Code Extension API: 1.128.0
Commit: 63a2996a10d9e476b6c28e951dd7691d9c0cf480
Date: 2026-07-21T22:50:03.568Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

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.