I am unable to edit over the text, I get two links error and another agent edit errors:
Where does the bug appear (feature/product)?
- Editor, Tab & Chat (in-editor Agent / Composer Write, StrReplace, ApplyPatch)
- Terminal & commands (Agent Shell + approval-card pile-up when a write fails)
Describe the Bug
Windows 11. Paid Cursor. Daily Agent work in C#, ASP dot NET (CRLF), Java, SQL.
The built-in Agent Write / StrReplace / ApplyPatch path on Windows is not safe for real source file edits in a multiple-developer platform environment. It produces UTF-16/BOM or encoding damage, or it misses multiline edits against CRLF. PowerShell Set-Content / here-strings fail the same way. I blocked those writers with local hooks and route every text edit through a custom Python door so agents cannot silently corrupt the tree.
That door is why our repos stay intact.
Steps to Reproduce
- Windows 11. Open a repo that has CRLF files (ASP.NET WebForms
.cs/.ascx.csis enough). - Ask the in-editor Agent (Grok 4.6) to apply a two-line exact edit, e.g. change
if (checkRevCount != null)/checkUnitCount.Checked = false;
to
if (checkUnitCount != null)/checkUnitCount.Checked = false;
in an existing CRLF file (~30 KB). - Watch Write / StrReplace / a multiline
patchneedle: single lines match; the same two lines joined with newline + indent fail (old_string not foundon both LF and CRLF needles). - Separately: ask the Agent to update one section of an existing ~7 KB markdown plan. After one patch miss the path is a full-file write. The Agent thrashes minting a multiline body (30 minutes observed; I stopped it).
- Optional: leave an Agent on a write overnight. Next morning the write is still stuck, or the next session is spent on the write path, not the product task.
Expected Behavior
- Native Agent Write / StrReplace must write UTF-8, preserve existing newlines (CRLF included), and apply a small exact edit without a custom encoder or a local hook stack.
- One miss should be recoverable in the next command. It should not become a 15–60 minute stuck loop or an all-morning incident.
- Windows must be a first-class Agent target. I should not have to be unpaid QA for file encoding so agents can edit C# / ASP.NET / Java on this OS.
- A Windows shop should be able to leave an agent overnight and come back to merged edits.
I am not asking for another workaround recipe. I am asking you to fix the product writer.
Screenshots / Screen Recordings
n/a - Hooks in place
Operating System
Windows 10/11 — Windows 11
Version Information
Version: 3.18.25 (user setup)
VS Code Extension API: 1.128.0
Commit: 280eca2911f1774689696e5f1efa5a4f97a87af0
Date: 2026-08-31T23:08:02.261Z
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.291
OS: Windows_NT x64 10.0.26200
For AI issues: which model did you use?
Cursor Grok 4.6 (this Agent chat). Same class of failure on other in-editor Agents doing writes.
For AI issues: add Request ID with privacy disabled
Request ID: 1137c320-ce43-446b-b4b2-95050722aade
Additional Information
Cost of one dedicated “hooks / write-path” Agent chat (25 Aug 2026 – 2 Sep 2026), from that chat’s transcript:
- 125 of my turns, 2,298 assistant turns
- Active work on 26 Aug, 31 Aug, 1 Sep, 2 Sep
- About 13 hours of my wall-clock time in that chat (4.5 h + 1 h+ + 3.2 h + 4.2 h), not counting other agents
- Last night: another agent spent 30 minutes and failed a single ~7 KB plan-section update; I stopped it
- This morning: another agent spent 15 minutes and failed a two-line CRLF C# patch; I stopped it and spent the rest of the morning (8:52 AM–1 PM) on the write path again
- Product work that should have been 15–30 minutes today is now at risk of taking the rest of the day; yesterday’s work was already pushed to today for the same reason
What happens in practice:
- Overnight / unattended edits fail or stick (multiline CRLF miss, invalid payload, approval-card pile-up, or a deny the agent “solves” by inventing another writer).
- I spend the next morning and a token budget on the write path instead of the product work that was already late.
- Even after we add extract-exact-bytes / remint / whitespace fingerprints, the same agent then thrashes on leftover docs using the method we had just banned.
Does this stop you from using Cursor?
Sometimes — I can use Cursor only because I built a local write door. Without that, Agent writes corrupt files or get stuck. With it, I still lose mornings and tokens when writes fail overnight.