Cursor fails at ApplyPatch

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor fails at ApplyPatch

Steps to Reproduce

I simply approved a plan an Cursor tries to create / update files.

This has began Yesterday and is persistent.

Expected Behavior

Cursor succeeds in creating / updating files

Screenshots / Screen Recordings

Screenshot 2026-01-19 at 9.56.51.png
Screenshot 2026-01-19 at 9.56.51.png539×742 97.8 KB

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.3.41
VSCode Version: 1.105.1
Commit: 2ca326e0d1ce10956aea33d54c0e2d8c13c58a30
Date: 2026-01-16T19:14:00.150Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 24.6.0

For AI issues: which model did you use?

gpt-5.2 Codex, gpt-5.2 High, Opus 4.5

Does this stop you from using Cursor

Yes - Cursor is unusable

3

Hey, thanks for the report.

There are a few different errors in the screenshot:

  1. OTLPExporter errors: this is a known telemetry issue starting from 2.3.35, the team is working on a fix.
  2. “No first token received within 6s”: timeouts while waiting for a response from the model.
  3. “maxBuffer length exceeded”: this one is interesting, it might be related to the project size.

A couple questions:

  • About how big is the project? Any large files over 1 to 2 MB?
  • Does this happen on all models, or only a specific one?

For now you can try:

  • Switch to GPT 5.2 High instead of Codex, based on other reports this sometimes helps.
4

Hi,

Project isn’t too large. several micro services and a web application.
Yes, there are files about 1mb, I suppose.
Tried switching between models and the issue was persistent.
Sometimes it goes away for a while and then returns.

Very problematic, as I have to instruct cursor to use scripts for modfiying files, whic I suppose costs me huge amounts of tokens …

5

Thanks for the extra info. The “maxBuffer length exceeded” issue is definitely interesting. It can be related to the project size and how many files the agent is trying to process.

A few workarounds that might help:

  1. Try reducing the agent’s scope:

    • Use @-mentions to explicitly point to only the files or folders you need
    • Close any extra open tabs before running the plan
    • Try splitting a big task into a few smaller plans

  2. For large files (around 1MB):

    • If possible, add them to .cursorignore if the agent doesn’t need to edit them
    • Try working with one microservice at a time

  3. Check your network settings: Cursor Settings > Network > Run Diagnostics. Sometimes timeouts can be caused by network issues

6

Thank you for your answer,

THe things you’ve written are interesting, but I cannot accept them as the root cause, even if they indeed are.

These are issues that should be treated as bugs, in my humble opinion.

That been said, I highly suspect the problem is not large files, as I’ve worked on larger projects in the past, using cursor.

I suspect the root cause is a cursor version which was rolled out after Friday noon, 16’th of January.

Best regards,
Kobi.

7

I get your point about the version regression.

The OTLPExporter errors are a known issue in 2.3.35+. The team is working on a fix, but it’s related to telemetry, not ApplyPatch directly.

The “maxBuffer length exceeded” part is interesting. To dig in, could you:

  1. Send the Request ID from when ApplyPatch fails? In the chat context menu (three dots on the right) select Copy Request ID. This will help the team check what’s breaking on the server side.

  2. Run a quick diagnostic test: try rolling back to 2.3.34 and disable auto-updates in Settings > Application > Update > “none”. If the issue goes away, that would confirm it’s version-related.

If we can confirm a regression with the Request ID, I’ll pass it to the team as a priority.

8

Apologies,

But I sincerely believe reproducing and fixing is on your side of the field :slight_smile:

I gave you all I had.

Best regards,
Kobi.

9

Same to me.

I’ve noticed a pattern that might help the Cursor team identify and filter similar cases in backend logs:

When “Apply patch” fails, Cursor still seems to think it succeeded, but the actual change applied to the file is almost zero — e.g., it only deletes an empty line or someelse.

It might be worth checking the diff size right after applying the patch. If the diff is obviously abnormal, Cursor should trigger additional analysis / troubleshooting instead of treating it as a success.

From my experience, this doesn’t feel rare (likely >1%). The Cursor team may want to query backend logs for requests with suspiciously tiny diffs after “successful” apply operations and investigate them further.

10

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.